VEX vs VOPs

[magneto]

I mean using the VEX node graph vs writing VEX code from scratch.

Is there any technical advantage of using one over the other? I actually just started learning VOPs recently and really liked the editor, but after writing a very small deformer, the graph became pretty large which is not hard to create, but I started thinking how hard it would be to try to understand it later.

Then I wrote the same operator in VEX never having used VEX before and it was a cinch. I must say I really like the VEX language, it's pretty cool.

Even when I was inspecting some VOP examples, I found myself falling back onto viewing the code the compiler generates as it seemed faster to see what's going on.

I am just curious what's the general/common workflow with VEX/VOPs? Or is it just a personal preference?

I was thinking maybe writing everything in VEX, but using VOPs for small/inline operations that are not generic, or are not worth making an operator for.

Is there one advantage of using one over the other? Like I said in one of my previous threads, I watched a video where the guy said VOPs map like 95% of VEX, but as I also found out, there are VOPs that don't exist in VEX. Anyone familiar with both can tell me if there are more things like this? Maybe even some high level VOPs that would be very useful if you use VOPs, but would miss if you just use VEX?

Again I am not criticising the VOP graph editor, but just want to know experienced people's opinions on workflow, etc.

Thanks

[hopbin9]

Keep learning VEX.

I keep hearing that the hardcore Houdini TDs all code in it.

What you do in VOP can be done in VEX, but what you do in VEX can not be done in VOP. VOP is just a tool for non programers to create VOP, but with that said non-programmers often don't get VOP anyway.

I think you can create your own particle and dynamic solvers in VEX. Now that would be a cool thing to try.

[hopbin9]

I just wrote my first couple of lines of VEX code.

Thanks for the motivation to give it a try.

I find the coding is a lot easier then VOP. I just wish I know more about how it worked. I'm going to have to read up on VEX programming.

[magneto]

POPs and DOPs in VEX would be sick. So much for the imagination.

Awesome man that you actually started writing VEX. You are one motivated guy

Yeah that's what I noticed, when I observed some mid-size VOP networks, it takes way more time to know what's going on, since it's very low level, not like the rest of Houdini. I think there is a spot as to how much you gain from low level vs high level granularity. Houdini hits the sweetspot IMO. Imagine everything in Houdini like VOPs. It would be very hard to get anything done or understand other people's scenes.

I don't think you need to read a lot on VEX As long as you are familiar with some C-style language, everything just makes sense IMO. I find very minor differences and just reading up on pragmas, but also from Sidefx's built-in VEX operators like Mountain SOP which shows a lot of stuff in regards to UI, etc. Rest is the available VEX functions where I just search as I go for things like identity matrix, sign, rotate, etc.

[LaidlawFX]

I'm gona use hopin9 stuff to help me answer.

Keep learning VEX.

Full heartily agree. It is an extremely useful tool to have in your belt.

I keep hearing that the hardcore Houdini TDs all code in it.

I would phrase that as Old-School and programmer based TDs use it. Over the last decade especially with better schools, and a better UI since 9, vops is a very commonly used method, almost the default in sops and with larger trends for shaders, as an otl style asset, as opposed to a custom node(like your own solver). Though don't apply as a shader td with just knowledge of vops, that won't get you a job, nor will vex either, RSL would be the route to go in that vein. For h10 and h11 vops sops were multi threaded unlike other sops leading to many TDs using vops sops instead of the point sop per say. Vex is also more for pushing points around than coding. http://www.sidefx.com/docs/houdini11.1/vex/ h12 will alleviate alot of this and make it comparable to xsi ice again for speed. If your learnign languages pyhton, would be more important in your day to day use, and hdk will guarantee you a job and long term employment. Expression language, and hscript are good to know, but most of hscript will slowly be phased out, or have an alternative python option.

As for the Old-School logic as opposed to hardcore, any senior or lead with more than 10yrs experience has been doing houdini since prism. While prism was the solution instead of programming back then you still needed significantly more programming skills to get the job done, and shop vops was especially weak compared to what it is now. These are two things that define it, but I've meet many a hardcore user that didn't use these things.

What you do in VOP can be done in VEX, but what you do in VEX can not be done in VOP. VOP is just a tool for non programers to create VOP, but with that said non-programmers often don't get VOP anyway.

Anything lacking in VEX can be done with a vex vop, and the odds of coming across that is often rare. I've come acros it maybe a half dozen to dozen times over the last couple years, and I primarily use vops. There is a good vex/vop tutorial from cmiVFX that has an example of putting a math formula in vex as opposed to vopswhich shows some of the problem and benefits. It really depends on what you are doing and how you think.

I think you can create your own particle and dynamic solvers in VEX. Now that would be a cool thing to try.

I forget and alternative term for vex outside of an expression language, but it was designed to handle points, and subsequently derived for color since they are based on the same principle of vector based math and logic. Either way, it certainly can be used for pushing points around.

As for me I use vops all the time, they just make sense to me better than code, and is why I use Houdini. There are many times where I can't figure out something in vops, but I'm pretty sure that those are the same amount of problems anyone has when solving a problem you haven't done before. Vex and Vops method is certainly a matter of opinion which to use if you favor one, both can be used in production.

