Problem with RenderStates

I am a bit puzzled.

The following works perfectly:



WireframeState ws=DisplaySystem.getDisplaySystem().getRenderer().createWireframeState();

ws.setEnabled(true);

getWorld().getRootNode().getChild("box5").setRenderState(ws);

getWorld().getRootNode().getChild("box5").updateRenderState();



But the following does nothing:

getWorld().getRootNode().getChild("box5").clearRenderState(RenderState.RS_MATERIAL);

MaterialState ms=DisplaySystem.getDisplaySystem().getRenderer().createMaterialState();

ms.setDiffuse(new ColorRGBA(1.0f,1.0f,1.0f,1f));

ms.setEmissive(new ColorRGBA(1.0f,1.0f,1.0f,1f));

ms.setShininess(100f);

ms.setSpecular(new ColorRGBA(1.0f,1.0f,1.0f,1f));

ms.setEnabled(true);

getWorld().getRootNode().getChild("box5").setRenderState(ms);

getWorld().getRootNode().getChild("box5").updateRenderState();



Lights are turned on, I have materials working (the scene is exported from blender). But if I try to change the material it just fails.

Why can that be?

Ah, it works with newly created objects.

But I thought cleaning the renderstate would be enough.

Am I missing something?

Thnaks a lot


What's likely going on is there is a material state deeper in your scenegraph that is overriding the new one.

I've been working on this problem as well - it is mystifying.



As far as I'm aware no material states are being set elsewhere, up or down the scene graph, plus:

getWorld().getRootNode().getChild("box5").clearRenderState(RenderState.RS_MATERIAL);

And something pflanzenmoerder didn't mention is that we sandboxed setting local LightStates -which had no effect - though applying LightStates to the root node did work.

So I have a few follow-up questions:
Could there be any problem with the fact the nodes we're working with are jmex PhysicsNodes?
Should we be paying more attention for possible overriding up the graph or down the graph, or both?

Anything at this point would be helpful.

Thanks in advance.

I'm not sure about the physics stuff but states always inherit from above (child inherits from parent).  One thing you could do is use BinaryExporter to save your model to a file and post it somewhere.  I could use our internal tools to view the file and see where the material is coming from.  (Or you might be able to use MonkeyWorld3D)

Ok, so I think we have a slight misunderstanding of renderstates here.

I thought it worked like this:

If the parent has a MaterialState and the child doesn't have one then inherit it.

If the child has a MaterialState it uses the one it has not the one from the parent.

That's why we cleaned the RenderState and then added a new one with calling UpdateRenderstates afterwards.

Or is it like that:

If the parent has a MaterialState ALWAYS inherit the RenderState and ignor RenderStates in the child.

>.<

Further info: I've suspected that its something to do with the scene loader for a while, and got a test put together.



Turns out that material states are being correctly set on new objects, but refused on loaded objects.



We use the Collada Loader, and apparently it's locking something or reloading something… somewhere.

I've tried Node.unlock() and such, and am trolling the Collada forums and code, but again, any lead at all is a help.



(note: as to the suggestion to use MonkeyWorld3D - we use Collada because it's the only thing that's feasible given that we use Blender to give us model format import flexibility, as our designs are coming from varied sources)

I'm not too sure how renanse meant that states always inherit from the parent, when in his earlier post he said that the likely situation is that a state further down in the scenegraph was conflicting and overriding, but the latter seems to be the case.

I've also been working on this problem, and i've solved the issue of recoloring SharedMeshes generated by the ColladaImporter by applying the desired renderstate to all batches within the SharedMesh. It seems that if the renderstate is simply applied to the SharedMesh itself, the renderstates for each batch within the mesh override the applied renderstate, and the change has no visible effect on the scene.

I've tried updating the render states on the batches, as well as on the SharedMesh, but it doesn't seem to propagate down and override the child renderstates at all. In my case this is the desired effect, but I can see how this may not be wanted. Even so, is there a separate function or a flag somewhere for the updateRenderState method that I'm missing (ie. a proper way to do this)?

The problem was that the Collada importer sets RenderStates on the SharedBatches as well as the SharedMeshes themselves.  This is extremely misleading because the batch RenderStates override the mesh RenderStates - in apparent opposite of Node RenderState inheritance, where lower overrides higher.



I could shoot someone.



Any other gotcha's of this type to be aware of involving SharedBatch/TriangleBatch/etc?  ie: What exactly are the overrides?  Should I be worried about possible changes to the SharedBatch.target() mesh after targets have already been set, or just before?  XD

Feature, not bug. :)  (No, really…)

…Renanse recently started working at Microsoft…it's amazing how there's about twice as many hidden features and never any bugs anymore. 

darkfrog said:

...Renanse recently started working at Microsoft...it's amazing how there's about twice as many hidden features and never any bugs anymore.

It always makes me sad…renanse generally seems to take the high road and not respond to such things thrown at him. :wink:

Probably because things thrown from a frog generally don't reach  :smiley:



Always enjoy giving the "It's not a bug, it's simply an unplanned feature" response.

Actually, in this case, it really is a feature.  Shared meshes use the same states as the target (same object).  So if you make changes to that state, it will carry over to both target and copies.  If you replace on the target or one of the copies however, it will be unique for that batch.  This allows you to have a special blue leaved tree, for example, while still using the same target.

SOunds reasonable. If we had just known earlier  :wink:

Anyways, by next we will be able to show you a video of what we are doing with the monkey.


renanse said:

Actually, in this case, it really is a feature.  Shared meshes use the same states as the target (same object).  So if you make changes to that state, it will carry over to both target and copies.  If you replace on the target or one of the copies however, it will be unique for that batch.  This allows you to have a special blue leaved tree, for example, while still using the same target.


You made that clear the first time, I just couldn't resist the good natured ribbing. ;)