Model loader interface

Engines, Libraries and Tools Xith3D Forums
#1

In java3d, de facto standard for 3rd party loaders was Loader/Scene interface. It was designed to handle scenes - together with all extra info like lights, cameras, fog, etc. While it should work perfectly for complex 3ds scene, it was not used in most geometry loaders. getSceneGroup() and getNamedObjects() were only commonly used methods.

My idea is to create some kind of inteface for xith3d, which would focus on model loading - thing which is useful for games, instead of scene renderers/visualizers.

ModelLoader interface would expose methods for loading models from file/url (possibly more than one model per file). It would return a collection of Model instances.
[i]

  1. It is highly probable that application will like to create more than one instance of given model. In theory, model can be cloned using java3d cloning functionality, but it is not very intuitive as far as attribute/geometry sharing in concerned. Maybe some kind of explicit method like createModelInstance() would be better ? In such case, maybe ModelLoader can return collection of ModelPrototypes, which in turn can be asked for create Model instances (to avoid need to create first model with textures and all, if it is not needed at the moment)
    [/i]

Basic methods are more or less obvious - String getName, String getDescription, BranchGroup getMainNode, MapNode> getNamedNodes. We need to think what extra functionality can be exposed here, while staying generic enough.


2 ) I think that most common extra functionality, which cannot be easily described by just scenegraph alone is animation. Exposing any particular method of animation is out of question, but IMHO it would be possible to standarize on concept of Action. Action could be single animation, sound, particle burst - visualization of action. Model would expose methods Set getAllActions, void performAction(String/Action) and enqueueAction(String/Action). Difference between perform/enqueue would be that perform moves to new action almost immedietly (pending any transition animation), while enqueue adds it to queue to be played after currently playing actions end. Action interface would expose getName, isLooping and getDuration - looping means that animation is supposed to be played for longer period of time (walk/bored stance/etc).


3) There is a question of animation routine entry. In java3d, it could just add a Behaviour to scenegraph, which would be run automagically. With xith3d, manual management of updates is preferred. Probably adding method to Model like updateModel(frame_time, other params?) which would perform needed scenegraph updates would do the trick.


4) What with model LOD ? Should it be displayed in Model interface ? Separate getMainNode for various LOD levels ? Single node, with explicit control of LOD level ? Or just hide it inside Model implementation and let the loader code determine which LOD should be used ?


5) What with combined animations ? In some cases damage animation can be applied over walk/run/fight with given percentage. IMHO it is an overkill for common-ground interface, but it should be considered.


6) What with parametric actions ? Some actions are just on/off, some can require a number of parameters ? Real example would be fire tank gun animation, which would require rotation of tower in specific direction and performing fire animation. I think it is also too specific to put into this interface - let the application rotate the tower through named node and then call ‘FIRE!’ action (some kind of projectile will need to be created anyway).

Comments ?

#2

I’ve been waiting for this for a while, just wanted to say thanks for bringing it up… I’ll have a think and get back to you.

Kev

#3

Hi,

[quote]ModelLoader interface would expose methods for loading models from file/url (possibly more than one model per file).
[/quote]
I think the basic loading method should accept InputStream (maybe DataInput because of it is interface and then app can provide custom DataInput impl), or probably Reader for text-based formats, probably alone with some resource-inclusion interface to obtain data for included files/textures/etc. Then File/URL/Resource/ByteArray methods are trivial.

As of 1):
I think it would be great to separate model loader for 2 parts: a) engine-neutral file parser, that loads model to a kind of internal loader-specific format as fast as possible; b) scenegraph generator that will generate BranchGroup (or basically Node) from this internal format.

As of 2):
For me, this is becoming a layer on top of just rendering engine - this is more related to rendering/behavior loop. I see loader as just a loader, and animation mechanisms are much more format- and application specific. I think that multiple of animation mechanisms may co-exist and should be optional.

As of 3):
Potentially loaders may extend Node (or preferred Group and Shape3D). It is possible under loaders API to create AnimatedShape3D that extends Shape3D (similar way as it is implemented now for Morph node) and there define animation-specific params. My preference whould be to keep rendering engine separated from animation engine.

As of 4)-6):
As I told above, I see this very loader-specific. Basic animation needs only current time value to display its state, as well as ability to control the animation playback - just as any other media stream (sound or video).

So, for animations, I see something like this:

AnimatedShape3D extends Shape3D {
  long getDuration();
  void rewind(long pos);
  long play(long from, long to, boolean loop);
  void pause();
}

And may be this is enough?

Yuri

#4

OK, and for model-wide full-scene animations maybe Animation should be an interface implemented by AnimatedShape3D and series of AnimationController instances returned by loader, whic abies mentioned in 2) as Actions?

Yuri

#5

In some cases (especially binary formats), it is sometimes not possible to parse model sequentially. One option is to read everything to memory and the work from there - but this is quite heavy solution. Having RandomAccessFile/MemoryMappedBuffer can be beneficial IMHO. Please also think about possibility of having internal format which is directly usable from disk - just pass pointer to part of memory mapped file to opengl call.

Trick is, that in most cases scenegraph classes are just perfect containers for geometry/appearance data. Having extra step in between requires duplication of classes, plus creates some overhead in loading if you just want to display something.
Please note that with Model/ModelPrototype, loader author is free to split it into two phases - it is just not required.

And this is I think the main difference between how we see the loaders. I suppose you want to have just geometry/appearance loading, with all the rest being loader specific (thus requiring application to know exact details of loader implementation). I would like to stretch common ground to basics of animation/particle effects/sounds. I think about some kind of model browser, in which you can plug ANY ModelLoader, browse model actions, execute them and hear them - instead of just looking at non-moving textured shape.

Please remember that any way, for specific application, everybody is free to use any interface/model loading/details/etc they want. We are just talking about lowest denominator, common interface, here.

With just one kind of animation per object ? Or do you plan to put all animations in one long sequence and control it by giving the correct time bounds ?

#6

[quote]With just one kind of animation per object ? Or do you plan to put all animations in one long sequence and control it by giving the correct time bounds ?
[/quote]
The example above was given just to demonstrate the idea of representing the animation as another one media stream. So, transforming the idea to more generic way, we can add Animated interface with methods allowing to obtain references to kind of AnimationController interface (similar to that one described for AnimatedShape3D, so any node in SceneGraph can implement this). In such case any Node and even NodeComponent (say, ColoringAttributes) may implement such interface and can be controlled by external code.

Summarizing this, to control animations, say, we define 2 interfaces:

public interface Animated {
  public AnimationController[] getAnimationControllers();
}

public interface AnimationController { 
  long getDuration(); 
  void rewind(long pos); 
  long play(long from, long to, boolean loop); 
  void pause(); 
  String getName();
}

so the trivial implementation of Shape3D with single animation can be something like

public class SingleAnimatedShape3D extends Shape3D implements Animated, AnimationController {

// Shape-related methods go here

  public AnimationController[] getAnimationControllers() {
    AnimationController[] ctl = {this};
    return ctl;
  }

// Animation controller methods (play, rewind, pause, ...) go here

}

In such case we can define animated groups, shapes, etc., and viewer/application will be able to traverse scene graph in order to find all animated nodes if needed.

I agree that in most cases holding model data directly in SceneGraph objects is preferred. The idea behind dual-step model loading was that developers of specific loaders may develop most of the code in engine-independent way and then provide “compilers” for different engines. But in general I agree - this is up to developer how to build internals of the loader. For Xith3D is important only scene graph side.

Yuri