Curve Attraction Animation

Been toying around and coming to grips point clouds in SOPs. The following tests in a nutshell use one set of points to look up another using point clouds, a little more magic is performed in a solver to animate the curves between the found points in the point cloud and the curve points original positions.

Tree Maker - Demo Video

Tree Maker Tool - part 4

In this part on the Tree Maker, I've added some additional settings for the leaves, creation, placement and orientation. This gives the leaves a more realistic look.

Images below demonstrate the difference, 

without and with the additional placement of leaves 

Tree Maker Tool - part 3

The following rendered trees, demonstrate some of the variations of tree types that can be generated with the Tree Maker Tool.

Tree Maker Tool - part 2

Tree Maker Tool - Test Renders

5 unique trees used in following instance renders

20,000 instanced trees recycling 5 unique trees

40,000 instanced trees recycling 5 unique trees

Tree Maker Tool - part 1

Here's some trees procedurally created with the Tree Maker tool I've been working on. For those that might be interested in the internal implementation detail, it doesn't use l-systems, it's amazing what you can be done with a few nodes, copy sop inside a for loop each and some python code, obviously a bit more to it than that but that's the core of it.

Python hou.runVex()

In a previous post I managed to find and implement the math required to find intersection point between 2 lines in 3D, which was interesting and a challenge.But in that and other situation I often wonder how I can exploit Houdini more when it comes to this kind of math, as Houdini's nodes already implement so much. Quite commonly cases arise where I'd like to run some python code against a node, ie. Invoke a node, pass some geometry and return the output.

That's where I got to thinking that VEX actually has a lot of powerful functions that Houdini's python doesn't, Then I remembered coming across the hou.runVex() method. After spending the best part of a week getting to grips with this workflow, thought I'd write down some of my findings, since there's not much out there on this topic.

Things of note when using hou.runVex(vexfile, inputs)

1. The inputs argument can't be an empty dictionary, even if there aren't arguments defined on the cvex function.
2. I've found that cvex must be the context function, at least when working with the Python SOP. Although don't quote me on that needs more testing.
3. When compiling, it's safest to rename the .vfl when changes are made, at least for a successful compilation to vex. e.g.. Say you have a file named attrib.vfl and you compile it to attrib.vex successfully, upon making code changes to the .vfl it's safer to rename the file attrib_01.vfl and compile this to a corresponding .vex file. This will ensure that the vex file reflects the changes.
4. There's conditions to passing lists or arrays in the inputs dictionary, they must have the same length and each lists items must be of the same type.
5. Also related to input arguments having length > 1 , e.g. Lists or arrays. Theses types will affect the exports/bound variables length, causing outputs to also display matching length even when their default value is of a single value.
6. Another point worth noting regarding inputs when using lists is that they effectively form a kind of loop, running the vex code as many times as there are items in the list. This ability could be utilised to emulate functionality akin to the vex/vop nodes parameter run over : points, prims, vertices, detail.
7. It also seems, a least for vector type inputs, they must be contained in a list or array type, ie When passing a single vector, it will need to be in an list of 1 item, or the function's input argument default defined in vex will be used. This doesn't seem to be the case with strings or integers, which makes me wonder whether it's due to vector types having native length in it's components.
8. This point needs more testing, getting some very strange results which are difficult to track down.I think there is a memory issue, although it could be due to way vex works! Not entirely sure. Can't recall exactly, but in the docs it talks about how vex is compiled and that it doesn't allow for recursive code. One odd effect of running vex via Python in this way, is that you can refer to the returned value before you've made the call. eg

          
     print a
     a = hou.runVex()
   
     This will work fine!
     Then again it doesn't, as it shouldn't.
     
    

   I think there maybe a memory related issue, because although the vex is running as expected, it seems to store the result in memory and that's why the above call to variable "a" before it's definition works, occasionally. Now when I change position values via an upstream transform node, the results of the vex also transform when they definitely shouldn't be. The kicker is when I save the hip with the upstream xform and reopen the hip the results are as expected. Also the variable ref that was working now doesn't, errors as expected. which brings me back to the vex in memory being the problem.

In Short, It works! Mostly.
As long as the above points are considered, hou.runVex() should work as expected. This workflow has the potential to be very helpful and powerful, which I'd like to use more often. Though the last point is a bit of a concern.

DOP Multiple Cloth Objects using Copy SOP

Multiple Cloth Objects can be created using the Cloth Object DOP, where the Initial Geometry contains multiple pieces of geometry, e.g.. Grids. (In many cases this geometry would be created by way of the Copy SOP). Actually to be more specific the key is Primitive Groups not so much pieces of Geometry, although those usually coincide.

Before continuing, I have to mention that although this process technically does as it says. The aim was to constrain each Cloth Object individually and dynamically(number of Cloth Objects). I have found it didn't give me the outcome I was looking for, ie. Constraints only work on a single Cloth Object, however I do think the may be a way, possibly using Copy Data DOP.

On the Creation tab of the Cloth Object DOP changing the following parameters:-

• Number of Objects : This would contain an expression that equates to the number of copies required, this will depend on your particular setup. 
• Pointing to the Number of Copies parameter of the Copy SOP using ch("your_copy_sop_location/ncy") would be one way.

• Using the npoints("your_copy_sop_location") expression could also be used when there are Copy SOP Template Points being used

• Object Name : "name_prefix" $OBJID   note : Quotes aren't required for the name_prefix 

Now this setup so far will create x number Cloth Objects with exactly same Geometry! So the trick is to isolate the Geometry for each Cloth Object based on the Primitive Groups created in the SOP context, in this case by way of the Copy SOP. As you'll notice there isn't any Group or Primitive Group parameters on the Cloth Object. You can however add the appropriate parameter, by editing the parameter interface of the Cloth Object DOP you can add a parameter - Primitive Group. It can be found via the Create Parameters - From Nodes tab, expand +Cloth Object + clothconfigureobject1 + sopgeo_initialgeometry1(Geometry) + Primitive Group (primgroup). move the parameter to the Cloth Object Creation tab. Finally in the Primitive Group parameter place an appropriate group name followed by the object id variable : "your_primitive_group_name"`$OBJID`   note : $OBJID could be affected by other simulation objects

The following screenshots show the Cloth Object and Geometry Data before and after the changes. Notice the standard setup Cloth Object contains all the copied geometry points, apposed to the altered setup, has multiple objects which only contain a subset of geometry based on the primitive group/s.

Mushroom Asset Development - Renders : Shaders

Mushroom Asset Development - Renders : GI

Initial mushroom renders.
Fairly basic light setup and the mantra surface shader.

Multiple camera renders:

Multiple object level copies of the mushroom asset, posed in world space simply for the purposes of render testing

Same again with addition of DOF