Inside <library_visual_scene> I set references to geometry nodes in the <library_geometries> section. Using <extra> and <technique> I can attach metadata (= alphanumeric data) to the geometry.
From the visual scene section I can reference the same geometry multiple times to and place it at different positions using <matrix>. But in this case, all instances have the same metadata.
I'm looking for a concept to store individual metadata for each object in the visual scene while referencing one geometry node.
A COLLADA sample file would be helpful - Thanks!
The concept above is identical to the behaviour in AutoCAD for blocks with attributes (=metadata). There I can define geometrie and attributes in a block definition. When I place the block reference I can set individual attribute values for each block reference.
Related
I'm trying to access Animation's but so far the only method I could think of was:
tool
...
set_meta("animation_path",["NodePath/to/AnimationPlayer","Animation Name"])
var ani_data=get_meta("animation_path")
var animation=get_node(ani_data[0]).get_animation(ani_data[1])
but the problem is that if I change the Animation Name I'll have to reset the value, so is there no way to store a unique id for Animation resource?
I tried storing get_instance_id() & using instance_from_id() but that doesn't work when I restart the game engine
If the Animation is saved
Given that Animation is a Resource, I believe you can use the resource_path (given the Animation is saved).
The resource_path represents where the Resource is saved, and thus it persists when you restart the game engine.
Also, it would be unique for each Resource (it is possible to have multiple Resources saved in the same file, but then the resource_path of each Resource points to a sub-resource of the file).
And yes, the resource_path does not change when you rename the Animation.
The other idea that comes to mind is that the Animation itself has metadata which you could use.
If you will not be using the animation name, you would have to iterate over the Animations of the AnimationPlayer to find the one you want.
I suppose that if you use the resource_path, you could load it and get the animation name form there. You could also be getting the same instance… That happens if you are getting it from cache.
If the Animation is not saved.
First of all, storing metadata on the Animation should still work. Except, of course, it still means to iterate over the Animations to find the correct one.
If the goal is to not do that, then you can hold a Dictionary with String for keys and Animations as values, and keep it somewhere you know there is only one instance. For example:
Store it in an EditorPlugin.
Store it in an Autoload.
Store it in a specific Resource which you preload.
Store it on a const. Godot will admit Dictionary and Array as consts. Making them consts means you cannot set them… But they are still mutable. Furthermore, consts are shared among instances.
In 3d Model of Autodesk Forge, We want to change the colour of the model with passing the DBId without selection. How can we do it? please help on this.. we are unable to find any reference on this.
If you already have a dbID of an object you'd like to color, you can use the viewer's setThemingColor method.
If you're asking about how to get dbIDs of objects without selecting them, there are different ways. For example, you can iterate through the scene hierarchy (as explained in this blog post), or obtain dbIDs of objects with specific properties (using the getProperties method).
This relates mostly with what a "best practice" would be with D3.js. I want to attach arbitrary information to different svg elements that I have on a page, after they are created. In D3, it looks like one generally generates svg elements from a dataset. I want to attach data to these svg elements at any time, without adding their HTML attributes.
Is there a good way of doing this? Do I need to use an auxillary array/object or is there a way to apply data to the elements themselves?
You would use the datum method if you want to attach arbitrary data:
D3.select('#mynodeId').datum( mydata );
And then later you could access the value again:
var mydata = D3.select('#mynodeId').datum();
Internally, D3 is going to use the __data__ property of the node, just like it does when the nodes were created from a data set via the selectAll, enter, append sequence.
Note that if you already have a reference to a DOM node you can pass it as the parameter to D3.select rather than making it re-look-up based on selector syntax:
D3.select( anExistingDOMNodeReference ).datum( mydata );
From the API doc:
d3.select(node): Selects the specified node. This is useful if you already have a reference to a node, such as d3.select(this) within an event listener, or a global such as document.body.
I understand that they are very similar and that the XDocument represents a whole document and an XElement represents a fragment of a whole document, but they seem to be very similar when it comes to loading and querying/updating the data. I am going to have templates saved to a disk and when I load them, I want to query over them and insert,update, and delete sections of data be it attributes or elements. Does XDocument or XElement make a difference here? Does it make a difference if I build the template on the dynamically first?
For starters, they behave in a different way when loading a document, which means you'll have to write your queries in a different way when you choose one over the other. Except for that, msdn states that
The XDocument class contains the information necessary for a valid XML document. This includes an XML declaration, processing instructions, and comments.
Note that you only have to create XDocument objects if you require the specific functionality provided by the XDocument class. In many circumstances, you can work directly with XElement. Working directly with XElement is a simpler programming model
So I'd stick to XElement, unless any of above mentioned metadata about xml is needed (which doesnt seem to be the case).
Edited by OP.
My program is in need of a lot of cleanup and restructuring.
In another post I asked about leaving the MFC DocView framework and going to the WinProc & Message Loop way (what is that called for short?). Well at present I am thinking that I should clean up what I have in Doc View and perhaps later convert to non-MFC it that even makes sense. My Document class currently has almost nothing useful in it.
I think a place to start is the InitInstance() function (posted below).
In this part:
POSITION pos=pDocTemplate->GetFirstDocPosition();
CLCWDoc *pDoc=(CLCWDoc *)pDocTemplate->GetNextDoc(pos);
ASSERT_VALID(pDoc);
POSITION vpos=pDoc->GetFirstViewPosition();
CChildView *pCV=(CChildView *)pDoc->GetNextView(vpos);
This seem strange to me. I only have one doc and one view. I feel like I am going about it backwards with GetNextDoc() and GetNextView(). To try to use a silly analogy; it's like I have a book in my hand but I have to look up in it's index to find out what page the Title of the book is on. I'm tired of feeling embarrassed about my code. I either need correction or reassurance, or both. :)
Also, all the miscellaneous items are in no particular order. I would like to rearrange them into an order that may be more standard, structured or straightforward.
ALL suggestions welcome!
BOOL CLCWApp::InitInstance()
{
InitCommonControls();
if(!AfxOleInit())
return FALSE;
// Initialize the Toolbar dll. (Toolbar code by Nikolay Denisov.)
InitGuiLibDLL(); // NOTE: insert GuiLib.dll into the resource chain
SetRegistryKey(_T("Real Name Removed"));
// Register document templates
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CLCWDoc),
RUNTIME_CLASS(CMainFrame),
RUNTIME_CLASS(CChildView));
AddDocTemplate(pDocTemplate);
// Parse command line for standard shell commands, DDE, file open
CCmdLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
// Dispatch commands specified on the command line
// The window frame appears on the screen in here.
if (!ProcessShellCommand(cmdInfo))
{
AfxMessageBox("Failure processing Command Line");
return FALSE;
}
POSITION pos=pDocTemplate->GetFirstDocPosition();
CLCWDoc *pDoc=(CLCWDoc *)pDocTemplate->GetNextDoc(pos);
ASSERT_VALID(pDoc);
POSITION vpos=pDoc->GetFirstViewPosition();
CChildView *pCV=(CChildView *)pDoc->GetNextView(vpos);
if(!cmdInfo.m_Fn1.IsEmpty() && !cmdInfo.m_Fn2.IsEmpty())
{
pCV->OpenF1(cmdInfo.m_Fn1);
pCV->OpenF2(cmdInfo.m_Fn2);
pCV->DoCompare(); // Sends a paint message when complete
}
// enable file manager drag/drop and DDE Execute open
m_pMainWnd->DragAcceptFiles(TRUE);
m_pMainWnd->ShowWindow(SW_SHOWNORMAL);
m_pMainWnd->UpdateWindow(); // paints the window background
pCV->bDoSize=true; //Prevent a dozen useless size calculations
return TRUE;
}
Thanks
Hard to give you good recommendations without knowing what your program shall do. I have only a few general remarks:
Your InitInstance does not look very messed up for me. It's pretty much standard with a bit of custom code in it.
Also the ugly construction to retrieve the first view from the application class (the chain GetDocTemplate -> GetDoc -> GetView) is standard to my knowledge. I actually don't know another way. You might think about moving it into a separate method like CChildView* CLCWApp::GetFirstView() but well, that's only cosmetic as long as you need it only at one place.
What you are doing and which data you are placing in your Document class and in your View class(es) is more a semantic question if you only have one view. (You have only one document anyway because it's an SDI application.). From a technical viewpoint often both is possible.
But to be open for (perhaps) later extensions to more than one view and to follow the standard pattern of a doc/view architecture there are a few rules of thumb:
Data which exist and have a meaning independent of the way to present and view them (a document file, a database handle, etc.) belong to the document class. I don't know what your pCV->OpenF1(cmdInfo.m_Fn1) ... and so on does but if it's something like a file or filename or a parameter to be used to access data in any way OpenF1 might be better a method of the document class.
Methods which do any kind of data processing or modification of your underlying data belong to the document class as well
Data and methods which are only needed for a specific way to display a document belong to a view class (for instance a selected font, colours, etc.)
On the other side: If you have a fixed number of views which open with the document it might not be wrong to put view specific data into the document, especially if you want to make those view parameters persistent. An example would be a file with some statistical data - your document - and a splitter frame with two views: one displays the data as a grid table and the other as a pie chart. The table has "view data" describing the order of and width of columns, the pie chart has data to configure the colours of the pie pieces and the legend location, for instance. If you want to make sure that the user gets the last view configuration displayed when he opens the document file you have to store these view parameters somewhere. It wouldn't be wrong or bad design in my opinion to store those parameters in the document too, to store and retrieve them from any permanent storage, even if you need them only in the view classes.
If your application allows to open an unlimited number of views for a document dynamically and those views are only temporary as long as the application runs, storing all view configuration parameters directly in the view classes seems more natural to me. Otherwise in the document you would need to manage any kind of dynamic data structure and establish a relationship between a View and an entry in this data structure (an index in an array, or a key in a map, etc.)
If you are in doubt whether to place any data in the document or view class I'd prefer the document because you always have the easy GetDocument() accessor in the View class to retrieve members or call methods of the Doc. To fetch data from the View into the Document requires to iterate through the list of views. (Remember: Doc-View is a 1-n relationship, even in a SDI application.)
Just a few cents.