I notice on the new dawn xith3d loaders page, the line "The following loaders are supplied externally to Xith3D but hopefully will migrate into the code base eventually." I agree, I think this would be a really good idea.

Kev and Jeremy, do you mind if I do put them in CVS? I would make them part of the toolkit which is distributed along side Xith3D.

I don't see any problem with this. Probably be nice to change the packaging (I assume that'd happen?). Its worth noting that the 3DS loader isn't fantastic for animation (see sooooo many posts on the topic :/).

I'm actually doing a Cal3D port for Java using Xith3D for the Gamma project.Maybe It can be included in Xith3D and then reutilised in gamma.Cal3D support really cool features : skeletal animation, animation blending...More informations on http://cal3d.sourceforge.net/Note : I'm not sure I can finish the port ( say, if it is possible, or realisable ), but it is a project.

Yes I know.A Java port has been made for Fuze3D, but it was the 0.8 version.I'm doing a port of the 0.10. However, I could ask the guys from ShortFuze to send me their code but...I don't know if it would save time.

One thing that always put me off looking into Cal3d was not being able to find any models for it. It seems like a great idea but a bit useless with out models. I know there are exporters for stuff like blender but my modeling skills are pretty useless really.

One thing that always put me off looking into Cal3d was not being able to find any models for it. It seems like a great idea but a bit useless with out models. I know there are exporters for stuff like blender but my modeling skills are pretty useless really.

Oh well sorry it's off topic.

Dan.

Yes, there is really a big difference.The biggest ( to me ) is that the Blender exporter work only from 0.9 version... And when another version of Cal3D is released, there is a good reason.You can convert any model into Cal3D, just open it in 3DS max, or in Blender and export it..You don't need to have modeling skills...

I don't see any problem with this. Probably be nice to change the packaging (I assume that'd happen?). Its worth noting that the 3DS loader isn't fantastic for animation (see sooooo many posts on the topic :/).

I think Jez made the AC3D loader available in Xith aswell..

The New Dawn Software loaders pull the texture files from the classpath. I tried to trick the loaders into pulling them from an arbitrary directory selected by the user by extending the classpath via URLClassLoader and some reflection by I was not able to get it to work.

Once this change is made, Whoola 3D Browser will be able to load file formats other than COLLADA and Whoola COLLADA Converter will be able to convert files from user directories using the New Dawn Software loaders. This is sort of a critical path for me so I would be happy to dedicate the time to move the New Dawn Software loaders into Xith if New Dawn and Xith grant permission. Once granted, I could do it within a week. I would then make the changes I need.

Please let me know if this is OK or if New Dawn Software wants to do this.

I don't see any problem with this. Probably be nice to change the packaging (I assume that'd happen?). Its worth noting that the 3DS loader isn't fantastic for animation (see sooooo many posts on the topic :/).

I think Jez made the AC3D loader available in Xith aswell..

The New Dawn Software loaders pull the texture files from the classpath. I tried to trick the loaders into pulling them from an arbitrary directory selected by the user by extending the classpath via URLClassLoader and some reflection by I was not able to get it to work.

We have some code to sort-of do this we wrote for Survivor, which I've been meaning to put online for about 12 months - it's designed so that you can drop files into a directory and they automatically override whatever is in your JAR files. IIRC it only works on directories that are relative to the classpath - but also IIRC this is the only thing that is physically possible in Sun's java (at lesat, it was back in java 1.2; things have changed in the ClassLoader impl since then, so maybe not any more). If you are having problems, it's almost certainly because some code somewhere is using instanceof - which *by definition* (although not really documented last time I looked, again could be updated by now) always returns false on things loaded by different classloaders - even if it's the same file.

You might also want to take a look at the source for the "arbitrary find and load any class anywhere on the classpath" class:

The "name" argument would be some identifier or path to retrieve the InputStream relative to a baseURL, classpath root, or user-selected directory. The other possibility is that it would be a cache identifier. Ideally, the loader would retrieve the InputStream using a filename without knowing whether the file was cached, pulled off of a website, on the classpath, or generated dynamically.

It would be almost exactly like com.xith3d.loaders.texture.TextureStreamLocator but only more generic. Is TextureStreamLocator something that was introduced to with TextureLoader2? If so, would it be sufficient to simply update the loaders to use TextureLoader2?

I am in the process of moving the 3DS, OBJ and MD2 Newdawn loaders in to the xith-tk shared CVS as planned.

I agree it would be nice to have some sort of universal resource loading method amongst all the loaders (at least the ones in the toolkit). Perhaps this functionality can be abstracted out, with the default being to load from the classpath.

Once the code is in the CVS, such changes will be possible. According to the governance of the project though, consent is desired from the original author(s) before changes are made.

What happened is that we now include the tools with the main distribution. Go download a copy of Xith3D, and it should be there.

Modularised? Each tool has it's own package. Each package has package level documentation stating what it's dependancies are. For example, if you write a tool A, you specify what other tools it depends on. This way, anyone should be able to cut out unneeded classes without trial and error. Most tools are self contained, certainly all of the current batch are.

The current roadmap sees many of Xith3D's non-core packages (e.g. ASE loader, userinterface) moved into the toolkit. The idea is then to foster better community development of non-core apsects, while keeping the core code under stricter quality control (i.e. developer and community review -- example, see recent texture loader changes).

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.

OK, here is my plan:

1. 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.

2. 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.

3. Post the source code on this forum for comment and corrections.

4. Commit.

5. Do the same to the other loaders (MD2, etc.).

6. 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.</evil>

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

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

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

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org