Jeff Wagner

old_school

About Me

Expertise
VFX Artist
Location
Canada
Website

Connect

My Talks

obj-image ILLUME Webinar
FLIP Fluids | Part 1
obj-image ILLUME Webinar
FLIP Fluids | Part 2
obj-image ILLUME Webinar
Pyro FX | Tips and Tricks
obj-image ILLUME Webinar
Houdini VOPs
obj-image ILLUME Webinar
Geometry Workflows in H16
obj-image ILLUME Webinar
Learning Houdini

Recent Forum Posts

Simple jitter/sway animation on instances Aug. 23, 2019, 8:53 a.m.

Since each unique instance type only supports shader/displacement and render property changes per instance, you will have to generate sequences of tree geometry with motion on them. Then use modulate to cycle over the tree sequences when you instance them.

How you deform the trees is a different question. I am not familiar with SpeedTree these days but if it spits out a skeleton (like I remember I think…), then you can use the Edge Transport SOP to crawl up the trunk-branch skeleton curves (fuse the points so branches fuse to branches etc. fuse to trunk).

Edge Transport SOP creates a distance attribute starting at the point you choose which should be the base of the tree. It's a distance attribute that allows you to add more movement the longer the distance. If there is a width or thickness attribute even better to help add deformation.

Then drive the skinned tree with the skeleton.

Leaves should be instances with instance points. Hopefully they have a local frame of reference (N and up or an orient matrix) that is super easy to sway about with vex.

Then generate your sequence of deforming trees as a cycled animation to disk wedging as many as you want.

Generally 10 instance sequences per type of trees works well enough with a cycle length of 4-5 seconds.

Particle Lifetime measured in seconds? not for me! June 12, 2019, 5:46 p.m.

Your approach is a good one. Using a volume to create a lattice of points is one way.
Another is to create a density field and scatter points by volume as well.
This second approach allows you to scuplt the density with noise to create a non-uniform distribution.

If you “want” a uniform distribution of points, you can also use a Box SOP set to lattice and add the internal divisions then use an Add SOP to delete the geometry but keep the points.

I believe the offset may be due to the original bean's origin not aligning with 0,0,0 in the current object. Or if you are using a bean at the object level, there may be a transform present there that is causing the offset.

I whipped up a quick file to show one way to create floating coffee beans around a mug using Bullet Simulation to add motion and to solve for self-intersections.


Note:
- how to construct a proper convex decomposition for the mug to help Bullet collisions
- construct volume to build points from by subtracting the mug volume from the base volume to avoid beans interpenetrating mug.

Quick question... June 12, 2019, 9:20 a.m.

vex functions opfullpath()and relativepath() return paths to nodes.

http://www.sidefx.com/docs/houdini/vex/functions/opfullpath.html [www.sidefx.com]
http://www.sidefx.com/docs/houdini/vex/functions/relativepath.html [www.sidefx.com]

Here's one way to use opfullpath to return a string node name:
s@pathfull = opfullpath("../timeshift1");
s[]@pathsplit = split(s@pathfull, "/");
s@nodename = s[]@pathsplit[-1];
Just replace the s@pathfull and s@pathsplit to internal variables to avoid attribute bloat. Just exposed for clarity.


Now I have to ask, what are you doing?
It isn't that efficient to fetch a single node name for all the data/points you are ripping through.
If you have unique nodes to apply to different items you are processing, sure. But strings aren't the most efficient method through vex for lots of data processing.

It may be better to put a local spare parameter on the node and build out the string once as a set of parameters when the node cooks.
Python is very powerful at string manipulation while in vex it is somewhat limited…