Jump to content

VOP SOP vs VEX SOP TYPE nodes


itriix

Recommended Posts

Hello,

So, I just wanted to create a commonly used vop sop... I'm curious though, what would be the difference, and why or why not, would it be better to create a VEX SOP TYPE... for my otl... Versus using a VOP SOP, and turning that into my otl...?

Basically here is the forum talking about the vop i want to create: http://www.sidefx.co...c&p=80735#80735

Since the pic function seems so slow, it was explained that a simple vop sop/pop could handle the coloring way way wayyyyyy way faster!

The idea is:

import attribute *uv* --> vec2float --> val1, val2 to u,v of a colormap node... created a cmap parameter... plugged output of the colormap to Cd in Output

Anyways,

I created the vop sop... and the vop pop. and was just about to save them as individual otls, but then thought to myself hmmm. should i just recreate these networks in VEX as a VEX sop type and VEX pop type instead?

What would be the big difference if any? Which method would be best!?????

Thanks,

Jonathan

Edited by itriix
Link to comment
Share on other sites

"This node is useful for creating “one-off” programs to manipulate geometry in a single surface network. To use a VOP network to define a reusable surface node type, see creating a VEX Surface SOP Type." this is in the help card for the vop sop, but when I read this i didn't really understand exactly what it meant by "one off"... at least in reference to my question: if there is a difference in creating an OTL from a VOP SOP vs a VEX SOP type in this situation? I mean you can turn any node you want into an OTL... So, is there a difference, because in this case i'm MAKING the VOP SOP essentially into a resusable node! *at least that's the way i'm currently understanding how this works*

Thanks

Jonathan

Edited by itriix
Link to comment
Share on other sites

I notice that if I compile vex code to sop type, save as otl to all scanned locations... When I open up houdini, I can lay down the node... But then I noticed, hmmm, what if I want to edit the network? It's gone... Only thing I can do at this point is edit the code... So is there a process for being able to still edit the VOP network but still have the ability of it being an otl?

Do I need to create a VOP SOP TYPE, jump inside, create my vop network... select that network of vop nodes, collapse to a subnet, turn that into an hda? therefore I could at least edit that since hdas can still be editted as NODES and not simply as code.....

I'll just keep playing around. Would still be awesome if someone who's BEEN through this, and kind of knows the confusion i'm going through, would be able to clarify my confusion...

Appreciate all your time and effort

Jonathan

Edited by itriix
Link to comment
Share on other sites

A friend of mine just replied to me in an email: Thought i'd share it with everyone incase others ever run into this kind of confusion!

I have to admit, I wish this kind of an answer was in the help somewhere! If it is, then I will slap myself! because i couldn't find anything remotely this descriptive ;)...

Thanks again buddy!

"If you convert it to a compiled vop type, you don't edit it. It's byte-compiled code. You'd need the original network that you used to create the compiled otl any time you'd want to go back and edit the contents.

Sometimes that's good: the code doesn't have to be compiled when the asset is loaded in, and it leaves less room for people to screw with the structure (probably good in a studio environment). But in your case, you probably want a network that you can edit whenever and wherever you want just by unlocking it.

To do that, do not compile the otl. You don't need to. Instead, create a 'vop sop' node (the one with sop inputs), and use that to create your otl. Wrap that up inside a subnet, and convert the subnet to a digital asset as you normally would. Then you'll have a fast digital asset containing your vop network that you can edit whenever you want.

There's a slight performance hit when you do things this way: vop sop code is compiled on-demand. That is, the first time the node is loaded in Houdini, the network has to be parsed to generate vex code that gets compiled to a temp file. So it will slow down loading of scenes ever so slightly, but otherwise should be essentially the same. This is the only way I ever create new vop sop assets: I never, ever compile my vops down to a contained otl, precisely because you can't edit them inside of your networks.

Anyway, if you do choose to compile the code down, probably you'll run into cases where your otl is nearly there...but you need one or two sop nodes to give it the right polish. Well, you can't add those to your otl if you've compiled down to a vop sop type: vop sop types are just a single block of vex code, and can't use sop nodes. So you're screwed. But if your asset is just a vop sop packed in a sop subnet saved out as a digital asset, you can add new sop nodes any time. Even if I were writing vex code by hand (and I almost never do), I'd still use vop sop nodes (wrapping the code in an inline vop). If you have everything inside a vop sop, it's easy to go to a compiled vop type if you really want to. It's not easy to go from a compiled vop type to a flexible vop network."

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...