Search - User list
Full Version: Swithing from Maya to Houdini - advices needed
Root » Houdini Lounge » Swithing from Maya to Houdini - advices needed
Adrian Cruceru
Hello everybody

I'm a maya user, actually from beta 7 since i was working at Alias Wavefront. It has been hard to ditch maya for another software but we pushed the limits of maya and it crashed to many times that we can live with it. So we decided to switch to Houdini.

Actually i'm trying to get along with Houdini for quite a while but every time i'm starting to play around i have to translate all maya comands into houdini - and for sure that it's bad cause i'm always ending by freezing or crashing houdini.

A while ago when we bought XSI i bought also from 3dtutorial.com a video for Maya to XSI explaining how to “translate” each maya concept and workflow to xsi workflow. That tutorial was great since it allowed me to jump on XSI without wasting time wondering why does it do it this way or that way.

I'm looking for something similar to make the transition from maya to houdini.

Is there a Houdini for MayaUsers tutorial?

I'm doing 3d and compositing for the last 10 years using Alias and Wavefront products so i know a thing or 2 about this.

But i really want to understand the houdini paradigm. I watched Garman's Gnomon DVD, it was great but when i tried making a curve and tried adding a point i end up searching the help with no sucess. And i'm sure it's not houdini it's just the way i'm used to think.

I really think Houdini it's the software to use for vfx work and i'm ready to ditch maya completely. Compared to Houdini Maya looks like a broken toy. And i should know a thing or two about this cause i used to work at Alias Wavefront as an Support Application Engineer.

How should i approach this roadtrip?
graphos1
Hi,

This is the only information that I'm aware of
http//usa.autodesk.com/adsk/servlet/item?siteID=123112&id=6904938

Best Wishes
jason_iversen
Hi and welcome to Houdini, hope you enjoy your stay!

We started on some migration hints and only got this far: http://www.odforce.net/wiki/index.php/MayaToHoudini [odforce.net]

It seems like some memories fade fast, even before you can transcribe onto a Wiki. However, if upon your merry travels you find that you want to share wisdom about transitioning from Maya, please feel encouraged to contribute to this Wikipage.

Cheers,
Jason
Adrian Cruceru
thank you jason.

i'm rather interested in the basic workflow rather than advanced concepts. i really think that in order to master an application you have to mentaly switch to that application way of working, forgetting about shortcuts and commands from another software, freing your mind and accepting the new ways.

so i need to understand how you work in houdini appart the node paradigm i'm used with in shake, maya, nuke etc. I need to understand how you model and where you set up shaders, how to use VOPs, SHOPS and COPS for example. I'm a bit confused by the fact that you can create subnets and these subnets can be everywhere.

i need a bit of guidance here about a basic workflow like:
1. how do you model
2. where do you make the shaders VOP or SHOP?
3. SHOP VOP difference - as far as i understand you build VOPs and edit them in SHOP
4. how do you assign shaders and textures cause it seems you can do it everywhere

the list is long but i hope to get along with it

thank you
djorzgul
I know this may sound as a stereotype, but good starting point is going through video tutorials on buzz.com and gnomon.
Once you understand them you will feel much more houdini in your blood :wink:
Adrian Cruceru
i'm doing it but just trying to figure out how to use VOPs to do SHOPs drives me crazy. i know that SHOPs are shader operators but i can't do anything with them unless i build VOPs with controls that i can use in SHOPs.

from my experience you understand something when you're able to explain it to someome else, which right now i can't even figure out the workflow.

i can “assign” shaders in SOPs using a shader SOP or i can assign a shader at OBJ level. i've noticed that OBJ level SHOPs asignment has a higher priority than SOP level shader SHOP assignment after asigning different shaders in different places.

on the other hand VOP is very nice, looks like Hypershade on steroids or what i was expecting to get in maya 1.0 from Hypershade and it seems more powerful than slim. at the first glance. it resembles more to render tree in xsi in terms of illumination model and output as material.

i'm still not able to add a point to a curve or insert a point in a curve but i'll figure it out someday.

