Apologies for the necro thread, I was seraching an unrelated issues ran into this post.

The offending program isn't qwavefront.exe, but should be gwavefront.exe.

A fair number of file formats are supported in Houdini by using standalone programs to do the conversion. gwavefront, gdxf, gply, etc. When houdini tries to read or write a .obj, it will instead launch this program to do the task. This is usually done with pipes so no files go to disk, but the gwavefront program doesn't know it was invoked by Houdini. Thus, it has to check for licenses to see it is allowed to run. This usually involves contacting hserver. In most configurations, this should be entirely local connections, which is why it will run normally unattached to the network. But it surprisingly difficult to separate local from external connections, which is probably why Zone firewall is tripping on it.

It isn't a stupid question.

hscript is a shell-like language, similar to csh or bash.

However, when you use back-ticks to escape it doesn't run shell commands, but a separate expression language. This is also the language that is used by default in parameters.

If you open a textport in Houdini (Windows::Textport) and type
3 + 2
it doesn't work because it tries to run the command 3

But
echo `3 + 2`
will invoke the expression language and evaluate 3+2.

I tend to call the expression language EXPR, but most people will just call it HScript. But I think it is simplest to think of there being Python VEX, Hscript, and Hscript Expressions as separate languages to learn. It is likely you don't have to learn HScript, only Hscript expressions, for example. Most of what hscript did is better done with python.

Our goal was to remove both Hscript and Hscript expressions and replace them with Python. Due to performance issues, however, HScript Expressions are likely to stick around.

An embarrassing bug!

Thank you for isolating & reporting this.

Hopefully 18.0.339 will work for you without the need for workarounds.

pickled
Paint Attributes/Attribute Paint SOPs redundancy?

“Situation normal.”

I wanted “Tab->Paint<enter>” to get you the new paint sop. So it has to be called Paint Attributes in the tab menu for that. But the natural naming scheme for this is “Attribute Paint” to match the other Attribute prefixed nodes.

Of course, we allow typing names out of order in the tab menu, so whichever you type the other will show up… Best course would likely be to have only the highest-matching variant show up in the menu, but that will require a fair bit of extra metadata to tie the tools together.

In the vellumconstraintspropertiy it is bound to the Constraint primitives. Thus @PinSelection would read the primitive attribute on the constraint geometry, which likely isn't where you have your animated data.

This is why you likely want to use a point() expression to read from one of the other inputs, and set that input to the animated geometry. In particular,

stiffness = 1e10 * point(2, ‘PinSelection’, @ptnum);

would work if the Third Input (2) is set to point to the SOP that has the animated PinSelection attribute.

Note stiffness is exponential, so it will be pretty much on/off even for intermediate values of PinSelection like 0.5.

The vellum constraint node is only run on the first frame. So it creates all the pin constraints on that first frame. The “Animated” flag adds an attribute that the target position to be updated, but will not re-create the pins. Thus it won't notice that the group has since changed. This might seem a pedantic separation when the group is “pins” as it seems trivial to re-evaluate membership in that group. But that generation group can be any arbitrary expression.

Since you created soft pins they exist as spheres on the Constraints geometry.

The easiest way to deactivate them is to set their stiffness to 0. You can do this in the vellumconstraintproperty DOP inside the forces tab.

The Animated Constraints help card example shows a setup reading in to a vellum constraints property. You could do similar with a vexpression of

stiffness = 1e10 * inpointgroup(2, “pins”, @ptnum);

and then set the Input 3 to point to where the pins group is animated.

Faster way might be to use nuniqueval/uniqueval to see if the string attribute has only blank strings in it. Can do it in a detail wrangle that builds up a detail string of attributes to delete that the attribute delete brings in with a details() expression. Bonus points is to wire your geometry to test to the *second* input of the detail wrangle so you have no copy costs for generating this.

The peculiar behaviour of disableself may be found in the vellum attributes docs:
http://www.sidefx.com/docs/houdini/dyno/vellumattributes.html [www.sidefx.com]

The idea of how to use this to solve this case isn't in the docs. We're exploring how to make as a proper built-in, and will probably be adding an option to the vellum solver to auto-disable freshly broken welds.

One issue is that if your tear is pulling apart quickly, you don't want to auto-disable as it may cause layered cloth to fail.

In VEX:

In the EXPR world (expressions outside of VEX)



So it is just convenience.

Groups can be ad hoc groups, so don't need to be created ahead of time.

So you can use the group “53” (note a string holding 53, not the integer 53) to find distance to primitive 53. sprintf(“%d”, primnum) can be used to generate such a group.

A big warning, however: internally it will have to create a group for all those primitives. So while it won't be as clunky, there may be more expense than you expect if every point creates a different group.

The samples of Houdini volumes are stored in the voxel centers. If you use volume slice, you will notice that it is half a voxel smaller than the original volume on each side as it is placing the generated points at the volume samples, not the corers of the voxels.

howiem
Or is the VEX compiler smart enough to recognise variables that won't change per-point, and just calc/cache them once?

Pretty much this.

There are three levels of computation:
1) Compile time
2) Once per point block (uniform)
3) For every point

If you have code like:


The sprintf() will actually be computed at compile time.

If you have code like:


the ch() function has no per-point dependency, so will be marked uniform. Thus the sprintf() likewise will be uniform and only evaluated once per point-block. Point blocks are 1024 in size, so for almost all cases are pretty much equivalent to only evaluating it once outside the loop. It has to be pretty exceptional for me to consider pre-computing something rather than trusting the VEX compiler.

No, that currently can only be done by making that external object a volume collider and using collisionignore.

The main thought with hair is to use the Glue nodes to set up soft constraints to lock hair together. This has a lot of options for clustering which can be used to control pairwise generation of the glue.

Such attributes are planned; but many things are planned, so I rather focus on what is actually done. :>

If you are colliding with static objects using a DOP setup, you can switch the objects to Use Volume Collisions. Then the collisionignore attribute will work. But this means you lose the edge/edge collisions that can be very useful for hairs.

For controlling pairwise collision within dynamic components of a vellum solve, there is no attribute now.

I couldn't reproduce this as it was fixed in 17.0.374! So when you next update it should work. Thank you for the reports!

A .hip file is a thousand pictures.

If your cloth is stretching too much, first increase substeps to 5 if you haven't already. Then increase Constraint Iterations to be at least the diameter of the cloth in edges. Higher res cloth needs more iterations.

You can't animate the input to the vellumsolver, as this is only read for the first frame.

Instead, for the SOP-based Vellum Solver dive inside it and add a Vellum Constraints Property. This lets you modify Rest Length scale there. You may want to create constraint groups to ensure it modifies the ones you want.

For DOP-based vellum solver, it is a similar idea, wire in a vellum constraints property like you would any microsolver.

Your analysis seems quite right. Stripping those points from the neighbourlist is what the don't-collide-with-explicit does. I'm glad you were able to find the right code to add it.

As for speed, I'd expect a proper apples-to-apples to match speed in both cases. One big difference is we've locked down the Vellum path to be only support OpenCL and only have constraint averaging disabled. But we call the same kernel in the inner loop, so I'm not sure where the speed up occurs.

Another issue with Vellum is the auto-sleep likely won't be as effective in speeding up the sim. So I can see pure grains still being used. Which is also why we kept all those shelf tools.

I'm unable to reproduce, it toggles the piece visualization for me?

Can you please submit a bug with a .hip file that shows how you have this set up?