what gets processed?

[meshsmooth]

Do branches that don

[Mario Marengo]

The only way to determine these things, is to actually look at the code that the VOPs put out.

To view the code, you can RMB on any tile in your network and choose "View Code" from the popup menu. This assumes you can follow what's going on in the raw vex code, of course. If that's not your bag though, that's OK, you can post said code (instead of -- or maybe as well as? -- the picture), and someone here who can follow it, may be able to tell you what's going on. (but post a simplified version, perhaps)

That said; I believe the answer is Yes!

For a simplified version of your picture, you'd get this kind of program flow:

    1. Result of code produced by: VALUE gets assigned to a local variable
    float value = [blah blah blah];
    
    2. Result of code produced by: if_eq_to_0 gets assigned to another local
    int bool = (value == 0);
    
    3. Result of code produced by: Heavy_process_subnet, ditto
    float heavy = [blah blah blah];
    
    4. Result of code produced by: constant_of_neg_1, you guessed it;)
    neg_1 = -1;
    
    5. And now the switch3 Op simply switches between the two locals
    if( bool == 0 )
        output = heavy;
    else
        output = neg_1;

So you see... all vops that are part of the chain that connects to the final output get cooked and their results stored in temporaries. Any branching logic then uses these temp vars to do the branching.

Can it be optimized by rewriting it in VEX? you betcha!

Can it be optimized using VOPs?!? -- not sure (don't use VOPs much), though my gut is telling me "no", but I'd be glad to hear otherwise..

Cheers!

[edward]

I think (hope/should ) that we can optimize code like that internally without any recoding at all.

[Mario Marengo]

I think (hope/should ) that we can optimize code like that internally without any recoding at all.

Yea, my little explanatory expansion would reduce to a single assignment

(As a side note... even in a simpIe case like that... I wonder if the vex optimizer would actually consider the first branch of the if() as well as everything before it that had anything to do with "heavy" as dead code and throw it all away.... worth a test...)

But... assuming that "heavy" is actually "heavy!", and the discriminant ("value") is actually a parameter (and not the constant that it appears to be in my snippet), then you'd need to stuff all the heavy stuff inside the if() statement somehow... simple in VEX... but in VOPs? -- dunno

Edward?

[meshsmooth]

The code that VOPs produces is not the kind of code that I would write.... I did a 6 month programming corse in java so I am no REAL programmer. But it has so many assignments. It is being generated for you so can

[stevenong]

Hey meshsmooth,

C++ syntax highlighting should be fine.

Cheers!

steven

[edward]

But... assuming that "heavy" is actually "heavy!", and the discriminant ("value") is actually a parameter (and not the constant that it appears to be in my snippet), then you'd need to stuff all the heavy stuff inside the if() statement somehow... simple in VEX... but in VOPs? -- dunno

Edward?

I'm not in a position to give a proper answer. In VOPs, you could simply use an If-Then block to generate the VEX code you would expect. In VEX, I vaguely recall Mark saying that if a shader gets a constant value assigned to a parameter then it gets optimized away at run-time. Not sure how much it does though.

[athomas]

Since we're on the topic of VOP processing.

Does anybody know if we have the ability within VOP's to specify that we only want something to be evaluated at run/compile time and not at preview time?