The current way of changing a material per view is not usefull in some situations.

Using an event function and ENABLE_TREE to change the material depending on the render_view has some problems when not all entities use the same material. I have seen ello's code here but it only works because there is only 1 material per view (all objects use the same material in the camera view). If you want to use multiple materials in the camera view things get difficult.

Let's look at an example:
I want to render the objects in my scene with their normal shaders in the camera view (normalmapping, terrain shader, etc). In a second view (DepthView), I want to render the depth of the scene.
I can use a ENABLE_TREE to change the material to my DepthRender material if render_view == DepthView. The problem is that I cannot use a material event for resetting it to the original material because there is no way to know what material it originally had (this is possible in ello's code because all entities use the same material in the camera view..).
To solve this, I could use a seperate DepthRender material for every other material so that each DepthRender material resets to a different original material but this is very ugly, especially when you have tons of shaders.
Additionaly, if you use this method to change the material AFTER the normal camera was rendered, the material pointer will still be set to the alternative material when the game code is executed. If I wanted to use the material pointer in my game logic I would run into problems with this.


It'd be nice if there was a more elegant way to switch the material per view. Here are some thoughts:
A) Have a material pointer in the view definition so that entities in that view are always rendered with that material.

B) Similar to solution A: have a global, predefined material pointer that overwrites the entity materials if it is not null. This pointer could then be set before a certain view is rendered.

C) Reset the material pointer after rendering the entity if it was changed in the event function. To not break old code, this could be done only if -1 was returned from the event function or something.

Cool, I just had an access denied clicking that link

Cheers

me too it's probably in a beta section which us public-beta-ans dont have access to.

julz

Yes, it is a beta link. - The request makes sense and I'll implement a solution similar to B.