How did you build this site?
It's MediaWiki running the Chameleon plugin so that it can use Bootstrap skins. The particular skin I'm running is Yeti from Bootswatch. I also use the MsUpload plugin to make it easier to attach files.
Can you do video tutorials?
I don't have time unfortunately. In addition I like this to be a quick reference guide, so you can quickly find the example hip and text and get on with your current project, rather than have to sit and watch me ramble for 70 minutes to get to the bit you need. Maybe I'll get more time in the future.
Can I support you?
You sure can, head over to Support.
How do I clean up curves so there's less points on straight segments?
Facet sop, enable 'remove inline points'
How can I make a wireframe of my shape?
Ends sop, 'unroll'. For those coming from Maya, you know how paintfx is ultimately lots of single curves that are welded together, but they're limited to paintfx, you can't really use them elsewhere? Houdini treats standalone curves as a 'polywire', so edges don't have to belong to a polygon to be valid. Very powerful.
How do I tell a copy sop to point copies along @N, but have random rotation around that normal?
Lots of ways, simplest way when starting out is with an attribute randomize sop to create an @up vector; the copy sop will now treat @N as the primary axis to align the copies, and use @up to define the twist around @N. Create an attribute randomize sop, attribute name to up, leave the dimensions as 3, set distribution as 'direction or orientation', enable 'cone angle', and slide it up to taste.
How do I get a stable scatter on moving geometry?
Use an attribute interpolate sop. Scatter on a frozen copy of your geometry (use a timeshift with the frame expression disabled), on the output attributes tab enable 'sourceprim' and 'sourceprimuv', then wire that to the first input of the attribute interpolate, and the moving geometry to the second.
How do I scatter points inside geo rather than on the surface?
Convert your geo to a volume first, then scatter (can use an isooffset sop for this, or a VDB from polygons sop in density mode)
How do I carve lots of curves at different rates?
Carve is one of the older sops, so it doesn't give you any built in control to randomize growing lots of curves. You could use a stamp or a for each loop, but that gets slow quickly.
Mawi on odforce has a very clever trick; he realised the fur grooming tools have the ability to trim curves, had a snoop around, found a vex function. More info is here: http://forums.odforce.net/topic/19626-carving-multiple-curves-by-attribute-hip-file-attached/ .
In a pinch I've done a very lazy way and just deleted points based on the curve uvs.
Another trick is to store the curve positions with a rest sop, transform the curves to origin, clip them, restore position. I have an example of that here: https://www.tokeru.com/cgwiki/Houdini#Procedural_growth_via_edge_transport
How do I turn selected edges into curves?
Dissolve sop, and sometimes a polypath sop too. Select your edges, and in the viewport put down a dissolve sop. By default it removes the selection, change the delete mode to 'delete non-selected' to reverse this. Enable 'create curves when dissolving boundary'. If you're in wireframe mode this should see the curve, but in solid shaded it might be invisible. Appending a polypath sop will fix this. If you want all the internal extra points on straight sections, disable 'remove inline points'.
Use the Sidefx Labs tool for that. :)
Why can't I export fbx/alembic/big images/animations?
You're probably on Apprentice, it limits the kind of things you can export to make sure you can't use it in production. Buy an indie license!
The help files are slow!
Yes they are. Use the online link instead: http://www.sidefx.com/docs/
Unfortunately the example links won't work, so if you want them you need to use the local help.
Houdini on OSX behaves strangely!
Yes it does. Houdini relies on good OpenGL support, Apple keep dragging their feet on this (Apple maintain the drivers, not Nvidia/ATI), there's not much Sidefx can do about that.
Mantra is slow for simple things!
Yes it is. But its not as slow for complex things as you'd expect, when put in the right hands it can be compared to most commercial renderers. It's current design goals are to be the jeep of rendering, not an F1 car; its reliable and will get you there, but not in a hurry. Everyone who wants renders quickly seem to be having great success with Redshift.
Whats the difference between Vex and Hscript and Python?
In a broad sense Houdini is a tool to modify data on geometry. Vex is a direct way to do that, its fast, multithreaded, inherently designed to work with large amounts of geometry in parallel. Vex is most often used in attribute wrangle nodes, and can be identified by using @P syntax to refer to attributes.
Houdini also contains a UI, and a unix flavoured high level overview of your data. Hscript is designed to deal at this level; driving UI elements with expressions, moving around your scene with 'cd' and 'ls' if thats what you like. Its the UI expressions that hscript is most associated with, and generally speaking whenever an older tutorial references hscript, there's usually a better vex alternative to use. Hscript usually features $VAR variables, though of late you can often replace the more standard hscript variable names like $T for $F for @Time and @Frame, which makes it more confusing. It appears there's a long term goal to remove hscript from Houdini, but that won't be for a while.
Python is python. If you know what Python is, great, if not, its a handy generic glue language common to most vfx apps, and comes pre installed with linux and osx (and is an easy install for windows). Within Houdini its used to create and delete nodes, define shelves, drive parts of the UI, open files, talk to databases, websites, run the help system... anything that involves stuff outside geometry processing, thats where Python in Houdini is used.
Look a little closer and the lines are blurred (you can use Python to do geometry processing and define UI parameter expressions, hscript variables can sometimes be understood by vex wrangles in a roundabout way), but thats the general overview. Vex is the interesting stuff, hscript is the necessary evil, python is for pipeline td's or for when vex doesn't have the function you require.
Whats the difference between attributes and parameters and variables? Why this $ vs @ stuff?
Attributes belong to geometry, and use the @ prefix in wrangles. By saying they 'belong' to geometry, they're data that rides inside your shapes. So at the most basic level, @P is an attribute, which is position. Each point has @P. Points can also have colour, @Cd, or any other attribute you choose to store. Verticies and primitives can also have attributes, eg @N for verts, or @shop_materialpath for prims. Wrangles also provide some bonus virtual attributes that don't belong to geometry, but are still available like @Frame and @Time.
Parameters are UI elements. The number of divisions on a grid sop, the scale of a box, the number of points to be scattered, they're all parameters. An analogy is if you were to treat a Houdini file as a car factory, attributes are things on the car parts that are being assembled, parameters are the buttons and controls on the robots and machines building the cars.
Variables are hscript things that are prefixed with $. More on those in a bit.
But here's where things get a little confusing. Parameters are usually set by the user, but in some cases they can automatically be linked to geometry attributes. In other cases they can be controlled by expressions that also read from geometry attributes. Which parameters can be controlled in which way isn't consistent, and usually requires reading the docs, or more likely, asking a more experienced Houdini user.
For example the polyextrude sop has an extrude parameter, but it also has an extrudescale parameter; if you put the name of a primitive attribute in there (without the @ prefix!), and that primitive attribute exists, then each primitive extrude distance will be set by that attribute.
In other cases, you could use use an expression to set the translateX on a transform sop by reading a point geometry attribute. This involves some hscript trickery, and note that unlike the polyextrude it won't magically move each point or each prim a different amount; you'd need to explicitly choose one point to read from.
That said, other sops and other parameters can read from each point or prim, and affect each thing differently. How can you know when this'll work? By reading the docs, or really, by asking others.
The clue in the docs is it will probably mention $ prefix'd things, the variables I mentioned earlier. These date back to earlier builds of Houdini and it's unix style underpinnings. $HIP, $OS, all that stuff. Some sops define their own $ variables, and allow for special behavior. This might be stuff that is spatially aware of the geometry ($XMIN), or the number of points ($NPTS), or the width of a wire-to-tube extrusion ($WIDTH). Again, this is specific per sop, and in some cases it can be actual user editable point/vert/prim/detail specific data.
Wait what? Yes, this is where stuff gets really confusing for new users. In some cases you can middle-click on a sop and see it has @width defined as an attribute, but also $WIDTH defined as a variable. Houdni does an internal mapping so that width is available in either format, depending if you need to access it from vex or from hscript.
But there's more! There's a small set of variables where you can use pretend vex attributes in hscript expressions, like @Frame and @Time. This was introduced to try and make things easier, but in fact it becomes more confusing, as new users assume 'oh cool, I can use any vex attribute in a hscript expression or group expression', when you often can't.
Unfortunately for new users this is not easy to navigate, but at least you're warned. If you create an expression or do something with @ or $ things and it misbehaves, ask a more experienced Houdini artist, they'll usually be able to quickly spot the error and offer a solution.
Why can't you have spaces in group syntax expressions?
The simplest group expression lets you select points 1, 3, 5, and 8,9,10 with the syntax '1 3 5 8-10'. Spaces mean something.
If you try and do an expression with spaces, eg '@P.y < 5', the group expression interpreter doesn't know any better, and will try and read that as 3 individual things.
Remove all the spaces from your expressions, or use vex to define groups, and call them by name later.
Why do some node parameters support attributes and others not?
This is related to the hscript/vex/python question earlier. Certain nodes, like the older point sop, could reference lots of interesting hscript dollar-prefix-uppercase name things like $CEX for the centroid x position. Its important to remember that this was hard coded to that particular sop; you couldn't use $CEX for a divide sop for example.
With the gradual push to remove hscript, it makes sense that any newer sops should lead the way and show how we can use vex style attributes instead of hscript variables. The polyextrude sop does this; on the second tab you can enable attribute control, and if your prims have a @zscale attribute that will drive the extrusion length (you can use whatever name you want, zscale is the default).
But in a similar situation to the older hscript aware sops, the newer sops have to be explicitly designed to support this. Unfortunately there's no way to know ahead of time what sops do what, apart from reading the help cards or pulling apart other peoples setups.
The alternative is to skip sops where possible, and do as much as you can down in vex and vops. They'll implicitly be attribute aware, and less confusing.
Make sure you're in the right network context. A main point of difference of Houdini compared to other apps is that has lots of different types of networks, each with its own set of nodes. The top level nodes are the object network context, which is like the outliner in maya, its mainly transforms. The sop network context is where you spend most of your time, its modifying shapes, and has the widest range of nodes. Vops is the visual coding environment, and even this can change the kind of nodes in the tab menus depending on if you're visually coding deformers, or shaders, or other things.
To make it a little more confusing, some nodes are common across several network contexts. Eg, you can merge in sops, or dops, or rops (render operators), they all have slightly different behavior. As with most things in Houdini, the more you use it, the less confusing it becomes.
The other possibility is it's an old node that's been depreciated. Sidefx are constantly refining their workflows, a byproduct of this is if you read a tutorial for Houdini 8.0, it's possible those nodes no longer exist. If you're not sure its easiest to ask on a forum or chatroom for help.
How do I refresh stuck textures in the viewport?
In a texport, glcache -c
I have multiple named bits of geometry in my dop network, how can I refer to them in a wrangle?
You need to use the full name, so 'obj0/second' rather than just 'second'. And its the dops name, not the path to the node where you defined the name. Very confusing!
How do I setup dependencies so that a sim is cached before a render starts?
Use a Fetch rop. You'll usually have a FileCache sop directly after your dopnet to write bgeo's to disk, look inside and you'll find a rop output driver. A fetch rop is designed to trigger rops like this, so in your rop network you can put down a fetch rop and connect it before your mantra rop, and point the fetch to the 'render' rop that lives inside the FileCache.
Why does a dopnet show me different things if I'm inside vs outside the network?
This is a common thing, you'll pop down a popnet and a ground plane, and when you go outside you see all the things, but if you do a pyro from scratch you see all the volumes when inside, but from outside you see nothing at all.
The trick is to look at the dopnet parameters, and see what it's exporting. It gives you a choice of objects, and a choice of fields. The objects is for the dop objects, so the popobject, the smoke object, the packed rigid body object etc. On popnets it defaults to '*', ie, export all the objects, which is why if you put down a ground object, you see it. Rather than go and find explicit names, I know that I usually leave the object names as their defaults, so I'll just do a lazy wildcard for the kind of sim I'm doing, eg '*pack* for a packed rigid body sim, or '*pop*' for particles.
Volumes require a little more work, that's what the second field is for. Because a smoke object could have many fields ( density, vel, fuel, temperature, Cd etc), it expects you to be clear about what you want. For smoke I know I can just put 'density' and leave it at that. If you want more, use the fact that it's a multilister, and do a new entry for 'vel' or whatever you need.
This is all being lazy and hacky (but it works fine for me). The 'official' way is to use a dop IO node, where you point it explicitly to the dopnet and dop object, but then you get to use the presets combo box to bring in exactly the right field (and display/visibility options) for smoke, or fire, or whatever else.
Why do my RBD objects seem to freeze after 2 seconds?
It might be the default sleep time. Go to the rigid body solver, change the default sleep time from 2 to 0.
I loaded an old example and it used a volume source, what do I do post H17?
- Old: Volume Source
- New: Source Volume
Oh Sidefx. At least the new one doesn't require the annoying opinputpath expression, it has a dropdown to choose which input you're sourcing from, which is handy.
- How can I zero the transform of an object and have the internal geometry remain where it is?
- How to generate a sweep with two curves and get automatic uvs based on the curve knot points?