RenderStates

1

I had a look into the render states and I'm about to do the following:

  • Edit - rubbish: (Geometry.states seems to be just wasting space -> replace by render states of Spatial)
  • initialize Spatial.renderStateList to null, allocate when first render state is added
  • store states that differ from parent state only
  • use ArrayList instead of array, provide access to renderStateList only with getters (by render state class and by index for iterating)
  • improve extract methods (e.g. in lightstate) to avoid unneccessary creation of states (this should speed up rendering, too)
2

Whoa, hold on a bit.  There is a purpose for each of the arrays that currently hold RenderStates.  They are not redundant  Geometry's states are the actual states set by the programmer on a Geometry object.  If you get rid of this, there is no way to tell what states were set on the object, what states are inherited from above and what states are default.



Let's go over this a bit more before jumping on it.  We spent a long time crafting it to its current form based on correct functionality.  I'd like to see us reduce more memory, but this is an area where we need to use caution and lots of testing.

3

Just to be clear, I think you have some good ideas there but without gaining a deeper understanding of how the current system works, it will be hard to implement those ideas without causing problems.

4

Oh  :-o, you're right.

But don't panik I would have noticed I when starting to work on it :). Unfortunately I have not yet started (some rl kicking in this afternoon).

5
renanse said:

Just to be clear, I think you have some good ideas there but without gaining a deeper understanding of how the current system works, it will be hard to implement those ideas without causing problems.

sure :), I'll be careful
6

We're going to go ahead and release 0.9 today. Because changing the RenderState is one of those things that might expose issues, require revamping, etc, etc, we didn't want to delay 0.9 for it. However, if the changes do prove to be good, they can go in right away (just be advertised under 0.10).

7

To be fair, Mark and I did look into each of your points and it basically ended up being a fairly small amount of memory saving because most of the current Geometry RS array locations are null in many cases and those in the non static Spatial RS array are pointers to shared Objects.  Only LightState and TextureStates are created new, but they would have to be anyhow either once and stored, or on the fly.



Changing to an ArrayList would introduce new issues, like the need to go through each and every ArrayList item to find out if the ArrayList even contains a particular renderstate type.  Your idea would also require going up the tree looking that way through every single ArrayList on every frame.



Basically that brings us down to only the "initialize Spatial.renderStateList to null, allocate when first render state is added" and improving the extract methods.  Both of those have some merit and would probably improve memory a bit in cases where no states are used (which is fairly rare, but still…)

8

Ok, so finally the most important things went into .9 :slight_smile:

More work could though be done on the extract methods, the states created in there should be stored in the nodes where they merge not in the geometries - to gain some memory and speed up in actual applications with more than one light state and so on …

But this must wait.



Going to sleep now - good speed for finishing .9 today…