Scene Graph

[zparticle]

Thanks a lot, that helps very much.

[zparticle]

Things are coming along very nicely. I might have a first alpha available by Friday.

Is having GL.ALPHA_TEST enabled with an alphaFunc of GL.ALWAYS the same thing as having GL.ALPHA_TEST disabled?

[cfmdobbie]

Is having GL.ALPHA_TEST enabled with an alphaFunc of GL.ALWAYS the same thing as having GL.ALPHA_TEST disabled

Yep, sounds about right!

In case you're interested, Redbook says the default settings are effectively:

1   2

gl.alphaTest(GL.ALWAYS, 0) ; gl.disable(GL.ALPHA_TEST) ;

Games published by our own members! Check 'em out!

[zparticle]

Okay some stupid little screen shots of this thing in action.

http://www.scottshaver2000.com/temp/shot1.bmp
http://www.scottshaver2000.com/temp/shot2.bmp
http://www.scottshaver2000.com/temp/shot3.bmp
http://www.scottshaver2000.com/temp/shot4.bmp

These show different combinations of Appearance NodeComponent properties being turned on/off. The last one is basically the first one with a marble texture.

There are 13 cubes.

[zparticle]

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.

[edit] http://www.reactorcritical.com/review-geforceshaders/review-geforceshaders.shtml This is a pretty good article about the NVIDIA pixel shaders in OGL.

[vrm]

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?

strange, sound wrong for me

[cfmdobbie]

Yeah, with display lists the hardware will be pulling data from internal storage but the processor should be doing less.

Could the processor be working harder because it's not having to wait on the hardware any more, and getting more done?

[zparticle]

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.

Thanks in advance.

[Orangy Tang]

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).

Hope that helps

[zparticle]

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.

Games published by our own members! Check 'em out!

[cfmdobbie]

Scott, any word on a first alpha release?  Want to start playing...

[zparticle]

Scott, any word on a first alpha release?  Want to start playing...

Close and not close.

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.

[vrm]

any idea about the planed license ?

[zparticle]

Probably the same one LWJGL uses. In any case nothing that needs to be paid for or that you couldn't use in commercial or personal projects. It's for everyone.

[zparticle]

Do people see having the ability to read/write a scene graph or portions thereof as a requirement?

[Herkules]

I don't think its urgent.

Typically a scene graph is constructed from a custom format like 3DS. For games, it is unlikely that an active graph has to be saved.

If you start to create tools, .....

But still then, scenegraph IO has limited value.

[zparticle]

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?

[GKW]

I am interested.

[bmyers]

Scenegraph IO would be a requirement for me...

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.

Just my personal $0.02...

[zparticle]

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.

[zparticle]

I'll have an alpha up on Monday April, 28th. I would put it up today but there are a number of things I want to get in this weekend.

[zparticle]

Okay well it is slow and many pieces are still missing, for instance lighting doesn't work yet but here it is, call it alpha 1 of LWJGL-SG.

http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_api.zip - The javadocs, such as they are
http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_src.zip - The source code
http://www.scottshaver2000.com/files/lwjgl_sg/lwjgl_sg_bin.zip - Everything you need to run the examples

[EDIT]
I run on Win2K so if you use LWJGL on Linux replace the library file in the lib directory.

[Herkules]

Ok, examples seem to work.

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?

[zparticle]

Ok, examples seem to work.

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.

[Matzon]

nice - works fine!
you've been very productive - shitload of code, and nicely commented (for the most part  )

Keep up the good work

[psiegel]

It's been quite on this topic lately.  Hard at work, or is the project losing interest?

[zparticle]

Things have got a bit busy at work and I haven't been real motivated by the time I get home.

I would assume nothing usefull will come out of this for a long long time unless I get some help. Sorry.

[GKW]

I am interested in this scenegraph and I would like to help right now but I have my own project that is woefully behind schedule.   Maybe in a couple weeks I will provide some help.

[psiegel]

Yeah, while I feel like this is a pretty important project, I don't have an immediate use for it and have too much on my own plate to really help out.  It's a sharme though.

Well, at least we know where it stands.  Perhaps I will grab the source you've posted so far and file it away for possible future development.