[Ogre 2.0] How to get shadow textures in render_quad

[al2950]

I am playing around with a few rendering techniques and I would like to be able to read the shadow maps from a render_quad pass. How would I go about doing this using the new compositor system. I have had a look through the code and I am not even sure its possible!

If you are wondering why I need it, I am playing around with some volumetric lighting effects like the ones outlined here. I could draw a full screen quad manually, which along with other light geometries is probably what ill end up doing, but I am being a bit lazy!

[dark_sylinc]

You're right, I don't think this is currently possible in the compositor.

A workaround is to get on C++ the name of the shadow texture from the CompositorShadowNode and set it to the material directly. But this is very far from ideal.

EDIT: What happens if you connect the shadow node to the node as input? It might/ought to work. But I never tried really.
EDIT 2: Another suboptimal solution is to copy the results inside the shadow node (using a pass_quad) to a global texture.

[al2950]

Interesting... I dont like your 'EDIT 2' option so I am going to ignore that for now(**EDIT** that sounded harsher than I meant!) However I like your 'EDIT' option , but it crashes .

It successfully adds the shadow texture to the outputChannelMappings of the node definition, however it crashes when instantiating the Shadow node, the reason is it instantiates the base 'CompitorNode' class first which tries to route the output textures in its constructor, however the shadowmap textures are not created until the 'CompisitorShadowNode' constructor is run. There are a number of ways to fix this but not sure how you would like to tackle it... any ideas??

**EDIT 2** I am leaning towards a virtual _initTextures, or even an _init function.....

[dark_sylinc]

I was afraid something like that would happen as the dependencies are hard to solve.

The thing with shadow nodes is that their initialization depends on the nodes referencing them.
And you would certainly deduce that if a Node references a shadow node, while the shadow node's output is the input of that same Node, a circular dependency appears.
Things can get more tricky when multiple nodes are involved (Node A -> Node B; Node B uses Shadow X; Shadow X output is the input of Node A).

However it's not impossible. Instead of doing both pass_scene and pass_quad in Node A, you could do pass_scene in Node A and pass_quad in Node B; if Node B never uses the shadow node, it could use it as input. We would have to modify the Compositor code that solves the dependencies. But I fear this could become too complex (not just the code, but also for the guys writing compos).

Perhaps the safest bet is to reference the shadow node from within the pass_quad (just like pass_scene do) and access it like the special case they are.

[al2950]

Hmmm, I mostly get where you are coming from, but I am still getting to grips with the internal workings of it. I think, based on what you have said, the best course of action would be;

1) allow shadow_nodes to be defined within pass_quad, similar to render_scene.
2) Disable the ability to define an output from a shadow Node? Its easy to ignore the sctipt token, but what about devs trying to do it from code, how would you prevent them calling mapOutputChannel on a shadow node?

On another note, should shadow_nodes be called shadow_nodes? Do you think it might cause confusion if, to the user, they are never really used like a standard compositor_node?