uniform / constant parameter types in shader VOPs?

[meeotch]

Do shader VOPS have a sense of "class", in the way that old-school Renderman SL parameters do?  Specifically, is there a way to limit some block of shader stuff to not calculate on every sample?

The context is that I've got packed alembics coming in.  Inside those packed objects is a detail ID attribute (int, but saved as a float) that specifies a group of texture maps.  In the shader, I need to construct the texture paths based on this integer, which I'm currently doing in an Inline VOP.  This works, but when I insert a printf() into the Inline as a test, it appears that it's getting evaluated many thousands of times.  What I'd like is evaluation once-per-alembic, or once-per-packed-prim, or something. 

I know that this could be done with style sheets, or by baking the texture paths into the alembics, or by unpacking the alembics and adding the texture paths, or by having many dozens of individual materials.  But for reasons unspecified, we're not doing any of that.

[StepbyStepVFX]

I am not a shader expert, but it seems to me that the shader is called on a per ray basis, so that would explain the inline vop being evaluated thousands of times.

I understand your inline vop is there to create a string path based on the integer that is sampled ? Maybe outside of the shader, create an attribute on the geo that will directly contain the string (so you run a Wrangle node with same code as inline vop), and in the shader just sample this value. This should avoid the code being run as many times the shader is called, no ?

Hope I don’t make you loose your time :-)

[old school]

Old school renderman shaders used micropolygon rendering and scan lines. Vertices were pre-shaded and yes you could set constant values that only evaluate on the verts and not across the face. All after geometry refinement.

Raytracing is not this. Every ray needs to evaluate the shader. It's all firing rays and calculating all shader properties on ray hits. Even constant colors are evaluated every ray hit. Including texture string look-ups. UDIMs with varying texture references per face after refinement...

Vex is still pretty loosely typed in that you don't have to specify varying or constant variables as this is determined when shader is compiled. Optimizations applied as they can. 

???

 

[Jason]

Also, when you printf() in VEX, you're forcing output to happen. VEX is usually very good at detecting uniform vs varying variables and executing thing the minimum number of times.  However, there are some specific optimizations you can use -- check out texprintf().

[meeotch]

Thanks for the replies.  @jason - An interesting point about printf possibly preventing optimization.  Would be interesting to test, though I'm not sure how off the top of my head.  But I'm unclear what you were referring to w.r.t. texprintf - it seems to just be a sprintf that does UDIM substitution automatically?

@oldschool - point taken about the shader being evaluated for every ray.  It still feels like this wouldn't prevent optimization of non-changing values at various levels.  But I'm not sure how the parameter-override mechanism is implemented.  With packed geo, presumably you can't know if a value is overridden until render time.  But mantra also knows which object / prim is currently being shaded, so once it's determined that parameter X isn't overridden at the point level, it presumably doesn't need to make that determination again.  I guess it comes down to how clever the compiler is about arranging things to execute the minimum number of times, as jason mentioned.

In the absence of an "optimization hinting" mechanism, it would be great to at least have an explanation in the docs re how the compiler / mantra work together to optimize stuff.  Then you could attempt to arrange your input in a way that was efficient to render, and avoid pathological cases like doing string mangling on every sample.

[old school]

On 4/7/2018 at 12:28 PM, meeotch said:

In the absence of an "optimization hinting" mechanism, it would be great to at least have an explanation in the docs re how the compiler / mantra work together to optimize stuff.  Then you could attempt to arrange your input in a way that was efficient to render, and avoid pathological cases like doing string mangling on every sample.

I agree! 

Please submit an RFE for this documentation. Just so we have a reminder that this would be useful to have.

[meeotch]

Submitted.  RFE #89590

Edited May 27, 2018 by meeotch