Wait that wasn’t meant to be sarcastic.
Not everyone knows getter methods for booleans are of isXXX() form. Not everyone is supposed to know we want to use instance() named methods instead of getInstance() for singleton classes… I meant we could mention that in the “Developers Infos” (and I really think it’s a good idea).
Woah calm down guy. 
EDIT : I think, we’re all getting a bit nervous these times… sorry man if you felt offended
Sorry, when I misunderstood you. Seems like I am a little shirty.
Well, It is the way the JDK/JRE goes. And it is Bean-compatible.
This instance() method is for example used in LWJGL. As far as I am concerned, we can stick to getInstace(). But it certainly is a good choice, if you find it too long.
Yes, we could. And I agree, that it is a good idea to mention some basic things in that aticle like this one.
Marvin
Hi, I’m finally back at JGO (logon issues)
I choose the name getInstance() because sometimes I also have createXYZ methods - get signals a invariant behavior between calls. Also this getInstance() method is static and thus does not conflict with a bean property.
Long method names serve also as a documentation - I prefer them over too short and meaningless names.
But I don’t want to start/continue any quideline issue - this post is just to explain the code (method names) that I had created.
Ciao Matthias
Welcome back :).
It wouldn’t even break bean compatiblity, if it wasn’t static ;).
I agree. So I’ll use getInstance() for this method in the loaders.
Thanks ;D.
Marvin
I’ve now added static getInstance() methods to all Loader implementations to make them usable as singletons.
Marvin
OK, cool, thanks.
But I think nevertheless that decisions like that should be written somewhere… if I know a bit as programmers work, if there’s a doc maybe they’ll read it (partly at least) if there’s nothing, they’ll do their work, no really matter how…
Just jumping in on this thread. I am seeing the following after having upgraded to the SVN base as of today.
Prior to this SVN pull, I was able to do the following, which worked but is no longer a valid call SURPRISE!!! :o.
org.xith3d.loaders.scene.Scene sc= new OBJLoader().load(name);
bg=sc.getSceneGroup();
I am now trying something like the example code
model = new OBJLoader().loadModel(demoFolder.getResource( myModel ));
java.io.FileNotFoundException: Untitled.mtl (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(Unknown Source)
at java.io.FileReader.(Unknown Source)
at org.xith3d.loaders.models.impl.obj.MaterialLibLoader.(MaterialLibLoader.java:87)
at org.xith3d.loaders.models.impl.obj.OBJLoader.load(OBJLoader.java:148)
at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:195)
at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:202)
at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:207)
Try something like this (please refer to the JavaDoc for more info, or ask):
URL myModelFolderURL = new URL( folderToModel );
model = new OBJLoader( myModelFolderURL ).loadModel( new URL( myModelFolderURL, myModel ) );
Where myModel is a resource name relative to myModelFolderURL.
I’m streamlining the model loaders and therefore porting all of them to the new loader base. This is why the previous usage isn’t valid anymore. But you can grab the legacy-loaders.jar (mentioned above in this thread) to use the old loaders. But it is advisable to use the new loaders, if your project is work in progress. I guess / hope, it is not too hard to port, is it?
Marvin
I’ll check, if the baseURL of the loader can always be safely retrieved from the given URL in loadModel( URL ). If it is, I’ll modiy the loaders to do it. Then you won’t need to set the baseURL of the loader and the call will work as you expected.
Marvin
Please recheckout SVN. I’ve updated the JavaDoc and made the loaders use the resource’s path as the basePath / baseURL. So you don’t need to set the baseURL or basePath anymore, if you’re loading from a URL of filename, just as it was before :).
Marvin
working…coooooll…thanx!!!
Hi,
I had a lot of work but Iam finaly back ^^
At first I tried to compare the Objectloader from Java3D with the one from Xith.
In J3D it is simple said load(xy) … returns scene -> attach it to the TranformGroup and it works
Xith now offers loadScene and loadModel. To compare it I use loadScene… and than I got an Exception:
java.lang.ArrayIndexOutOfBoundsException: 2
at org.xith3d.loaders.models.impl.obj.FaceList$Face.configure(FaceList.java:267)
at org.xith3d.loaders.models.impl.obj.FaceList.build(FaceList.java:206)
at org.xith3d.loaders.models.impl.obj.OBJGroup.build(OBJGroup.java:62)
at org.xith3d.loaders.models.impl.obj.OBJLoader.load(OBJLoader.java:165)
at org.xith3d.loaders.models.impl.obj.OBJLoader.loadScene(OBJLoader.java:270)
at org.xith3d.loaders.models.impl.obj.OBJLoader.loadScene(OBJLoader.java:307)
I don’t know how to handle this because I used only ‘‘scene = (Scene) ofl.loadScene(“test.obj”);’’ …there is nothing else…
I know that it works a few weeks ago… :-\
I’m tempted to say that it’s impossible : nothing has changed in the OBJ loader since then…
But just give me your model I’ll see what I can do.
Thanks… u helped me a lot
I cheked the exported files and it seems that I hit somthing weired … I compared the export with an older file
So the second export of the cube runs fine so far…
sorry begging for help unneeded 8)
Phew glad it finally worked. This type of debugging is particularly nasty.
There’s no problem asking for help, I prefer people who ask (unnecessary) questions than those who don’t say anything and go out saying Xith3D is crap because they don’t found anything There’s plenty for you, just ask
Welcome back :).
The loadScene() methods of the OBJLoader return an OBJScene, which extends BranchGroup. If you’re planning to load a model, which is to be inserted somewhere into the scenegraph, but not as root, then use loadModel(). The most important difference is, that it returns an OBJModel, which extends TransformGroup and is meant to be inserted as a non-root element into the scenegraph.
Could you maybe give me the version of the export, that produced this exception? Maybe I can modify the loader to throw a more readable exception.
Marvin
Hi Marvin,
works fine so far. Changing appearance like color or texture is the next test ;D … hope it will work …
I exported ist from Blender, but I don’t know what button I hit to cause this trouble… maybe this one with the edges ?!
So, loadModel and loadScene works so far… but stil got a problem with texturing.
I used getShapeNodes() but it returns nothing…
The loaded File is an Object-File exported from wings3D. I exported the selected cube.
getNumChildren returns 1. So there is nothing more than the cube. What’s the step catching the shape and change the texture oder material ?
Look at the org.xith3d.w3g.ModifyModels example, created especially for you (some convenience features added for that, ok texturing is not perfect, I know )