Okay I started adding the code for handling compiled branch graphs using display lists. Two questions:

1> Is there anyway to know that a card is going to have issues with display lists and therefore automatically disregard the programmers decision to use them?

2> On my GeForce 4ti 4600 When I use display lists my processor usage goes up slightly when compared with not using them. Is this what should be happening or am I doing something wrong?

Another unrelated question: Should I plan for automatically using the advanced features (OGL extensions) of different video cards? For instance NVIDIAs pixel shader extensions if they were applicable in certain situations.

I'm having some difficulty getting my head wrapped around the lighting for the scene graph. There doesn't appear to be any limit to the number of lights used in the Java3D scene graph but OGL does have a limit.

The lights in J3D have a InfluencingBounds object in them that tells J3D to only light objects with a particular light if the objects are inside of the bounds of the light. How would one go about implementing this with OGL?

In OGL it seems that an ambient light source has to be tied directly to a specific GL_LIGHTi instance. This being the case what exactly is the purpose of the glLightModel function? Can someone either point me to a dummies guide for OGL lighting or explain how the GL_LIGHTi and glLightModel function together? I simply don't get it.

GL is 8 lights minimum, per primative. So if you've got active bounds setup for each you can find the influential lights for each object/poly group, and set those as your GL lights. All fine until you get >8 per object, at which point I guess you'll be either choosing the 8 most influential (based on brightness/type/location) or doing some sort of multipass to add them all together.

Just to complicate things, some graphics cards support more than 8 lights (GeForce cards I think are at least 16), and some cards while supporting 8, get drastic speed drops if going over (say) 4 - dropping back to software T&L I guess. So you'll probably want to make the actual number of GL lights settable though code.

One thing that I heard mentioned a while ago was LOD'ing lights - numerous small lights being clumped together into one larger light at a distance. For example, a table with lots of candles on could probably get ~16 lights close to, but reduced to 2 or 3 lights at a distance.

The glLightModel is to do with how the specular lighting is calculated. Unless you're doing a parallel projection, then it'll almost certainly be better off set to a local eye (isn't there something like this in J3D? Local eye vs. infinate eye, if i remember correctly).

Okay, so it looks like I need to turn lighting on/off per object rendered based on if the object is inside of the InfluencingBounds of the light.

Seems like that would have really strange effects on the rendered scene as every object isn't going to be effected by every light. However the material for the object has the same effect I guess given that if it is null the lighting is disabled for that object.

I'm kind of stuck, I've done all of the grunt work of getting the classes in place but I'm having a terrible time finishing the last 1-2%. I really need help or this is going to take me forever to figure out.

1> Transform3D class needs about six methods filled in.2> Once #1 is done I can put the use of the TransformGroup class into the SimpleRenderEngine class. It is being ignored right now because the Transform3D isn't finished. This is really just a matter of putting pushMatrix/popMatrix calls in the right place.3> BoundingBox, BoundingPolytope and BoundingSphere classes need the intersect*/combine*/transform* methods filled in.4> Lighting, I'm working on figuring out what the best way to handle rendering the lights would be.5> Transparency, which if I'm understanding things correctly is dependent on the lighting being finished.

Basically since I have no experience with OGL and my math skills are crap I'm having a tough time of it. You can build a graph and create a scene but it is useless with out the above items being finished.

So if anyone is interested in helping out please let me know. You can get me on YIM most days if you want to talk to me directly.

Okay I've decided to change the Transform3D class in this scene graph to be a fair bit different from the one in Java3D. There will be a number of methods from J3D missing and a number of new methods. This will allow me to move forward to a point were people can start using the thing.

At this point the geometry/lighting set up of the scene graph will work basically the same way that J3D does. However I'm discarding the notion that you will be able to directly port an existing complete J3D scene graph to this scene graph.

There is simply too much stuff in J3D for a single person to replicate, and it is nearly impossible for me to infer what J3D does under the covers. Also I don't have the knowledge (not even close) that the J3D designers have. So I want to get something out and then evolve it based on feed back and hopefully help from others.

How much interest is there in me getting a first alpha out for people to use?

We are generating a customized shape with a fairly intensive process that does some special normal smoothing and level-of-detail generation. Then we save the generated shape. Takes about 15 minutes to do the processing, and about 26 MB to save the generated BranchGroup to a file.

At game initialization time we load the pre-generated shape. Right now we're using Java3D to do this -- takes about 16 seconds to load the 26 MB generated file and recreate all the scenegraph objects.

If I didn't have Scenegraph IO I wouldn't be able to use this pregenerated model, which is crucial for our game, so I wouldn't be able to use the Scene Graph API and LWJGL.

Okay well, I can tell you knwo the the first alpha deffinately won't have IO abilities. I guess that should go on my list for alpha 2. I wonder if what I'll have will be able to support something as complex as you are talking about any way. Odds are it will take a fair amount of time to get to the level you require. Baby steps.

The framerate of the house sample drops below the synchronized 85hz and is somewhere around 70fps on my quite fast machine. Is there a special reason for that?

The whole thing is terribly slow right now. The SimpleRenderEngine doesn't do anything to optimize the rendering. It just traverses the graph and renders what it finds, I had to start somewhere to get a clue about how the thing should work. There isn't even any culling of non-visible vertices.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org