new sop type vs vex surf and vex disp

[itriix]

Hi all. i've been playing around with VEX and just have a question... what is the big difference, benefits, reasons why or why not... to use a "new sop type" that does displacement on the point positions... and colors, lights... etc. vs, creating a vex surface shop type and a vex displacement shop type... and turning that into a material? main thing i can think of is... making the material would be "cheaper"? yes/no? in terms of rendering and such? I'd like to clarify what the true advantages are to do it one way or the other.

thanks,

J

Edited April 25, 2009 by itriix

[itriix]

To clarify a bit better. if i created a new sop type. inside there is a color mix node with the first two inputs as Color 1 and Color 2 parameters. and then i plug a pattern into the bias. also i hook the pattern into a displacement vop, create a scale paramater. I plug the color mix node output to the color output... and then a plug the displacement output to the P output.

and then compared to that... if i created the same type of thing... but instead with a vex surface shop and a vex displacement shop... and bundled them into a material.

I'm assuming, the second method is cheaper... but that if i needed to have TRUE displacement where i was creating like a valley, and then flying through it. i'd need to use the first method. but if i'm not needing to basically travel through it, and just wanted some simple displacement, go for the second method?

thanks,

Jonathan

Edited April 25, 2009 by itriix

[Jason]

That sounds about right. Generally displacement is used for high-frequency, low amplitude detailing of the geometry. Deformations with VOP SOPs and such are generally used for animating the mesh, setting the attributes for rendering with, etc.

You're right that the line begins to blur - but it becomes quite clear after a while that you should try to keep as much in SOPs as possible before allowing displacement to take it the rest of the way. This is all highly dependant on what you're up to... in FX work, VOP SOPs are used a huge amount to process attributes fast, but in Lighting work you tend to want your geometry to exhibit high quality details for which Displacement shading is appropriate.

In many lighting pipelines, for instance, the lighter/lookdev doesn't have permission or access to deform the geometry.

[itriix]

thanks for the clarification. now i'm playing around with "hda's" and making sure they are "pipeline" useable... a little tricky for my brain right now but nothing that a bit of practice and experimentation won't help out with.

it sounds to me that, the correct procedure really just depends on the studio's pipeline however, i'd like to start practicing "good practice"... and methodology. sounds to me that it's safer to create a network as usual, collapse it to a subnet, promote the parameters for the artist's control, and then save that as a digital asset (.otl).... *independent of the hip file*???? i guess that's where i get a little confused at the moment. seems that if it's embedded in the hip, that could be good so that "wherever" you go, it'll work... but seems that the .hip would begin to get large *maybe*... hmmm i think i just need to ponder this process some more, in the meantime back to my particle work

Cheers!

J

[Jason]

thanks for the clarification. now i'm playing around with "hda's" and making sure they are "pipeline" useable... a little tricky for my brain right now but nothing that a bit of practice and experimentation won't help out with.

it sounds to me that, the correct procedure really just depends on the studio's pipeline however, i'd like to start practicing "good practice"... and methodology. sounds to me that it's safer to create a network as usual, collapse it to a subnet, promote the parameters for the artist's control, and then save that as a digital asset (.otl).... *independent of the hip file*???? i guess that's where i get a little confused at the moment. seems that if it's embedded in the hip, that could be good so that "wherever" you go, it'll work... but seems that the .hip would begin to get large *maybe*... hmmm i think i just need to ponder this process some more, in the meantime back to my particle work

Cheers!

J

How HDAs can work for you can vary a lot, really because they can represent/store data (like models, textures, etc, can be embedded in them), or they can be tools (SOPs, etc), or a blend of both (hard to categorize).

I think there are several ways HDAs will fit into any pipeline, but I'll comment on one way quickly - tools for an FX pipeline. This is a lot more clear-cut, as it you can kind of treat them in a similar way to the concept of versioning of software. What seems to work effectively is a simple but strict naming convention, some simple guidelines, some version control (rcs/cvs/svn,etc) for storing minor revisions, and a way of making all of this as easy as possible to use. I firmly believe that artists should be encouraged to develop, maintain and enhance tools that can be used across the studio by many artists.

This is the basics of what works for us:

*/ Only one HDA per OTL, unless it's a compound system that has several codependant assets - which, thankfully, doesn't happen too often. It's best if the all the assets are useful in their own right and can be reused in several systems.

*/ Naming conventions: [context]_[show]_[name]_[version].otl (eg. SOP_xmen_PointWiggler_v03.otl) The operator label is tied to it: ie., "PointWiggler v03 (xmen)". The name is tied to it as well: xmen_PointWiggler_v03. These three things can never be allowed to diverge (esp, name and filename), or chaos will ensue.

*/ If the artist wants to change the HDA, the artist can check-out a copy of his own. While he has it checked out, no-one else can check it out. (if they try, they'll be told who checked it out). If he is adding extra functionality or bug-fixing it, he can check it back in under the same name. If he ends up making significant changes that would break backward compatibility with other people that may be using this operator, he must choose to bump up the version number (and the original version he checked out will just be made redundant and "released"). eg. the checked out PointWiggler_v03 will be renamed to PointWiggler_v04 and the lock on v03 released.

*/ The check-in/check-out process should be journalled by something like CVS, and a little tool written to make sure artists can quickly revert to earlier versions should a mistake be made which breaks stuff.

*/ These OTLs should be able to be promoted from shows to studio. So you can send a copy of SOP_xmen_PointWiggler_v03.otl to the show's otl location as SOP_studio_PointWiggler_v01.otl. Usually this is done at the end of shows, as the nodes have probably been used on several shots and so been tested.

*/ An easy way to ophide older versions of nodes to encourage the artists to use later versions exhibiting new/better/fixed functionality and to keep the TAB menu from getting huge. You can't remove OTLs once they're out there unless you have a way of telling that they're never used by anyone... so your only choice is to hide them. (You can log OTL usage too, which we do - useful for cleanup purposes)

*/ We've chosen to use the RMB menu (the OPmenu) to manage the check-in's/check-outs. It seems like a good place for it, but you could probably use the shelf too.. with the only complicating factor being context, and multiple selections.

HOM and hscript have all the functions you need to do this, but the methodology would kinda depend on your pipeline setup, show directory structure and all that.

I hope this helps,

Jason

[itriix]

fantastic explanation!

*/ Only one HDA per OTL, unless it's a compound system that has several codependant assets - which, thankfully, doesn't happen too often. It's best if the all the assets are useful in their own right and can be reused in several systems.

how about in the case of "materials"... i was suggested creating a library of VOPS not SHOPS... and essentially do everything i need to do with VOPs and basically just use SHOPS as a wrapper for the asset? if i wanted to recreate the very "basic renderman fruit project" in mantra, i was suggested to create two VOP HDAs... one for the shape, cuts, knicks, etc... created from black and white masks. and then, one HDA for the color. then use a vex displacement shop which uses the mask info to drive a displacement vop, and then in the vex surface shop, the mask would connect to the fruit coloring vop. what's your thoughts on this methodology?

once again, thank u for the detailed response. i already copy and pasted it to keep as my reference

J

Edited April 26, 2009 by itriix