May I have permission to update them in the xithtk CVS? I would do so in gradual, incremental steps with the first objective being to allow loading textures from arbitrary sources.
Go for it! If you don’t have dev access, just apply.
May I ask what is your plan?
The way I see it some abstract texture providor would work well, with people free to code custom ones (for things like loading from a URL). We could probably build this in to TextureLoader2.
Will.
The last loader, MD2 has been added.
Thank you once again to Newdawn for these excellent loaders! The MD2 one is particularly impressive.
Regarding any modifications, it is of course always best to discuss proposed changes in the forum before making them, that way we can all review them and add our suggestions.
Cheers,
Will.
OK, I’ll study and propose here before committing.
OK, here is my plan:
-
Modify org.xith3d.loaders.obj.OBJLoader in project xith-tk to extend from com.xith3d.loaders.LoaderBase. Initially I would leave the original method signatures in OBJLoader as they are and just add the new methods from interface Loader.
-
Replace the use of TextureLoader in the loaders with TextureLoader2 at the same time, if required to get it to work. Otherwise, do it later.
-
Post the source code on this forum for comment and corrections.
-
Commit.
-
Do the same to the other loaders (MD2, etc.).
-
Create a super loader which can delegate to the other format-specific loaders depending on file type.
Step 6 was a problem in Java3D. The super loader interface is great if you’re assume that the object you get back from loading is always the same thing, i.e. a BranchGroup. However, alot of the geometry loaded for games isn’t static, people like animation, at that point you need some API for controlling the current frame and/or animation weights and positions.
You could introduce some sort of generic animation Controller type as with JME but from experience this suffers from the way to generic for the purpose problem aswell.
Still, the super interface is still worthwhile, just that things underneath have to be exposed aswell. Unless of course you just want to cast the object back to whatever the user is suppose to know it is.
Kev
I’ve hit a snag. The first OBJLoader load() method returns BranchGroup but interface Loader expects Scene. This causes an interface conflict when I extend OBJLoader from LoaderBase.
A quick fix is to change the return value in OBJLoader from BranchGroup to Scene by wrapping a SceneBase around the BranchGroup via SceneBase.setSceneGroup(). This changes the method signature of the load() method, however, which breaks pre-existing code. Application code would need to change load() to load().getSceneGroup() in order to get the BranchGroup.
I can either change the method signatures or create a new class called OBJLoader2 to do what I want to do. I prefer the former. Any objections?
Before you worry too much about com.xith3d.loaders.Loader et. al. evaluate how useful this interface is to start with.
AFAIK, no loaders, even the ASE loader which is in the core and was originally created by David Yazel, actually use it.
So if you think there are ways to improve the interface we can look at them.
I don’t think there is a problem with interface changes at this stage – nobody is using these loaders at the moment from the org.xith3d package anyway since they were only just added. The most important goal for now is having the best design possible 
Cheers,
Will.
I do, but a good design is more important and it won’t be a big problem to change the code. But I think when we want to improve the design, we’ll also have to think about Scene. As an example Scene got a function “getBehaviors()”, but in Xith3d we don’t use Behavior classes, or does anybody? And Scene hasn’t got a function like “playFrame(int n)” which we would need for animations.
I’m a big fan of sticking to the Java 3D API which is why I like implementing interface Loader by extending LoaderBase.
I use Behaviors, including Scene.getBehaviors():
http://cvs.sourceforge.net/viewcvs.py/whoola/core/src/com/whoola/core/media/xith/behavior/
Ah, OK. I will feel free to break as required. I’m going to go with interface Loader as it can load from a URL, Reader, or file. The capability to read from a URL is particularly handy as it can be used to find resources on the classpath using ClassLoader.getResource() which returns a URL argument. You can also use a URL to reference files via HTTP and the filesystem (file:/C:/…).
Wow they work!?! - cool - I always thought they would be there from the “xith to be as much Java3D like as possible”-times and I never thought, they were fully implemented - you know empty method stubs and stuff.
I had to write my own bits and pieces for what I needed for Behaviors.
OK, I was able to modify OBJLoader to get it to load from a baseURL. I tested using a baseURL that was pointing to the file system (file:///C:/Documents%20and%20Settings/…/shuttle.obj). It successfully loaded.
I committed it as OBJLoader2 so that it would not cause problems with people using OBJLoader and to make it easy to back out if necessary. Once finalized, we can overwrite OBJLoader and remove OBJLoader2.
I also created a MaterialLibLoader2 that uses TextureLoader2. OBJLoader2 uses MaterialLibLoader2. The changes to MaterialLibLoader2 were necessary since TextureLoader2 lets you load from an arbitrary URL.
I am going to continue working on OBJLoader2 and MaterialLibLoader2 over the next few days as I integrate and test with applications. Feel free to take a look and post comments:
https://xith-tk.dev.java.net/source/browse/xith-tk/src/org/xith3d/loaders/obj/
I am having trouble compiling org.xith3d.loaders.tds.TexMapProcessor. It looks like it is relying upon a previous version of com.xith3d.scenegraph.Texture.
Is this something that can/should be added to the core? A lot of people have been asking for this!
Will.
Good point. I agree.
Will.
Hmm what exactly is your problem (i.e. error message)? The TDS loader compiles here fine (thought I havn’t updated with your new changes yet).
Cheers,
Will.
Here is where I am hitting the trouble spot:
[javac] C:\external\xith-tk\src\org\xith3d\loaders\tds\TexMapProcessor.java:72: cannot find symbol
[javac] symbol : method getFormat()
[javac] location: class com.xith3d.scenegraph.Texture
[javac] if ((textureMap.getFormat() == Texture.RGB) && (context.transparency == 0)) {
[javac] ^
[javac] C:\external\xith-tk\src\org\xith3d\loaders\tds\TexMapProcessor.java:72: cannot find symbol
[javac] symbol : variable RGB
[javac] location: class com.xith3d.scenegraph.Texture
[javac] if ((textureMap.getFormat() == Texture.RGB) && (context.transparency == 0)) {
[javac] ^
I’m guessing the getFormat() method and the RGB constant were removed from Texture recently.
Yes. Let me ease into that one over time as I get more experience.