Okay well to help get myself up to speed on the 3D/OGL/LWJGL stuff I have decided to write a scene graph library for LWJGL.
But before I start I want to know if one already exists, I don’t want to duplicate effort. If there is already one out there then I’ll find another way to get myself going.
I’ve got a little framework for pumping triangles of different states in the right order in com.shavenpuppy.jglib.renderer.*
That’s probably one of the first, deepest, bits of a scenegraph.
Cas 
Giggle It’s interesting the different ways people think about problems. You, at least in this case, seem to think in a bottom up manner. I tend to think in a top down manner.
It would not have occured to me to start were you have suggested. This code you mentioned is at SourceForge somewhere? Could you post a link to it? Also I don’t suppose you have any simple examples that show it being used so I can avoid going down the wrong path while trying to incorporate it?
EDIT: typos
EDIT2: just found the link
EDIT3: however there are no release files in the project 
Muhahaha, another confused LWJGL developer encountering the SPGL! ;D
SPGL is more of a technology dumping ground than a client library, from what I can see. Cas reserves the right to break it at any time, and I personally doubt there’ll ever be a formal release from it. That’s not what it’s about, at least not at the moment.
But don’t let that disuade you - there’s some fascinating stuff in there. Grab a CVS client and pull the code directly. Think of it as a nightly build… ;D
Thanks for the tip. I’m making good progress on the scene graph lib. Thanks to the fact that I’m basing it on the Java3D scene graph. I’ve been doing an awful lot of reading as I’m sure you can imagine. Especially since I really haven’t had any previous 3D experience.
If the code Cas has fits the model I’ll just rip it out and put it in my packages so it doesn’t get broken in the future if he needs to make a change.
Currently, in my scene graph code, for methods that require a point or points be passed into them I’m using the Vector3f class from lwjgl. Was wondering if this would confuse people and if I should make another class named Point3f for this purpose. Then only use the Vector3f class for methods that really need a vector.
Any opinions?
While some might consider it unnecessary “syntactic sugar”, I personally prefer it. If it’s a point, call it a point. If it’s a dimension, call it a dimension. You use a bit more memory for another couple of class files, but it makes more sense IMO.
A point is a point and a vector is a vector. 2 different things that accidentially have the same members. Why not going the vecmath way and deriving Point3f and Vector3f from Tuple3f?
In the end, it is very practical that Matrix4f#transform() can treat them differently.
Okay, looks like I’ll have to change the stuff over to Point3f. Two votes for that no votes for the other way so Point3f it is.
Last night was fun I got all the primitives rendering via the scene graph classes. Nice to see the code actually DO something.
LineArray
PointArray
QuadArray
TriangleArray
Of course they are only using the vertex colors and vertex coordinates right now but that will change soon. Need to get these working tonight.
LineStripArray.java
TriangleStripArray.java
TriangleFanArray.java
Found a link to a nice overview of scenegraphs today on flipcode:
Yep, that was one of the first things I read before starting this project. Thanks for pointing it out though. Any other resources you find please let me know.
Inventor, OGRE, OpenSceneGraph, …
I once tried to do a scenegraph in C++ on top of directX. But I failed. I wanted to embed render states directly as nodes (e.g. have TextureNode); to do the sorting, LODing, … and rendering all in a single graph traversal… too much at once.
In the end, the complex copy and reuse patterns of subgraphs killed me. If I only had a GC…
Just curious, did you consider it a failure because it was too slow in the end or because it was simply too complex to finish because of all the memeory allocation/deallocation?
I suspect that when I get the first version of this up for people to look at it will be WAY too slow for practicle use. However I’m hoping people here can help me with algorimths to speed up the rendering then we can all use it.
Do you have any intention of making your scenegraph API more-or-less compatible with the Java3D API? It would certainly make it easier for those of us who are currently using Java3D to switch over to a LWJGL-based scenegraph if/when it makes sense.
It would be great to get better performance, smaller footprint, etc., if it didn’t require a rewrite of the entire scenegraph and didn’t obliterate the other advantages of using Java3D.
Even partial compatibility would be better then incompatibility. I am fine with replacing all j3d.Point3f’s with lwjgl.Point3f’s if the interface is fundamentally the same.
And if it isn’t the same, then why not? 
But keep up the good work – Go trailblazers!
With respect to points and vectors: I found it immensely irritating that the designers of J3D decided that points and vectors are different things and have different methods.
This isn’t how it works in maths. A vector is a point is a matrix.
There is in truth only one kind of thing, and that’s a 3-tuple, and we called them Vectors because that’s their most common use.
Cas
Yes, the plan is to have a scene graph that is used in a way almost identical to Java3D. The package names will be different of course but I’m trying to keep the following as close as possible:
class names
class heirarchy
method names
graph layout (same child/parent relationships allowed in J3D)
There will be a few changes.
First I have, up to this point, left out methods that take primitive arrays for things like Vector coordinates. In the initial version you would use only methods that take arrays of objects.
I haven’t come to a firm decision yet but I don’t think I’ll have a Universe object. You will simply pass any Locale graphs into the renderer to get them on the screen. Also Locales use floats instead of the HighResCoords that J3D uses. My rationale for this is that with the exception of really advanced games like true flight sims the rounding problem won’t be that big of deal. If it turns out to be then I/we can add a new Locale type that uses higher precision coordinates.
In J3D it appears that the renderer is started inside of the Universe the instance you attach a Locale with a sub-graph. This keeps you from be able to make a renderer that is most efficient for you particular needs. I plan on supplying a few different renders that handle the scene graph in different ways to allow better performance based on the type of scene be rendered. Obviously you will be able to create a new renderer if the supplied ones don’t fit your needs.
Since this scene graph is ONLY going to work with the LWJGL OpenGL binding it will be much much smaller than J3D. What is J3D now, 7 megs for the SDK and runtime? 
Yeah, this will be smaller.
It should be easy to port to other graphics libraries though.
EDIT: Keep in mind before I started this I really didn’t have any 3D experience. So some of the choice I make may be completely wrong.
[quote]With respect to points and vectors: I found it immensely irritating that the designers of J3D decided that points and vectors are different things and have different methods.
This isn’t how it works in maths. A vector is a point is a matrix.
[/quote]
I cannot agree with that. A point stands for a certain location in space whereas a vector is a direction that has no certain origin and can be located anywhere. That’s also how mathematics and physics handle these items.
A thing like a position is very different from a thing like speed. A think like a vertex coordinate is very different from a thing like a normal.
And for they transform differently (applying a translation to a vector absolutely make no sense), they have to be treated differently.
Libs that ignore the difference have sometimes very ugly code when it comes to transform normals…
No no, in fact is was VERY fast! No allocations after setup at all.
Judging from today, I over-simplyfied things. Nodes just had a render() method and the graph was meant to be traversed just once during rendering.
I wanted the perfect solution just in the one scenegraph structure. Means it should be able to do the material sorting, culling, reuse of everything, LOD, …
Additionally I wanted to use both, heap and stack allocation for objects of all kinds.
Now, as I look to existing scenegraphs, they are by far more complex. Event systems percolating changes up and down the graph, separate structures for rendering, dynamic memory management.
I’m afraid I have to admit I was just not good enough.
Another reason was that I had time. So I designed, threw away, designed again, discarded it, … very painful.
There was good info on that topic today on the J3D mailing list. Sounds complicated.
Damn low-level 3D stuff…
Largely about to become obsolete with the advent of ARB_vertex_buffer_object.
In reality what Mark Hood’s said there is not strictly true. The biggest vertex buffer you’re ever likely to find will only hold 16 vertices in it. On T&L cards this is held on the server side; on non-T&L drivers this will be on the client side, if it even has one, and there may still be a small vertex cache on the serverside.
Then you’ve got the option of calling glDrawRangeElements which basically works out the best strategy for you and should be as fast or faster than any cleverness on your own part; and if you can’t call that you may be able to call glLockArraysEXT which is a more brute force approach to the same problem.
The whole idea is to avoid repeatedly transforming geometry and repeatedly copying geometry from one memory location to another and to minimize the amount of geometry that’s got to be copied over a bus and to use the fastest bus there is to do it. Complicated? Nah
Talking out of my arse and confusing AGP DMA buffers with post-transformation cache. What has the world come to. Take no notice of me.
Cas