Ive been busily building myself a multi purpose shader in vexbuilder, i`m kinda proud of it.. but i`m suspicious that the render times are too slow…

my shader has access to Spec parameters, and multipliers for specular variation/strength/colour textures, bump map, diffuse colour and map, diffuse2 and some photoshoppy blend modes (a la Lightwave) , environment mapping (using the `reflective` vop), self illumination, opacity, and a render pass output so you can choose which pass you render..

i was wondering if the shader is doing a load of processing for parameters i`m not using… like if i have my spec pass selected, which is an additional lighting model vop, with the parameters applicable to spec piped in, connected to a switch to the output.. etc for the other passes…
also wondered if its doing any raytracing that i`m not aware of (in teh reflective vop for example).. as i dont want it to be raytracing anything..

cheers,

MarK

Hey there,

When VEX gets executed (VOPs generate VEX), a pre-optimization process runs first that optimizes all the constant conditionals out of the code and so on. I've had general-purpose shaders which compile to literally thousands of vex instructions - and after the preoptimization process they typically reduce down to around 20 instructions. If you are varying many of the arguments across the surface (by overriding parameter names with point attributes) then it will not be able to collapse those operations which could be resolved if the terms were constant. You will not be able to tell how big the optimized code is - Side Effects told me once when they inspected a shader of mine a while ago.

But rest assured, even with the inflated vex code generated from VOPs, the acutal size of the executing code will no doubt be small and fast.

If you're suspicious about the raytracing, you can tell mantra to deny all raytracing in the Mantra ROP “Command” options - I believe its “mantra -Q r” and check the difference.

Hope this helps,
Jason

thanks very much

If your vop network has a lot of conditions, use if-then VOPs so that they do not get evaluated followed by a two-way VOP. This is natural to do when writing shaders with code as it is a simple if-then construct but not so evident in VOP networks.

A switch VOP is not an if-then loop.

Thank you guys , those great info should probably include in doc.
Could I get more info about this pre-optimization somewhere?? or output ascii code after pre-optimization to see how optimization works .

I made a shader with only diffuse and reflection component from higher level kitchen sink H12 surface model vop. But both render without noticeable time difference display in render scheduler. Thus I have few more questions about how pre-optimization optimize.

* For a constant condiction to if then block. Does the code inside loop get stiped out to scope above(condiction true), or not even placed to execute(condiction false) after per-optimization ??

* For code multiply with 0 constant, and assign to variable. Does the variable get assign 0 directly without code placed to execute after pre-optimization??