Looks good, Gregg. Although it feels a bit odd being mentioned in a presentation. I’ll be sure to get you that scenegraph demo before the end of the week. I definately see how it will help explaining the slides.
Hi Mark,
I don’t mean to make you uncomfortable and I can take your name out if you want me to.
However, I think jME is a very cool project with a lot of potential for showing what can be done with Java and 3D computer graphics, to things I’m rather passionate about. 
You started jME and you’re doing a good job of managing it’s evolution into a serious game engine.
I just want to give credit where credit is due. 
Gregg
Oh no, I just said it felt odd… not that I didn’t like it. I’m not that humble.
Howdy,
I’m looking at the Sound api, which is a first for me.
It appears that it is architected in the same way as the graphics renderer, in that it is specified by an interface, in this case, two interfaces, ISoundSystem and ISoundRenderer.
Then a platform specific implementation, LWJGL or JOAL, is instantiated by a sort of factory class, SoundAPIController, that contains an instance of and ISoundRenderer and an instance of ISoundSystem.
ISoundSystem takes care of playing or making the sounds and ISoundRenderer takes care of connecting the sound to the Scene Graph.
This makes the sound system pluggable like the graphics rendering system.
Are any of these observations correct?
Thanks,
Gregg
Yes, that’s correct, the sound system is set up almost identically to the graphics system, just when the “rendering” occurs a sound is played rather than something drawn to the screen.
Gregg, I added a Test: jmetest.renderer.TestSceneGraph that demostrates the interaction of the node branch with translation and rotation. 1-6 selects a specific node, mouse or arrow keys rotate, w,a,s,d translates. Let me know if this is they kind of demostration you were looking for. I’ll start on another one that demonstrates how render states work. I’ll also get the scene graph demo on the demo web page soon.
We have an abstract class called Controller. It looks like all of the Controller derived sub-classes have something to do with animation.
If this observation is correct, is it also correct for me to combine the topic of Controllers with Animation in the presentation? Or is there some other use for a Controller class?
We also have InputController but it isn’t derived from Controller. Oh yeh, and AbstractInputController, which I blessed us with and probably should be reconciled with InputController at some point.
Anyway, to reiterate, is combining the topic of Controllers with Animation going to correctly convey the intent of Controllers.
Thanks,
Gregg
The base class Controller defines any time based alteration of the scene graph over time. So, it’s much more general than just for animation. It can be used to increase the fog values over time, it can be used to animate a model, it can be used to translate a node. For instance, there is also a CurveController that moves a node along a Bezier Curve.
Yeah, InputController and Controller are not related… little naming issue there.
Ok, Gregg. Updated TestScenegraph, now you can choose a node 1-6 (the selected node is highlighted), pressing 8,9,0 will change the texture of the selected node (an it’s children). This should show off how the relationship works for render states. Let’s call this version 1. What else would you like to see for your demonstration?
Thanks dude. This is a big help.
I think I’m good to go for everything else. I’m almost through the architecture part of the presentation, which is the bulk of it.
I believe I might be ahead of schedule, I like it when that happens. 
Gregg
Howdy,
Is setting the render state to null on a node the way I should clear it from the node?
If it is I’ll need to add a check for null on the parameter to Spatial.setRenderState.
Thanks,
Gregg
I don’t believe that will work.
Is there a way to clear a render state on a node?
Maybe a clearRenderState? Or am I confused?
Gregg
Good point, I’ll look into this tomorrow. You can’t set it to null, because it uses the passed state’s type to set it to a particular index. I know just want to do though, and I’ll put in the test first thing in the morning. However, I did add a quick fix and it’s in CVS.
You’d do the following:
spatialObject.setRenderState(texture);
//now we don’t want it.
spatialObject.clearRenderState(RenderState.RS_TEXTURE);
I’ll test to make sure it works in the morning.
Ok, test is now using the clearRenderState method. Use the 7 key to turn off a particular render state (in the test’s case Texture). So, if done at the parent level, texturing will turn off, if done a lower node, it will inherit the parent’s texture.
Very cool, I’ll check it out tonight when I get home.
Thanks,
Gregg
I’ll be out of town until Sunday.
I’ll have the presention done by then. When I get back I’ll post it for review and critique.
Gregg
Howdy,
Here’s the current presentation.
I don’t give it until Thursday so there’s still time to make changes and corrections to it.
http://www.synthaworks.com/jme/presentation/IntroTojME.pdf
http://www.synthaworks.com/jme/presentation/IntroTojME.ppt
If you see anything that needs to be changed or corrected just let me know.
Thanks,
Gregg
Looks real good, Greg. Where there is a screenshot of a demo, will you be showing a live version to the group? Also, are there any other demos you’d like to show off? (Perhaps something with our new torus, etc. or visible bounds.)
Thanks.
I’ll be showing the corresponding demo for each screenshot in the presentation.
I haven’t had time to investigate all the new demos yet. I will before I finalize things.
Gregg
Howdy,
I just got back from the Fort Worth JUG meeting. It went very well!
I want to thank all of you guys for contributing the very cool demos and game, and for all the hard work that went into them. The apps made all the difference and I had fun showing them.
Thanks again,
Gregg