[JAVA3D] possible improvements

[Michael Nischt]

Java is great and also Java3D is, but nothing is perfect right ?
So I hope to start a heated controversy on possible improvements for the Java3D API.

1. SUN's utility packages:
Neither the Loader interface nor the TextureLoader are usefull when the source is an InputStream.

Why InputStream compatiblity is needed ?
Many game formats like the Quake 3 Arena one use a renamed zip-file for storing the data. Java's ZipFile class provides only an InputStream for reading, which is of course sufficient. Unfortunally standard j3d utilities can handle this and I don't want to unzip the data into an temp directory, which I guess even isn't possible using an unsigned Applet.

A possible solution would be to modify the loader interface accordingly:

interface Loader {
       public Scene load(String file) throws Exception;
       public Scene load(URL url)   throws Exception;
       ..
}

interface IOLoader extends Loader {
       public Scene load(InputStream in) throws Exception;
}

Note: I chosoe to throw an normal Exception, because now implemting classes could chosse their own Exceptions. Some loaders want to use RuntimeExceptions which needn't to declared as thrown, some not,...


TextureLoaders may be written for each Format:

interface TextureLoader {
       public Texture load(String file) throws Excpetion;
       public Texture load(URL url)   throws Excpetion;
}

interface IOTextureLoader extends TextureLoader {
       public Texture load(inputStream in) throws Excpetion;
}

class TGALoader implements IOTextureLoader {
       ..
}

Finally a TextureManager could be written wich combimenes the differents TextureLoaders..
    


2. Pure Immediate Mode:

Please don't blame me, but it a fact that most game-developers prefer programming in pure immediate mode. O.k. Most Scenegraph APIs are aren't designed well (compare DX retained mode).
Neverless the main reasons are the flexibilty and the knowledge about 'what is excecuted at the time'.
IMHO Java3D's scenegraph is great, but that's no reason to neglect the immediate mode.

Intersection Example:
I think an Intersection package containing the following classes:
Ray
Segment
Plane
Sphere
Cylinder
Triangle
Box
- AABBox
- OBBox
Frustrum
..
which provide Geometry Information, and an additional class  'Intersect', with methods:

public static boolean           rayAndSphere(Ray r, Sphere s);
public static IntersectInfo   rayAndSphere(Ray r, Sphere s);
..

where IntersectInfo gives detailed information about the intersecting point / area.

So this classes could be used in immediate mode and of course intern for the Scenegraph.


Collsion Example:

This is more comlicated, because depending on the application differend kinds of collision systems can be needed:

One approach for Collision Detecting and Response can be to generate static/dynamic Collison-Trees, which wraps ervery primitive into an BoundingBox for retreiving the insercting point/area (Intersection package). Now torque, .. can be computed (may a physic package can be helpful).

Another one could use rays for testing future intersections, before happening..


Tutorial Lack:
With the demo directory containing only one example for using the pure immediate mode, many people will get frustrated. For Example I found no way to use an OffScreen Canvas, which I still hope is possible to manage.


3. Behaviors:
I would like to write my own Behaviour conditions, instead of putting them into one triggering on time, frames,..




Any other ideas for improvements or comments on mine ?

greetings
 -Michael Nischt