Hello everybody,
I have a geometry in a 3DS file that I want to load with the 3DS-Loaders from “www.newdawnsoftware.com”.
I want to import this scene and later
adjust the positions of some of the 3d-objects. But I found out, that the names
of the Shape3Ds that represent the objects, are empty Strings
( .getName() ). I really need this names to determine wich Shape3D
represents which 3D-object.
Has anyone any suggestions ??
best regards
Marc
Eeep, you mailed me direct about this one too didn’t you?
I’ll try and take a look tonight unless anyone else has any initial suggestions (croft?)
Kev
Do you want to me to hold off on working on org.xith3d.loaders.tds while you address this issue? I can work on org.xith3d.loaders.md2 in the interim.
Na, its fine, I imagine this is a tiny patch. If only I hadn’t spent all night playing about.
Kev
Croft
You obviously have been making some big strides in adding and extending some Xith capabilities. Do you have any plans on putting some of what you have done, the original stuff for the whoola browser, into xith. Behaviors for example?? Are there any other goodies in that tool?
Yes, eventually.
I’ve got a Loader almost ready to contribute that delegates to one of the other New Dawn Software loaders which is chosen based on the filename extension such .obj, .md2, or .3ds. I was thinking about putting it in package org.xith3d.loaders and giving it a name such as MultiLoader or DefaultLoader or somesuch. Any suggestions for the name of this class?
How about ModelLoader ?
Kev
Is there a design pattern that describes this kind of thing?
Here is what I have so far:
http://cvs.sourceforge.net/viewcvs.py/whoola/core/src/com/whoola/core/media/xith/XithLoader.java?rev=1.3&view=auto
I am assuming that you have tested the loaders accessing jar embedded files, accessed using a MyClass.class.getResource() type thing??
There is actually an existing pattern in the Java API core for image IO (look for IIORegistry and ImageIO and the ServiceProviderInterface associated in the Java API reference).
It can be easily adapted to be used for model loading (that’s what I do in my engine).
The benefit is that new loaders are automatically detected when a jar is added to the application class-path.
Another benefit is that you can use the same pattern for Models, Textures and Image loading and therefore everything looks easier.
VincentYes, getClass().getClassLoader().getResource() works for both OBJLoader2 and MD2Loader2. Your message prompted me to do extensive testing today and everything worked fine.
Do you know if that design pattern has a name?
I made the multi-loader extensible. You can now map additional filename extensions to additional loaders at runtime. What to call it, though? How about “ExtLoader” for extensible, filename extension loader? I’m also leaning toward “MultiLoader”.
Are you currently working on that? I am ready to start working on TDSLoader2 tomorrow but I want to make sure we are both not hacking on it at the same time.
Go ahead and work on it. I’ll take a look once you’re done (I’ll want to anyway :)).
Kev
I took a look. Looks kind of scary. It turns out I don’t have a bunch of 3DS models lying around in the company archive so I my incentive to scratch this particular itch is diminished. I am going to postpone indefinitely on this one.
it’s me again …
Remeber me and my problem ? 
In the meantime I found out, there is this class “ModelContext” where all information found out by the "ChunkProcessor"s is stored. But i cant find the place where the real "Shape3D"s (that can be found later in the TDSModel) are created.
greetz Marc
In NamedObjectProcessor.java -
the bit of code that reads:
context.object = new TransformGroup();
context.shape = new Shape3D();
context.shape.setAppearance(new Appearance());
could be changed to:
context.object = new TransformGroup();
context.shape = new Shape3D();
context.shape.setName(context.objectName);
context.shape.setAppearance(new Appearance());
Might work?
Kev
Hi,
thank you for coming back to my problem … in the meantime i solved it by myself.
It is not enough to insert the line
context.shape.setName(context.objectName);
because the Shape3D will be copied later with
<com.xith3d.scenegraph.Node>.sharedCopy()
and the made copy will be attached to the scenegraph. This method does NOT copy the name of the given node and that was the problem. So I changed the method a bit and it worked.
anyway … thanks for your help 
I think it would be now problem if you would commit your changes - or if this is too much work - simply give the line numbers and the changes, so croft, kev or whoever has already got developer acces can also change that while he’s editing the code anyways.
Um, I would say thats a fault with Xith core tho, shared copy does maintain names?
What happens when you want to duplicate your model - you can no longer access its sub-parts.
Kev