So I’m switching over to jME from Xith because of various reasons, and am still in the learning stage. Xith and jME are really quite different in philosophy it seems. As I’m reading all this code, especially in SimpleGame, I don’t understand the reason for many things. Why is it, for example, necessary to call various update methods? Examples include:
trimesh.updateGeometricState(0, true);
trimesh.updateRenderState();
and calling trimesh.updateModelBound() after a bounds object has been set.
It seems to me, and it is done in xith, that all these methods are unnecessary and are done within the code. Like, after you set texture attributes, they are set, and there’s no need to call an update method. Or when you give an object a bounds, the bounds are automatically calculated.
In Xith, each update has only one method that does everything: View.renderOnce();
Since in xith there is only one root node that is attached to a “universe”, and the view is attached to this universe as well, View.renderOnce() does in one line what jME must do in many lines.
I know there must be reasons for these design decisions, I would just like to know what they are, and don’t mean any offense.
Edit: Also, I have a suggestion for the jME starter PDF. It starts out first by showing various examples that use SimpleGame. As I’ve been reading through it, this method of explaining something while holding the fundamentals till the end causes confusion. I think it would be better if it started off with AbstractGame, moved on to BaseGame, then to SimpleGame, and only then to the specific tutorial examples that use SimpleGame.
First, calling updateGeometricState on a TriMesh won’t do anything (I’ll explain why in a minute).
I’ll explain what these methods do, but don’t really want to get into why we don’t do it like Xith. Never looked too deeply into Xith, so I wouldn’t be accurate in my comparisons.
updateGeometricState -
updates the world data (translation, rotation, and scale) from the point you call it on down. You can call this at any point in the scene graph, typically, at the highest point where something has moved.
updates the bounding volumes. If something has moved the parent’s bounding volume will grow/shrink to handle this change and contain the child.
updateGeometricState is typically called at the root and called when the scene graph has changed. But it can be called lower if needed to only update a branch if the others are unaffected by a node moving/rotating/etc.
updateRenderState -
http://www.jmonkeyengine.com/jmeforum/viewtopic.php?t=357 answers this question very well.
updateModelBound
update model bound calculates the bounds for the geometry it surrounds. So when you assign a bound it’s probably empty, calling this update method generates the bound values for you. You’d also call this if the geometry vertices were to change from animation or something.
In Xith, each update has only one method that does everything: View.renderOnce();
extend AbstractGame with your own and it can do that for you. We gave the user as much control as the want. For example, SimpleGame you don't call anything to render. BaseGame you do it yourself... you can set it up how ever you are comfortable.
We chose not to hide things from people.
To add to what Mojo said (was writing this when he posted, so sorry if repetitive…)
Many update methods are recursive on the tree and would be wasteful if called automatically everytime. Where this is not the case, we have tried to have update called automatically. Perhaps there is room for more of this but so far it has not been a big sticking point.
Rendering is a two line deal in jme (clearing the buffers and calling draw(rootNode)) if you follow the same scheme and use a single global root node. That said, we give the ability to have more than one tree which can make setting up certain kinds of scenes easier but of course has you call render on each tree you set up. I’m not sure how you find this more complex but I suspect you say that because of the additional lines in SimpleGame that facilitate the built in features such as stats and bounds drawing. Yeah, we could probably make the clearbuffers call somehow automatic, but that could be limiting to some uses of GL and is a one line thing. As Mojo said, you could easily extend AbstractGame and do this yourself.
As for the user guide, that’s probably just a matter of preference. I would consider being able to write a 10 line program to get a simple Box rendering a very gentle way to start for new users. Adding objects to the scenegraph, setting texture states, lighting, loading models, adding sound… those are what I consider fundamentals… As proof that the doc and SimpleGame work, once we had those two things jME new-comer questions definitely became more complex and insightful.
Thank you guys for your replies; it makes sense to me now 