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.
Cheers,
Will.
Edit: added URL
And why don’t put one of the 3DS loader, and the MD2 loader, too ?
yes that was the plan, sorry I meant to link to the page I was talking about.
Will.
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…
Kev
cool, yes I would repackage it.
Is MD2 your recommended animation format?
Will.
MD2 is simple and works well if you can get your models into that format. For keyframe its really just fine.
What we could really do with is a full featured milkshape loader. I know its heresy, but supporting the .jme format in a loader might save alot of hassle and leverage the work being done over there.
Kev
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.
Sorry slightly OT.
I believe that some work has neen done on Cal3d at this site
http://www.shortfuze.co.uk/shortfuze/template/Index.vm
It might be worth checking out.
Dan.
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.
ah is there a big difference then?
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… ;D
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…
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.
To take the next steps with Whoola 3D Browser and Whoola COLLADA Converter, I need to be able to modify the New Dawn Software loaders so that they load from some arbitrary location supplied by the application such as a URL or a user directory. It would be nice if the location was provided by an object implementing an interface so that the application could use a cache. Here is an example interface:
http://cvs.sourceforge.net/viewcvs.py/croftsoft/croftsoft/src/com/croftsoft/core/util/cache/ContentAccessor.java?rev=1.3&view=auto
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.
Which of the loaders are you refering to?
The AC3D Loader at least accepts a texture path, which is relative to the model path.
Endolf
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:
http://javagamesfactory.org/views/view-sourcesnippet?id=1
It only searches the classpath, but finds all: files, JARs, ZIPs, and extracts the class names that are hiding within them and instantiates those classes (if requested).
I would like to start with the OBJ and MD2 loaders since I have models in those formats.
Here is a revision to my proposed interface:
public interface InputStreamOpener
{
public InputStream open ( String name ) throws IOException;
}
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?
Unfortunately I need to be able to pull the files from an arbitrary URL in the case of the Whoola 3D Browser or a user-selected directory in the case of Whoola COLLADA Converter.
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.
Will.
What happened to the plans for making this:
?
Apologies if some of the above are incorrect, I can only vaguely recall what was suggested 
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.
As for information to developers of Xith3D tools, this page exists (accessed from the “Docs” link) to tell them what to do: http://xith.org/XithToolkitContributions (see also the guidelines).
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).
Regards,
Will.
As far as I’m concerned, since the newdawn loaders have been released to the Xith codebase proper you can do whatever you like to them.
I’d hope the new versions in XithTk become the reference point rather than the newdawn site and hence the new updates will be available to everyone.
Kev