thank you
JColdrick
Well, if it's any consolation you've hit on a particularly confusing issue, so you shouldn't feel badly. The whole VOP/SHOP paradigm was really something that happened over time, adapting from a particular way of working. However, if this helps a bit, try to think of VOPs like a completely different program, like Slim for Renderman/Maya. With both packages, you can't just willy-nilly link things together because VOPs(and Slim) are really a visual interface to writing shaders, which in turn are called from the renderer(like slo's and SHOPs). There's a need for them to be slightly “apart”.

As far as the issue of being able to have any type of network anywhere, that's a valid observation. It's very flexible, but it can also get confusing for beginners. Personally, I'm not a fan of the demos and examples making liberal use of them. I understand it puts everything “in one place”, but it also makes things so free-form that I can imagine it being a bit confusing.

Cheers,

J.C.
goldfarb
I'd suggest not using networks in networks AT ALL when first learning Houdini…as you become more familliar with the way Houdini ‘works’ you'll start to want to bundle things up as tools etc - then you'll discover how the different parts are related to each other and the great advantage of networks in networks - and ultimately the OTL/HDA workflow…
Adrian Cruceru
despite the fact that the help is very well organized, thank you SESI for this (i really think it's the best help ever), trying to load or launch an example it gets a little confusing at the moment since it uses some other operators i don't know and i tend to get lost in all the details especially when i get networks inside networks with referenced objects like ../../bla bla (combustion has something like this to reference channels). I do understand this but it's just a shift in the way you would use a 3d software. I'm gonna get used with it for sure but the first impression was WHERE DOES THIS COME FROM?

anyway one thing is sure I LOVE IT! little by little i'll get used with it, actually Shift+LMB adds/inserts a point to a curve wich is way cooler than maya.

i'm still a bit confused with VOP but i'll get along with it. I can't seem to find a way to see/edit a SHOP like in Hypershade cause i can build it in VOP but i don't know how to edit the VOP and reflect the edit in realtime in SHOP or SOP.

the funny thing was trying to explain what i understand from houdini to my team. After 5 minutes artists quit following me and even the TDs where confused about is VOP in SHOP or the other way around.

it's a fun experience for sure.
JColdrick
WHERE DOES THIS COME FROM?

The unix directory structure. This was one of the coolest things about it - if you came from that background(and in the day, everyone did), it's a great metaphor and works very well. Lately they've been breaking “the rules”, though, with the freedom of being able to put any network anywhere else. It became necessary with OTL's.

Your TD's shouldn't be confused about the VOP/SHOP thing if they understand that VOPs are simply a networked shader builder(well, it does much much more than shaders, but that's where you're currently focused). Tell them Slim or Shadetree(from years ago), and that should hopefully ring the bell. The integration of Hypershader in Maya is fine for the basics, but needs access between the shader compiling and render calls.

Cheers,

J.C.
mtucker
I'll see if I can help clea rup the VOP/SHOP thing a bit. Apologies if I get too basic at some points, but I'd rather give too much informatino than to little. So here goes:

Every node you put down in Houdini has a “type”. The individual nodes are instances of this “type”. So for example you can have 15 Grid SOPs. These are 15 instances of the Grid SOP type. Each instance can then be controlled through the parameters of that instance (to make the grid bigger, change the number of divisions, etc).

This is true in SHOPs as well. You can put down 10 Glass SHOPs, which means you have 10 instances of the Glass SHOP type. Each one has a set of parameters you can control to change the glass color, opacity, etc.

You can think of SHOPs as materials, or more generally as nodes that control your render (a SHOP can be a surface material, a displacement shader, etc). Each SHOP type is associated with a particular renderer. So there are Renderman SHOPs and Mantra SHOPs and MentalRay SHOPs. The reason each SHOP type has to be associated with a particular renderer is that the SHOP type is “defined” by a piece of shader code. Renderman SHOPs are defined by shader code written in the Renderman shading language. Mantra SHOPs are defined by shader code written in the VEX language. So where are these shaders that define the SHOPs?

For Renderman SHOPs, and for some VEX SHOPs, the shader is just a file on disk. The SHOP type holds the name of the shader file, and passes that to the renderer. The renderer then searches its shader path to find that shader file, and uses that.

So what about VOPs? VOPs are just a different way to define a SHOP type. Or, more precisely, they are a way to generate VEX code using a GUI (VEX code is used by Houdini for shaders, but can also be used to write SOP types, POP types, CHOP types, and COP types). So a VOP Network defines a SHOP type. If you create a VOP Network of type VEX Surface Shader (even VOP Networks, which define new node types, have a node type of their own) called newglass, with the SHOP Type Name New Glass, then you have defined a new SHOP type called New Glass. You can now create 10 SHOPs of type New Glass. As you modfy the contents of the VOP Network, all the SHOP instances will change their behavior to match the new VEX code that the VOP Network is generating.

Because a VOP Network lives inside a hip file, you can only create New Glass SHOPs inside the same hip file where the New Glass VOP Network is. However you can also right-mouse on the VOP Network and choose to “Create New SHOP Type FROM VOP Network”. This will save the VEX code from the VOP Network into an OTL (operator type library, which is a collection of node types). The SHOP type in this OTL can be installed into any hip file, and used without requiring the New Glass VOP Network in the hip file. The advantage to this is that your hip files will be smaller and more efficient, and you can easily change the definition of the New Glass SHOP in all your hip files just by updating the one OTL file. The downside of this aproach is that as you continue to edit the New Glass VOP Network, all the instances of the New Glass SHOP type in other hip files will not immediately be updated. You have to re-save the SHOP type into the OTL.

So to summarize, SHOPs are materials that are defined by shader code. VOPs are a tightly integrated graphical environment in Houdini for writing VEX (mantra's shader language) shader code, and by doing so, to define new SHOP types.

To extend a bit on something I mentioned earlier, the VEX languageis not just for shading. You can create a VEX Geometry Operator VOP Network to write VEX code that will define a new SOP type. And all h same rules and methods described above for saving SHOP types to OTLs from VOP Networks also apply to these SOP types.

Anyway, I hope this makes things clearer as opposed to cloudier.

Mark
Adrian Cruceru
mtucker
…Each SHOP type is associated with a particular renderer.

can i blend them together, meaning, can i use rman for some objects and mantra for others? but in the end i have to pas through a ROP …

mtucker
So what about VOPs? VOPs are just a different way to define a SHOP type. Or, more precisely, they are a way to generate VEX code using a GUI (VEX code is used by Houdini for shaders, but can also be used to write SOP types, POP types, CHOP types, and COP types).

should i guess that VEX is like a c code ready to be compiled for whatever i need then?

mtucker
So a VOP Network defines a SHOP type. If you create a VOP Network of type VEX Surface Shader (even VOP Networks, which define new node types, have a node type of their own) called newglass, with the SHOP Type Name New Glass, then you have defined a new SHOP type called New Glass. You can now create 10 SHOPs of type New Glass. As you modfy the contents of the VOP Network, all the SHOP instances will change their behavior to match the new VEX code that the VOP Network is generating.

that's very interesting, looks like file referencing but in the same file, kind of clone of a node

mtucker
This will save the VEX code from the VOP Network into an OTL (operator type library, which is a collection of node types). The SHOP type in this OTL can be installed into any hip file, and used without requiring the New Glass VOP Network in the hip file. The advantage to this is that your hip files will be smaller and more efficient, and you can easily change the definition of the New Glass SHOP in all your hip files just by updating the one OTL file.

That's interesting, looks like a shake macro that uses another macro as a function but faster

does it run slower than using API to write plugins?

mtucker
Anyway, I hope this makes things clearer as opposed to cloudier. Mark

yes it does

thank you very much

now that's the way to go, using VEX you can boldbly go where no one has gone before …

JC, i started animation on SGIs so i love UNIX, by any chance is there a way to reference parameters graphically? for example in shake i can use nodename.parameter in another node to reference a parameter, in combustion it's the same tree, unix like structure (just it can't get that complex as in houdini)

once again, thank you for your help everyone

damn, i wish i had prisms in back in 93, jeff wagner showed me houdini 1.0 at IBC in 95 or 96 and i was blown away at that time but my road was already paved with alias products and i had to push maya to the limits so i'm sure it's not me the moron that can't get it done, but i'm rather bound by the limits of the tools. i'm sure there are bugs in houdini as well but i'm also sure there are more workarouds since it's more open.

i'm still trying to understand how was the whisky splash done for Johnny Walker years ago on Houdini 1.0 from someone at SPI i guess. I would love to understand how can it be done. If anyone was an example of that feel free to share it cause trying to replicate that in maya, xsi or max it's just a waste of time.
mtucker
adrian cruceru
can i blend them together, meaning, can i use rman for some objects and mantra for others? but in the end i have to pas through a ROP …

Mantra can't use Renderman shaders, and renderman can't use mantra shaders. So if you have some renderman shaders and some mantra shaders, the only way to have them both appear in the same scene is doing separate renders and compositing. Which of course doesn't let you do proper reflections or global illumination. But Renderman and and VEX are quite similar, so it's no that hard to translate a shader from one language to the other (or so I've heard…)

adrian cruceru
mtucker
So what about VOPs? VOPs are just a different way to define a SHOP type. Or, more precisely, they are a way to generate VEX code using a GUI (VEX code is used by Houdini for shaders, but can also be used to write SOP types, POP types, CHOP types, and COP types).

should i guess that VEX is like a c code ready to be compiled for whatever i need then?

Yes, you can think of it that way. It is nowhere near as general-purpose as C, but it's enough to let you do some amazing things.

adrian cruceru
mtucker
So a VOP Network defines a SHOP type. If you create a VOP Network of type VEX Surface Shader (even VOP Networks, which define new node types, have a node type of their own) called newglass, with the SHOP Type Name New Glass, then you have defined a new SHOP type called New Glass. You can now create 10 SHOPs of type New Glass. As you modfy the contents of the VOP Network, all the SHOP instances will change their behavior to match the new VEX code that the VOP Network is generating.

that's very interesting, looks like file referencing but in the same file, kind of clone of a node

I'm not sure I follow you here…? It could just be an issue of terminology, but you aren't cloning a node, you are defining a new _type_ of node. Or maybe you mean the same thing?

adrian cruceru
does it run slower than using API to write plugins?

VEX is generally very very fast. It uses a lot of optimized SIMD assembler code. So if you're just blasting through all the points on some geometry modifying the color attribute, you'd have to work pretty hard to write faster C code. But what VEX lacks is flexibility. You can't add new points to your geometry, or process primitives. But again, it's enough to let you do some amazing things.

I expect there are lots of good tutorials and examples floating around on odforce and the Houdini Exchange if you want to learn more about VEX.

Mark
JColdrick
by any chance is there a way to reference parameters graphically? for example in shake i can use nodename.parameter in another node to reference a parameter, in combustion it's the same tree, unix like structure (just it can't get that complex as in houdini)

Not sure I entirely follow the question, but yup virtually all fields in Houdini can be referenced using either absolute or relative paths, just like in unix. If by graphic you mean is there a GUI method to avoid all that typing, absolutely - for example right click over the Translate text of, say, an object and select Copy Parameter. Right click on some other similar 3-entry field and you have a multitude of paste options.

You can similarly drag and drop fields too.

Cheers,

J.C.
Adrian Cruceru
mtucker: what i meant about the clone thing is that if you are defining a new type but the source of these node remains the same, just an analogy between a clone in xsi or an instance in maya where changes do propagate from the source to the destination. it's an analogy. i know it's more than a simple clone or instance

J.C. i was asking if there's a way to see all nodes in a scene (like treeview) and use a tool similar to drvien keys in maya, drag a node on top of another node opens a window and ask you to link avaiable parameters, in shake you just ctrl+drag from one node to another node parameters to link them. since the scene is an unix file system you have to go up and down the path to get the nodes so you never have all the nodes in the same time displayed in the UI (except treeview i guess). it's pretty hard to make an artist understand the relative path of a file system especially when they have shells. but if you can drag and drop fields it's more than enough (appart copy/paste parameters)

one thing that blew me away was the fact that i can control rendering with rgb channels, one of the biggest limitation of maya is the hardware rendering system, you cannot control the line with of a particle render in time, you can control the length of a line rendered particle through speed (up to a point) but you cannot control on per particle basis the width of a line. i find that amazing in houdini

and i'm just opening the box. i can't think of what i'm gonna find inside.

cheers
RickW
adrian cruceru
J.C. i was asking if there's a way to see all nodes in a scene (like treeview) and use a tool similar to drvien keys in maya, drag a node on top of another node opens a window and ask you to link avaiable parameters, in shake you just ctrl+drag from one node to another node parameters to link them. since the scene is an unix file system you have to go up and down the path to get the nodes so you never have all the nodes in the same time displayed in the UI (except treeview i guess). it's pretty hard to make an artist understand the relative path of a file system especially when they have shells. but if you can drag and drop fields it's more than enough (appart copy/paste parameters)

I hear ya! There's a couple of things you can do here….
you can load a floating parameter (rmb on op, choose parameters) window of your selected operator for your dragging/dropping of channels from one part of the network to the other. OR..

You can unlink panes (see UI section in manual) and use another pane to navigate to a different part of the network you need and then open the parameters for that op.

Does that make sense?
Adrian Cruceru
yes it does make sense. i would love to see a window with all the nodes but like a huge dependecy graph, kind'of like shake where you can visualy see if there are parameters connected.

with all the panes i need i feel like having 2 monitors it's a must in houdini.
judithcrow
you might find it helpful to view the dependencies thsi way:

in the network view hit the “d” key to bring up the Display Options.
Go to the Dependency tab.
turn on as many types of dependencies as you'd like to view
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB