Rewrote the Pressure constraint in the Vellum Solver to make it deterministic on GPUs at high constraint counts, as well as to avoid hanging that was occurring with the latest Ada architecture GPUs from NVIDIA (e.g. 4090).
Found 183 posts.
Search results Show results as topic list.
Houdini Lounge » Nvidia rtx 4090 driver issues?
- johner
- 807 posts
- Offline
The Houdini 19.5 Production Build of 19.5.534 includes the following change which should resolve the issue with Vellum pressure constraints and the 4090. This fix has also been backported to the daily 19.0 build.
Houdini Lounge » Vellum Solver OpenCL errors
- johner
- 807 posts
- Offline
Yes, it's an issue with the latest NVIDIA driver, which changed some things about the OpenCL compiler. This forum post is from people who ran into it:
https://www.sidefx.com/forum/topic/86887/ [www.sidefx.com]
We've fixed it for the daily builds, but there are ways to workaround if you're stuck on a production build.
https://www.sidefx.com/forum/topic/86887/ [www.sidefx.com]
We've fixed it for the daily builds, but there are ways to workaround if you're stuck on a production build.
Houdini Lounge » Vellum Solver OpenCL errors
- johner
- 807 posts
- Offline
As a temporary workaround, you can try the following:
The other (easier) option is to turn Smoothing Iterations down to zero, but that will likely affect the quality of the simulation.
With that Kernel flag added, you might run into complaints from the compiler when using Pressure or Shape Match constraints, but you can likely silence those by turning off the faster OpenCL 2.0 path for them as described in the Note here:
https://www.sidefx.com/docs/houdini/news/18_5/vellum.html [www.sidefx.com]
- Right-click on the Vellum Solver SOP and choose "Allow Editing of Contents".
- Dive into the solver and look for the green "dopnet1" node.
- Dive into that node and look for the "vellumsolver1" DOP.
- On the Advanced tab of that node, look at the bottom for the "OpenCL" section.
- Under the Kernel Options parameter add the following text:
-cl-std=CL1.2
The other (easier) option is to turn Smoothing Iterations down to zero, but that will likely affect the quality of the simulation.
With that Kernel flag added, you might run into complaints from the compiler when using Pressure or Shape Match constraints, but you can likely silence those by turning off the faster OpenCL 2.0 path for them as described in the Note here:
https://www.sidefx.com/docs/houdini/news/18_5/vellum.html [www.sidefx.com]
Houdini Lounge » Nvidia rtx 4090 driver issues?
- johner
- 807 posts
- Offline
Hmm, this appears to be a different crash somewhere deep within the new NVIDIA OpenCL compiler. I can reproduce it and will investigate.
Edit: Turns out this was indeed a bug in the new NVIDIA OpenCL compiler, but we were able to find a workaround. Tomorrow's builds of 19.5.408, 19.0.775, and 18.5.1098 should no longer crash. Hopefully this is the last issue with the new driver and compiler!
Edit: Turns out this was indeed a bug in the new NVIDIA OpenCL compiler, but we were able to find a workaround. Tomorrow's builds of 19.5.408, 19.0.775, and 18.5.1098 should no longer crash. Hopefully this is the last issue with the new driver and compiler!
Edited by johner - Oct. 18, 2022 15:47:49
Houdini Lounge » Nvidia rtx 4090 driver issues?
- johner
- 807 posts
- Offline
The 522.25 driver switched to a newer OpenCL compiler, which changed some flags in how it compiles OpenCL kernels (correctly by the way; we should have been handling these flags better). Tomorrow's builds of 19.5.407, 19.0.774, and 18.5.1097 should all work with the new driver without compile errors.
Technical Discussion » weird OpenCl error in vellum
- johner
- 807 posts
- Offline
This is an issue that arose from recent NVIDIA drivers updating to OpenCL 3.0. It should be fixed in Houdini version 18.5.553:
Houdini 18.5.553: Mon Apr 19 19:00:18 CDT 2021
Update the Vellum Solver to work properly with NVIDIA's recently
released OpenCL 3.0 drivers, particularly the Pressure and Shape Match
constraints.
Technical Discussion » Is vellum scale dependent?
- johner
- 807 posts
- Offline
There are options to set the Unit Length and Unit Mass in Preferences | Hip File Options. If you set these *before* creating any Vellum SOPs or DOPs, then physical parameters like gravity should be scaled appropriately.
Technical Discussion » Unstable Vellum Weld constraints
- johner
- 807 posts
- Offline
What's happening is the welds are breaking, which re-enables collision between the points, but they're still close enough to each other to self-collide. This gives a fairly explosive tear as the points immediately collide in the next timestep. There are a few different ways to handle this, but an effective one for this case is to disable self-collisions on any unwelded points just for the timestep when they break.
You can do this in a GeometryWrangle into the third input of the Vellum Solver, with the group set to “broken”, and code of
See attached.
(Note this only works for DOPs-based Vellum setups, since the third input is not exposed in the Vellum Solver SOP, and the “broken” group is only set for that third input.)
You can do this in a GeometryWrangle into the third input of the Vellum Solver, with the group set to “broken”, and code of
i@disableself = 2;
. Setting that flag to 2 will disable self collisions for a point until it is no longer self-colliding, at which time it gets reset to zero. (You can set it to 1 to permanently disable self-collisions.) This gives a much smoother tear in this case, as does setting Breaking Frequency to Per Substep on the Advanced tab of the Vellum Solver.See attached.
(Note this only works for DOPs-based Vellum setups, since the third input is not exposed in the Vellum Solver SOP, and the “broken” group is only set for that third input.)
Edited by johner - Feb. 11, 2019 16:34:33
Technical Discussion » no openCL device available
- johner
- 807 posts
- Offline
Technical Discussion » no openCL device available
- johner
- 807 posts
- Offline
By the way, as a temporary workaround, you can go to the bin directory of your Houdini installation (usually something like C:\Program Files\Side Effects Software\Houdini 17.0.356\bin) and temporarily move or rename the OpenCL.dll file there. That will cause Houdini to use the system-wide OpenCL loader installed by NVIDIA, which should find your GPU driver. You'll lose the built-in CPU driver, however, but you might not care about that.
Technical Discussion » no openCL device available
- johner
- 807 posts
- Offline
Thank you for reporting this issue. It turns out that Microsoft changed their specifications for where graphics drivers can write to the registry, which in turn means changes were required for the OpenCL ICD loader (the small bit of code that loads the various OpenCL drivers from different vendors). We ship a custom version of that ICD loader under Linux and Windows so that the built-in CPU OpenCL driver is always available, but have not yet updated it to obey Microsoft's new conventions. We're working on a fix that should be out soon.
Technical Discussion » H17 Vellum and hairgen
- johner
- 807 posts
- Offline
You really don't want to regenerate the hair each timestep, which is what you're doing if you send the deforming geometry through HairGen. It's expensive performance-wise, and more importantly, the points generated are jumping around as the scatter is not completely stable over time.
The best way to use Vellum hair with deforming geometry is to generate all the constraints on a static groom, then use GuideDeform to update the P and orient attributes right before the hairs go into the solver. This is quite fast, and guarantees stable point count and orientations calculated from the deforming geometry. The attached file shows a stable sim using this technique.
I've also reduced hair thickness a good bit in this file, since otherwise you can sometimes get the initial edges jittering a bit as they collide with the deforming geo. I also created a group for just the skin so there's no hair on the eyes which was pointing inwards. Also you might want to change the Orientation Pin Type to Soft rather than Same as Position if you want the initial edges to be able to bend as well.
The best way to use Vellum hair with deforming geometry is to generate all the constraints on a static groom, then use GuideDeform to update the P and orient attributes right before the hairs go into the solver. This is quite fast, and guarantees stable point count and orientations calculated from the deforming geometry. The attached file shows a stable sim using this technique.
I've also reduced hair thickness a good bit in this file, since otherwise you can sometimes get the initial edges jittering a bit as they collide with the deforming geo. I also created a group for just the skin so there's no hair on the eyes which was pointing inwards. Also you might want to change the Orientation Pin Type to Soft rather than Same as Position if you want the initial edges to be able to bend as well.
Technical Discussion » Ocean Waves doesn't render properly
- johner
- 807 posts
- Offline
That looks like an issue with insufficient displacement bounds. The link from the SHOP's Displacement Bound parameter to the spectrum's amplitude will typically work for a single spectrum ocean, but once you start adding in multiple layers and especially large instanced “hero” waves, it's probably wrong, and unfortunately it's difficult to have a simple expression that estimates the largest displacement once multiple layers, instancing, and masks are involved.
I would delete the displacement bound expression and test increasingly large numbers until you get rid of the artifacts.
I would delete the displacement bound expression and test increasingly large numbers until you get rid of the artifacts.
Technical Discussion » Ocean Spectrum Custom Combed directions
- johner
- 807 posts
- Offline
The only built-in support for control over local wave direction relies on “Wave Instancing”, which copies patches of ocean onto oriented points. So you can orient those points whichever direction you want, and waves from the instanced ocean patches will point in that direction (as much as they do given their spectrum settings). I went through that a bit in the Oceans Masterclass; in the attached example file from the class, it would be the “instance along curve” and “instance along radial points” examples (inputs 6 or 7 to the switch1 SOP, respectively).
Is that sufficient or did you have something else in mind?
Is that sufficient or did you have something else in mind?
Technical Discussion » Houdini 16 Extended Ocean - Displacement Baking
- johner
- 807 posts
- Offline
Yes, using the Bake All Displacements to One Layer option on the Export to Texture tab of OceanEvaluate. Note this is not in the gold release, so you'd need to install a daily build to get it. I go through that feature in some detail starting at 1:18:40 in the Ocean masterclass:
https://vimeo.com/204806144 [vimeo.com]
https://vimeo.com/204806144 [vimeo.com]
Houdini Learning Materials » Guided Ocean Layer Help?
- johner
- 807 posts
- Offline
Thank you for the report and the file. This is indeed a bug. The problem is the expression that the Guided Ocean Layer shelf tool puts in the Grid Scale parameter of the OceanSource SOP. Since we're usually using the Max Resolution parameter to limit the amount of high-frequency waves we're sending into the OceanSource, it doesn't make sense to generate a really high resolution volume to represent just those low-frequency waves. However, the output guiding surface SDF does have to be high enough resolution to maintain the Guiding Layer Thickness, which gets smaller as the Particle Separation decreases, and that was not being taken into account in the Grid Scale expression.
Short-term workaround, clear out that expression and set the Grid Scale to 6 (or even 8 in your example, I believe). You can put a Convert Volume SOP on the output of the OUT_GUIDING_SURFACE SOP to ensure there are no holes in the surface with the smaller grid scale.
We'll be updating the Guiding Layer shelf tool to correct this. Thank you again for the report.
Short-term workaround, clear out that expression and set the Grid Scale to 6 (or even 8 in your example, I believe). You can put a Convert Volume SOP on the output of the OUT_GUIDING_SURFACE SOP to ensure there are no holes in the surface with the smaller grid scale.
We'll be updating the Guiding Layer shelf tool to correct this. Thank you again for the report.
Technical Discussion » Point instanced ocean spectra not deforming flat tank
- johner
- 807 posts
- Offline
Ah, I suspect the problem is your point instances aren't on the zero Y plane? What's happening in that case is from the perspective of the OceanEvaluate, your particles and grid are below the ocean surface. However, only the OceanSource has the Depth Falloff set to Exponential by Frequency, so only the particles are showing the effect of being underwater, while the ocean_preview SOP is set to None, so it deforms the preview grid as if it were at the surface.
The bug here is that the ocean_preview should likely be tied to match the Depth Falloff of the OceanSource, although that is a more expensive evaluation. In the meantime you can either change the ocean_preview to Exponential by Frequency for Depth Falloff, or make sure your point instances are on the zero-y plane; either way they should then match, I believe.
The bug here is that the ocean_preview should likely be tied to match the Depth Falloff of the OceanSource, although that is a more expensive evaluation. In the meantime you can either change the ocean_preview to Exponential by Frequency for Depth Falloff, or make sure your point instances are on the zero-y plane; either way they should then match, I believe.
Edited by johner - March 11, 2017 13:30:33
Technical Discussion » Point instanced ocean spectra not deforming flat tank
- johner
- 807 posts
- Offline
Hmm, I'm not seeing the same problem, even with versions older than 16.0.543. Do you mind attaching the file you have above here (or even better, submitting a bug?)
Technical Discussion » Point instanced ocean spectra not deforming flat tank
- johner
- 807 posts
- Offline
Tomorrow's daily build (16.0.543) will have some updates to improve OceanEvaluate/OceanSource's handling of point-instanced oceans. Would you mind trying it your file in that version and submitting a bug if you still see problems?
Thanks
Thanks
Houdini Learning Materials » Guided Ocean Layer Help?
- johner
- 807 posts
- Offline
Would one of you mind submitting a bug along with your .hip files? It looks like the particles layer is not thick enough, and you're seeing the FLIP sim “fall through” the guided layer, but we'd need to see the .hip file to be sure.
Thanks
Thanks
-
- Quick Links