XIN Tutorial

[cylab]

The loaders base does exactly what you describe in point (2.). And I definitely prefer this way. It is an advancement and generalization of the old / current org.xith3d.loaders.scene loaders base.

As I said this option is fast and simple. The only real advantage would be offered by option (1), where you can mix and match different Producers (or Builders ) without the user knowing anything about different model/texture/sound types. This would also prevent different inconsistent Loader classes, since the usage pattern is given by the API (the actual XXXFactory) and all concrete implementations are forced to use the interface offered by the SPI.

Also I think it is substantial to have good support to load from the ClassLoader.

TextureLoader can theoretically load from an InputStream through TextureStreamLocator. But one had to write an implementation for it. Some time ago I wrote one for zip inputstreams, which is very similar.

Yes, it’s possible to use getResource() to retrieve an URL and pass it to TextureStreamLocatorURL, but this won’t deal with the structure of the classpath (multiple jars/directories).Since it is easy to write an own TextureStreamLocatorClasspath, that overcomes this, I think it would be beneficial to adapt that scheme with other loaders, too.

And org.xith3d.loaders.base.Loader has six methods to load. three to load the file as a Model and three to load it as a Scene. One of each three takes an InputStream, which enables you to easily load from classpath. It is up to the loader implementer to corretly implement these methods.

At this point a general ResourceLocator could tighten the interface, since the InputStream retrieval is shifted to the ResourceLocator, so only resource names are needed to load a resource. Also it would allow for further optimization of the name<->stream mapping and resource access would be generalized for all kind of Loaders.

btw. I don’t like the naming of Factory or Producer or things like that for Loaders. They don’t produce a model, but load it

Yeah Producer is wrong, Builder would be better, since it would be an (simplistic) incarnation of the builder pattern. For me however everything that creates an Object is a Factory…

Anyway Loader is fine. They should just all behave the same and share as most base functionality as possible.

Mathias

[Qudus]

@cylab

As I said this option is fast and simple. The only real advantage would be offered by option (1), where you can mix and match different Producers (or Builders ) without the user knowing anything about different model/texture/sound types.

Well, the user does know exactly what kind of data he is loading, since he’ll have to handle the returned object corretly.

@cylab

At this point a general ResourceLocator could tighten the interface, since the InputStream retrieval is shifted to the ResourceLocator, so only resource names are needed to load a resource. Also it would allow for further optimization of the name<->stream mapping and resource access would be generalized for all kind of Loaders.

Yes, maybe.

@cylab

Yeah Producer is wrong, Builder would be better, since it would be an (simplistic) incarnation of the builder pattern. For me however everything that creates an Object is a Factory…

Well, it is not simple object creation. Otherwise I would concede to you. Loader is just fine IMHO. Of course there’re objects created, but in fact everyone will understand, what a loader does, when he expects it to load a model / texture / sound. And of course an object holding the model (e.g.) is the result.

So I wouldn’t depart from the XXXLoader naming scheme.

Marvin

[eMKa]

I agree with Marvin.

The only things the “Model” (MD2Model, CalModel or whatever) should conform to is to :

• Display the first frame of anim if that’s an anim even if you haven’t called any function after load
• Extends BranchGroup or provide a branchgroup containing the data

And we should be able to load a “model” (huge abstraction here) of whatever type with a single generic instruction so a “basic” model loader is really straightforward.

I think we could provide a function which returns an icon of the 3D model file.

It would :

• Load it
• Compute its sphere bounding box
• Create a scene with a Camera at the right distance so you see the whole model on a e.g. 48x48 canvas
• Render an RGBA image of it

That would be most useful in games.

[Qudus]

@Amos Wenger

The only things the “Model” (MD2Model, CalModel or whatever) should conform to is to :

• Display the first frame of anim if that’s an anim even if you haven’t called any function after load
• Extends BranchGroup or provide a branchgroup containing the data

org.xith3d.loaders.base.Scene does extend BranchGroup while org.xith3d.loaders.base.Model extends Group.

@Amos Wenger

And we should be able to load a “model” (huge abstraction here) of whatever type with a single generic instruction so a “basic” model loader is really straightforward.

org.xith3d.loaders.base.Loader does exactly this.

@Amos Wenger

I think we could provide a function which returns an icon of the 3D model file.

Cool idea.

@Amos Wenger

It would :

• Load it
• Compute its sphere bounding box

This is done by the extended Group or BranchGroup.

@Amos Wenger

• Create a scene with a Camera at the right distance so you see the whole model on a e.g. 48x48 canvas
• Render an RGBA image of it

I guess, this would be better nested in a loader utility class.

Marvin