Enforcing changes in a RenderState based on the existing RenderState

1

I'm just wondering what would be the best practise for implementing this. It's because of this topic:

http://www.jmonkeyengine.com/jmeforum/index.php?topic=2749.0



It think with the pass system, there will be more such scenarios, mrCoder already seemed to mention he'll need some. The approach I've chosen here is to add a static method the the abstract RenderState it applies to (CullState in this case). I'd just like to hear if anyone had a better idea perhaps.

2

I think the first question is whether this needs to be part of core, or rather a controller / external device that updates the scenegraph in some way.  His particular issue could be solved by simply flipping frontface from CW to CCW and back.

3

Yes, the first question is what I mean really. This is quick and efficient, but it's rather intrusive in the design. (I checked it in for now, since in CullState it's only a minor addition, but it can be rolled back if something better is found).



As for the specific case, there might be a different solution, the general question still stands I guess. Going through all RenderStates creating altered copies seems a bit too heavy. I was thinking of something along the lines of a "hook" that calls preApply(RenderState rs) and postApply(RenderState rs). So eg. if I had the silly idea of doing a Pass that makes the global ambient light color more blue, I could call

renderer.setRenderStateListener(myPassClass, RS_LIGHT);





and have:



class MyPassClass implements RenderStateListener extends Pass {

// ...
private ColorRGBA old, temp = new ColorRGBA(), old;
preApply(RenderState rs) {

4

I think you're missing the whole enforced states concept that is already in?

5

I see… Still, now you are essentially adding extra check (to see if it has listeners) for every state on every execution of that state.  I'd still recommend simple state management instead.

6

I agree with Renanse - render state performance is very important, we should even improve it. So features like you suggest Llama should be implemented carefully and possibly only included if really neccessary.

An option would be to introduce subclasses of render states that allow listeners - this makes subscribing listeners a bit more complicated but that could be hidden…

7

Well, maybe we won't need such a feature for a while anyway. The current changes to CullState seem to have kept everyone happy for now, so if you guys can live with it as well…



I think compared to what goes on when applying most states the addition of a simple !=null check won't have an easily noticable impact on performance, but that's of course only when a listener is not used. I agree the weakness of the concept is when it's actually used :wink: