Marc Albrecht


About Me



My Tutorials

Recent Forum Posts

Orienting Geometry to Look Along a Curve Sept. 17, 2017, 6:23 a.m.


like Konstantin states, the video is unavailable - maybe you set it to private?

In general, one “standard” way of having geometry “look ahead” on a curve is to have a second locator/null/handle move along the same curve as the geometry, but slightly ahead (if you are using a percentage value for the current position of your geometry based on the timeline, you can grab that value and just add some arbitrary small value on top).
That way you have a goal for a “look at” constraint for your geometry.

One problem with this approach is, of course, that narrow turns can create problems, if the look-at-target is coming back at the geometry, passing it by too fast. But that's a) a layout question for the curve, b) a question for fine-tuning the offset between the two components on the curve and c) shot-dependent

I hope this helps. Let me know if I should make a video …


What are the seed, global seed and get attribute?! Sept. 15, 2017, 3:23 p.m.

Moin, peach,

your question is a bit out of context - it's like asking “I'd like to know the meaning of pressure, temperature and espresso, please”.

Just taking the terms you mentioned, I can suggest a) to read the documentation, b) watch some introductory tutorials and c) experiment. And d) these:

seed/global seed: A “seed” usually is used as a starting point to generate virtual random numbers. On modern computers there is no such thing as a “random number”, instead most programs use (large) internal look up tables with pre-created “random numbers” from which they then take a sequence of numbers to provide you, your program or whatever with “what looks and feels like random”. Unfortunately you will get the same sequence of numbers every single time you start the program with the same starting parameters, so “seed” defines *where* inside the huge lookup table this sequence should start.
So in animation, simulation etc, basically everything that is time- or frame-dependent, you will most likely use the frame number as a “seed”, aka “starting point” for randomization. Yet, that will still give you exactly the same sequence everytime you start the simulation (which might be exactly what you want to get, but maybe not so). If you can get hold of your system's time, adding that into the mix will obviously enhance your random-experience.

Anyway, “seed” is the starting point for a random-number sequence.

“get attribute”: Houdini uses “attributes” on “things” (points, primitives), which basically are VARIABLES with their respective VALUES. An example would be the color of a point on some geometry, which would be the point's “Cd” attribute, which would usually hold a 3 component vector (for r, g and b color values).
Since you have to read out the current state (value) of variables (attributes) in any semi-complex setup (“has that particle hit the ground yet?” would be an attribute of a particle-point), you need to be able to “get attribute”. That's what “get attribute” is about: It reads out the value of an attribute either of geometry on disk (cached) or in the current graph (a node's).

I hope any of this was helpful. Have fun learning Houdini!


Rigid Body object colliding with FEM object.. Sept. 15, 2017, 6:54 a.m.

Moin, no,

could you give more details about what exactly you mean by “collision”?
Houdini's documentation states that solid objects using FEM as their solver system can be affected by other dynamic simulation objects (like RBDs driven by bullet), but if they are expected to also effect other objects (being repelled and repell) the other objects need to be FEM driven, too. Or, in short, the documentation says that “off the shelf” you don't get FEM-to-RBD collision, only the other way around.
So, what “kind” of collision do you expect (energy transfer in both directions? If so, according to Houdini's documentation both objects need to be FEM solved).

Also make sure that, if you are using geometry based collision detection, Houdini usually only considers collisions on the “outside” of polygons, i.e. where the normals are pointing towards (point order of geometry is of essence here).