Accessing Geodes with duplicate Names

[Felix]

Hi,
I have the following problem when loading an .IVE or .OSG file exported from a .3ds file:

Some nodes in the SceneGraph of the OSG file get the same Geode names assigned.

Which looks like this:
Node-1
- Geode-1
Node-2
- Geode-1

Now when using the Vizard API to access such a Geode like mentioned here: http://kb.worldviz.com/articles/1157 I run into trouble.

The documention of <node3d>.getChild states If there are multiple scene graph nodes with the same name, then the first encountered node will be used.

Calling this command multiple times with the same name will return the same node3d object.


I can properly iterate over the names of the child nodes when doing a model.getChild('Node-1').getChildren() or model.getChild('Node-2').getChildren(). Here I can see, that each node in the SceneGraph indeed has it's own Geode but with the same name.

From what I understand, <node3d>.getChildren() won't help either. So how do I access this Geode (Node-2, Geode-1 in the example..), since getChild only returns Node-1, Geode-1?

[farshizzo]

Have you tried the following?
model.getChild('Node-2').getChild('Geode-1')

[Felix]

Thanks for the reply..
Yeah, actually I tried that..
This returns a seemingly random instance of the Geode-1, which is not the Geode-1 I want..
I always look at the World Position of the Geode to distinguish them.
I can read the correct coordinates from the Vizard Inspector.

[farshizzo]

I'm not sure I understand what you mean by a "random instance". Is it a valid instance? Is the position of the instance different every time you run the script?

My guess is that both "Geode-1" nodes refer to the same instance. This means it will have multiple parents, and multiple global positions. So you are most likely getting the global position from the first parent ("Node-1").

In this case, the solution would be to insert a node below "Node-2", ensuring the path to the desired instance of "Geode-1". Try the following code:
geode = model.insertGroupBelow('Node-2')

[Felix]

Wow, thanks a lot.. That seems to be the solving line..