The only way I would side towards vops in a direct to direct comparison, is that when giving a common artist an asset to use on a show(people who are not fully trained on the whole tool), vops provide a good solution to modify these tools, with it beign compartmentalized. My biggest example is shaders. A well built shader should be easy to modify for a common artist, by adding a noise pattern or ramp set to certain variables. This is something a vex based shader does not allow you to do, unless you packaged your different vex sections into good nodes, and then you will find yourself near the same level as the number of vops you have. This modular-ity with vops is one of the reason it can be more useful than codes. But I will end with learning both is good and will help you a lot, the more the tools you know the merrier.

[digitallysane]

VOPs can be faster and even more readable in small, day to day tasks. It's easiear to just put down a VOP SOP, place a noise and a mult inside, export few attribs and be done with it. For that type of stuff, just making an OP with VEX is slower, in workflow terms.

Also it's good to try to get used to VOPs since all included Houdini materials are VOPnets, so you'll probably hack them further with VOPs. And again, in shading contexts, I do find VOPs quite readable (the visual representation of having a shading model with all the patterns and colors flowing in the corresponding slots is intuitive). VOPs can also be more comfortable for people coming from other packages (Maya, Softimage).

Indeed for complex programming constructs like cycles and so on, VOPs are not readable at all. But no one stops you from using VEX in complex situations. I do find VEX very redable and I agree that is often more readable than a complex VOPnet, but not everybody does.

[symek]

My vote for VEX. Anything beyond basics are easier to maintain and understand in code. Unfortunately Houdini doesn't have vex editor in gui, inlineVOP in cumbersome, so "interactivity" is poor. SESI definitely pushes VOPs at first place. I actually greatly admire developers who are apparently forced to implement new shaders (or ops as RippleSolver) in VOPs, brave men!

There is a trick though to compile your code into operator first and once it basically works, recompile it into VOP node. This brings these two worlds close together. Just build your tools as vop operators, not sops/shops itself.

Besides that there is no difference between VEX and VOPs. Things you see missing in VEX, which are present in VOPs, are just a snippets of VEX prepared for VOP contexts - kind of higher level library. You can see it (and in fact it's a great way of learning VEX), in $HFS/houdini/vex/include/voplib.h (most headers there are worth reading).

[lisux]

Well I dont think is a question of use VEX or VOPs.

Use both.

For me the best is using VOPs for the prototype and then for the hard part of the tool use InlineVOP.

Easier to maintein than a pure VEX script, much easier to make the interface, seriously dealing with #pragma statements is not really practical when you have the Parameter VOP.

So mixing the best of both worlds, the inline VOP is the key.

[hopbin9]

Just build your tools as vop operators, not sops/shops itself.

Excellent tip. Sounds like I need to create some xVEX tools

[magneto]

Thanks alot everyone. It's good to hear the opinions of other experienced users.

@Symek: When you said there is a trick to get your code compiled into an operator and then back into VOP, do you mean seeing the graphical representation of your pure VEX code? That would be cool.

I will check out voplib.h tonight.

Also when you said building tools as vop operators, can you give an example? Say you are writing the Mountain SOP, what would you implement as VOPs? The pieces that makes it the Mountain SOP? Or the whole SOP as a VOP?

Another thing I was wondering is, would complex examples built with VOPs vs VEX have performance difference?

For instance I see that you always break compound data down and merge them back together in VOPs.

Like when you are changing only P.y, you use a vectorToFloat, do some operations and gather the result values into a floatToVector, etc.

Whereas in VEX, you just say:

P.y = ...

What do you guys think about this?

[Erik_JE]

Well I dont think is a question of use VEX or VOPs.

Use both.

For me the best is using VOPs for the prototype and then for the hard part of the tool use InlineVOP.

Easier to maintein than a pure VEX script, much easier to make the interface, seriously dealing with #pragma statements is not really practical when you have the Parameter VOP.

So mixing the best of both worlds, the inline VOP is the key.

I agree with this. Hard complicated parts in a InlineVOP (easy to use external editor) and simple parts with regular VOP nodes. Makes stuff easy to understand and fast to work with.

[glassman3d]

I agree with this. Hard complicated parts in a InlineVOP (easy to use external editor) and simple parts with regular VOP nodes. Makes stuff easy to understand and fast to work with.

hi there

I tend to use vops as it is easier to hand over to other houdini artists, though coding vex is much more concise and precise.

In the latest builds of h12, there seems to be little or no speed advantage to vex as all the code is optimized by the compiler

Edited May 9, 2012 by glassman3d

[pedrokobuti]

I wanna use VOPs whenever possible.

Looking at lines and lines of coding is such a buzzkill for me. Absolutely hate programming/debugging.

All I want is a beautiful result; and as a non-programmer; I was very attracted to Houdini specifically because of VOPs.

It really turns me down to see Houdini users opting for VEX over VOPs.

[mestela]

Writing vex isn't like writing code in other language, especially for graphics. Even tools like processing, which is probably the closest equivalent in terms of a purpose built language for manipulating graphics, involves more boilerplate code and fiddly stuff than I'm comfortable with. The fact that you can create a wrangle and write something as simple as...

@P+=noise(@P);

...and it works, I don't think any other language or 3d system can match that. And as others have said, Houdini doesn't compel you to use vex or vops, use whatever is best for the task at hand. I do shadery visual stuff in vops, and pointcloud lookups and loops in vex, and often I'll combine the two with snippets sitting inside vops.

I remember when I started learning houdini thinking 'ew, wrangles, too hard', but over time they've become my standard go-to node. Don't make the mistake of skipping vex cos you've had a bad time with other languages. It's incredibly elegant and powerful, and for the most part its faster to write and debug a simple 3 line vex wrangle than to create and debug the equivalent 12 node vop network.