That should work as written. Possible problems:
@opinput uses `id` attribute if it exists to match pairs of points so it works with particle systems for free. This becomes surprising if you have an `id` attribute that means something else. Under Bindings, erase the default `id` for attributes to match.
There may still be annoying bugs with VEX not refreshing its bindings cache when @opinput is used when nodes re-wire. Adding some white space to your wrangle will force a re-cache. If this does fix it and you can reproduce, please submit a bug as we want to fix these bugs. (For performance, we don't re-scan all the attributes when we re-cook if we think they are the same, but @opinput bindings have confused this in the past)
Found 390 posts.
Search results Show results as topic list.
Technical Discussion » Simple VEX Question
- jlait
- 6220 posts
- Offline
Technical Discussion » Has Turbulent Noise VOP changed?
- jlait
- 6220 posts
- Offline
Turbulent Noise VOP didn't change, but Simplex noise did. Unfortunately, the change did not enable us to keep the old version around, so you'll have to bake the values if you require a match in 16.
From the Compatibility logs:
Houdini 16.0.480:
The VEX and OpenCL versions of Simplex noise and Simplex-based curlnoise have been re-implemented for improved quality, particularly in 4-D, at a slight performance penalty. While the overall look of the new noise should be similar, the noise values for a given input will be different and could cause backward incompatibilities.
From the Compatibility logs:
Houdini 16.0.480:
The VEX and OpenCL versions of Simplex noise and Simplex-based curlnoise have been re-implemented for improved quality, particularly in 4-D, at a slight performance penalty. While the overall look of the new noise should be similar, the noise values for a given input will be different and could cause backward incompatibilities.
Technical Discussion » UV Flatten In Houdini 16
- jlait
- 6220 posts
- Offline
Shiva99
if I select all the prims, then nothing appears in the group field; and
That is normal. An empty group field means all the primitives, so when you select all it will be replaced with an empty string.
Shiva99
- If I insist, “BOOM” “Fatal Error!”
That isn't normal. You should get a warning about their being no boundary for it to flatten. What do you mean by “insist”? Can you save a .hip file prior to the crash so we can make sure we're trying to reproduce the same thing?
Technical Discussion » $N - variable in filenames not working in H16?
- jlait
- 6220 posts
- Offline
$N does not work in the File Cache SOP, only in ROPs themselves. This is a limitation of local variabls (which $N is an example)
maybe used.
filename.`rint($FF*2)`.bgeo.sc
maybe used.
Technical Discussion » $N variable in file cache node not working? - H16
- jlait
- 6220 posts
- Offline
$N is a local variable of the Geometry ROP. Local variables never work through channel references, and File Cache is an HDA that contains a Geometry ROP. Thus $N does not work in the File Cache.
Technical Discussion » Orient objects tangential to another surface
- jlait
- 6220 posts
- Offline
After the scatter you don't have normals on those points.
Using the attribute expression will try to create normals for the points. But geometry in Houdini has no history. The points don't know they came from a sphere, so think they are just free floating points and get 0 normals. So “self” is 0, and you are just setting all the normals to a constant value. Thus the global behaviour.
For non-primitive sphere geometry, you could add normals before the scatter. The scatter should then properly copy over these normals onto the points and copystamp would work.
For a primitive sphere it is a bit trickier as it only has a single point. So you have to build the normals after the scatter. For a zero-centered sphere, however, it is rather easy as the normal is the position. So in your Attribute Expression just put @P
You may want the grid to be an XY grid, however, as the Z axis is oriented to the normal. Then add an up attribute to change how the grid is rotated around the normal.
Using the attribute expression will try to create normals for the points. But geometry in Houdini has no history. The points don't know they came from a sphere, so think they are just free floating points and get 0 normals. So “self” is 0, and you are just setting all the normals to a constant value. Thus the global behaviour.
For non-primitive sphere geometry, you could add normals before the scatter. The scatter should then properly copy over these normals onto the points and copystamp would work.
For a primitive sphere it is a bit trickier as it only has a single point. So you have to build the normals after the scatter. For a zero-centered sphere, however, it is rather easy as the normal is the position. So in your Attribute Expression just put @P
You may want the grid to be an XY grid, however, as the Z axis is oriented to the normal. Then add an up attribute to change how the grid is rotated around the normal.
Technical Discussion » copystamp
- jlait
- 6220 posts
- Offline
… Why not use two inputs?
Using $CY works, but I do not encourage that workflow. If instead you are in a habit of generating a point cloud & setting up attributes on it for the two-input process, you have a nice point cloud to visualize without having to do the copying. This also makes stuff like isolating the 50th copy easy.
Using $CY works, but I do not encourage that workflow. If instead you are in a habit of generating a point cloud & setting up attributes on it for the two-input process, you have a nice point cloud to visualize without having to do the copying. This also makes stuff like isolating the 50th copy easy.
Technical Discussion » VEXpresssion
- jlait
- 6220 posts
- Offline
gl_wireframe and gl_lit are attributes. The viewer picks up certain named attributes and uses them for shading. Other obvious ones are Cd for colour.
We try to document all these magic systems here:
http://www.sidefx.com/docs/houdini/model/attributes [www.sidefx.com]
I think the 16.0 docs are just missing gl_showallpoints.
We try to document all these magic systems here:
http://www.sidefx.com/docs/houdini/model/attributes [www.sidefx.com]
I think the 16.0 docs are just missing gl_showallpoints.
Technical Discussion » Animated object colliding with Houdini grains issue
- jlait
- 6220 posts
- Offline
jlait
This is where a .hip file is a good help for figuring out how you've got it setup…
Hour glasses may often cause problems if you don't make them hollow. You may need to invert the SDF for the collider.
Technical Discussion » Compile block, Strange behavior. Any guidance.
- jlait
- 6220 posts
- Offline
The Attribute Create node uses Hscript, not VEX, for its initial value. Thus the @sourceprim in that expression is effectively a local variable, so prohibited in a compiled SOP.
There is clearly a bug here, as it should red flag and point that out to you, not just silently fail!
But the work around is to just move the expression into your Group Expression node & simplify stuff in the process, as in the attached.
There is clearly a bug here, as it should red flag and point that out to you, not just silently fail!
But the work around is to just move the expression into your Group Expression node & simplify stuff in the process, as in the attached.
Technical Discussion » Invalid subscript for type float.r Error!
- jlait
- 6220 posts
- Offline
I got too fancy with my rename pattern, apparently you need 3 patterns of
*.r to *.x
etc.
*.r to *.x
etc.
Technical Discussion » Animated object colliding with Houdini grains issue
- jlait
- 6220 posts
- Offline
This is where a .hip file is a good help for figuring out how you've got it setup…
Triangle collision detection requires constant topology, so if you are doing a trace + extrude you probably don't have that.
You thus want to make sure it is using volume collision detection and verify those volumes are high enough res to resolve the shape you have.
If you are using the Deforming Object shelf tool, it assumes constant topology.
In the collision source, turn off Blend Between Frames and Velocity as these will be confused by changing point counts. Display the VDB output and make sure you are resolving the shape over your sequence.
For best results, especially with fluids, you want to generate the correct velocities on the collision geometry. But sand should be able to stumble by without that.
Triangle collision detection requires constant topology, so if you are doing a trace + extrude you probably don't have that.
You thus want to make sure it is using volume collision detection and verify those volumes are high enough res to resolve the shape you have.
If you are using the Deforming Object shelf tool, it assumes constant topology.
In the collision source, turn off Blend Between Frames and Velocity as these will be confused by changing point counts. Display the VDB output and make sure you are resolving the shape over your sequence.
For best results, especially with fluids, you want to generate the correct velocities on the collision geometry. But sand should be able to stumble by without that.
Technical Discussion » Invalid subscript for type float.r Error!
- jlait
- 6220 posts
- Offline
jlait
You may need to rename the volume to C.x, C.y, C.z for the vector binding to work, I can't remember off hand the rules.
You can use the Name sop with
*.[rgb]
*.[xyz]
Edited by jlait - June 9, 2017 14:32:21
Technical Discussion » Invalid subscript for type float.r Error!
- jlait
- 6220 posts
- Offline
C is not a vector. Only some names are automatically considered vectors (P, Cd, etc), the rest are treated as float unless specified otherwise.
or
The type only has to be specified once, the other uses will inherit it.
You may need to rename the volume to C.x, C.y, C.z for the vector binding to work, I can't remember off hand the rules.
v@C.r = 0; @C.g = 1;
or
vector @C; @C.r = 0; @C.g = 1;
The type only has to be specified once, the other uses will inherit it.
You may need to rename the volume to C.x, C.y, C.z for the vector binding to work, I can't remember off hand the rules.
Technical Discussion » set the Operator style to VEX type, and set the Network Type to Geometry Operator not possible
- jlait
- 6220 posts
- Offline
CVEX operators will show up in SHOPs, not in SOPs.
So you need to:
1) Create a CVEX operator.
2) In a normal SOP hda, add a shopnet and put your cvex operator in there.
3) Use an Attribute VOP inside of that SOP hda. This can be pointed to the CVEX operator you put inside of the SHOP network rather than using its own code.
Note that any example you are following would be building something in the “sop” context, however, which is not the same as the CVEX context. CVEX has all the new features (geometry creation, array attribute support, etc), but some old features changed name/parameters, so you can't just copy and paste.
So you need to:
1) Create a CVEX operator.
2) In a normal SOP hda, add a shopnet and put your cvex operator in there.
3) Use an Attribute VOP inside of that SOP hda. This can be pointed to the CVEX operator you put inside of the SHOP network rather than using its own code.
Note that any example you are following would be building something in the “sop” context, however, which is not the same as the CVEX context. CVEX has all the new features (geometry creation, array attribute support, etc), but some old features changed name/parameters, so you can't just copy and paste.
Technical Discussion » Getting Brightest and Darkest Pixels in COP
- jlait
- 6220 posts
- Offline
With Houdini 16 you can import an image into SOPs as a volume slice in addition to as meshes.
Put a COP Network down in SOPs, point it to your COP network, then set it to Volume Slice.
Then you can use Volume Reduce in Max or Min mode to put the resulting max/min into detail attributes.
You'll notice this generates different results than the attribfrommap solution - I suspect it is mis-applying linearlization somewhere. The volume solution seems correct.
You can also do this entirely in COPs.
Dilate/erode will act as a maximum/minimum in a square region depending on sign of the operation. Ideally you could just set this to 3200 for your 3200x3200 image, but because COPs tries to compute the overscan this gets too expensive. So instead do two passes. First dilate/erode by 128. Then scale by 1/64 which will be safe - you won't miss any max/mins because each max/min already got spread everywhere in 128 tiles. Now do another dilate/erode and get a solid patch of colour for use elsewhere in COPs.
Put a COP Network down in SOPs, point it to your COP network, then set it to Volume Slice.
Then you can use Volume Reduce in Max or Min mode to put the resulting max/min into detail attributes.
You'll notice this generates different results than the attribfrommap solution - I suspect it is mis-applying linearlization somewhere. The volume solution seems correct.
You can also do this entirely in COPs.
Dilate/erode will act as a maximum/minimum in a square region depending on sign of the operation. Ideally you could just set this to 3200 for your 3200x3200 image, but because COPs tries to compute the overscan this gets too expensive. So instead do two passes. First dilate/erode by 128. Then scale by 1/64 which will be safe - you won't miss any max/mins because each max/min already got spread everywhere in 128 tiles. Now do another dilate/erode and get a solid patch of colour for use elsewhere in COPs.
Technical Discussion » Hibernate mode for Sops?
- jlait
- 6220 posts
- Offline
No. It would be a rather tricky endeavour. It is not enough to save all the geometry of all the SOPs, it is also important to save out the dependencies so they will re-awaken properly when you start changing parameters again.
This will also tend to generate gigabyte sized .hip files as often the .hip file is very small but references huge data sets.
You can manually freeze node chains using the Lock flag or the Stash SOP. But your IT department may be by asking why your backup directory is so huge :>
I'd really like this to be solved on the OS level. No reason why my OS can't snapshot a particular process and re-activate it later. It is always fun working with emulators where this is trivial.
This will also tend to generate gigabyte sized .hip files as often the .hip file is very small but references huge data sets.
You can manually freeze node chains using the Lock flag or the Stash SOP. But your IT department may be by asking why your backup directory is so huge :>
I'd really like this to be solved on the OS level. No reason why my OS can't snapshot a particular process and re-activate it later. It is always fun working with emulators where this is trivial.
Technical Discussion » #Include doesn't insert block of code
- jlait
- 6220 posts
- Offline
That documentation would be for normal VEX code.
In Wrangles the VEX code is transformed in several ways before going to the compiler. This includes pulling out all the @ variables and renaming them, for example.
One important thing to note about wrangles is that everything you write is *inside* a function. So when you write
The snippet will generate
and invoke the somelongname function from the relevant place of the CVEX shader. Thus, while your code looks like it is in the outermost scope of a .vfl file, it isn't. It is actually inside of a function. So if we tried to take a standard header like math.h and drop it in there, weird and horrible stuff would happen.
Thus, one pre-processing step is to take all the #include lines in your wrangle and move them outside of that somelongname function. This works well when you define functions. It doesn't work well when you try to insert code blocks.
Being able to nicely insert code blocks into wrangles is sadly something we don't have a good solution for. Some people go with
but this has its own list of problems.
In Wrangles the VEX code is transformed in several ways before going to the compiler. This includes pulling out all the @ variables and renaming them, for example.
One important thing to note about wrangles is that everything you write is *inside* a function. So when you write
@P *= 0.5;
The snippet will generate
void somelongname(vector bound_P) { bound_P *= 0.5; }
and invoke the somelongname function from the relevant place of the CVEX shader. Thus, while your code looks like it is in the outermost scope of a .vfl file, it isn't. It is actually inside of a function. So if we tried to take a standard header like math.h and drop it in there, weird and horrible stuff would happen.
Thus, one pre-processing step is to take all the #include lines in your wrangle and move them outside of that somelongname function. This works well when you define functions. It doesn't work well when you try to insert code blocks.
Being able to nicely insert code blocks into wrangles is sadly something we don't have a good solution for. Some people go with
`chs("pathtostringparameter")`
but this has its own list of problems.
Technical Discussion » Increment of New For Loop VOP
- jlait
- 6220 posts
- Offline
How is is that not a real while loop?
is equivalent to
The only difference is typing, which isn't an issue when the code is auto-generated.
It is hard to express a true while loop in VOPs because your continue condition depends on fed-back wires, while the initial condition can't depend on fed-back wires.
Attached shows that previous example as a while loop.
if (foo) { do { } while (foo) }
is equivalent to
while (foo) { }
The only difference is typing, which isn't an issue when the code is auto-generated.
It is hard to express a true while loop in VOPs because your continue condition depends on fed-back wires, while the initial condition can't depend on fed-back wires.
Attached shows that previous example as a while loop.
Technical Discussion » Increment of New For Loop VOP
- jlait
- 6220 posts
- Offline
-
- Quick Links