No worries! Try this.
See how you go, if this doesn't work then perhaps delete the whole ‘new’ set of hair nodes and make fresh ones - sometimes this fixes unexplained problems (or copy them from your groom-exporter file where I assume they do work).
Found 10 posts.
Search results Show results as topic list.
Houdini Indie and Apprentice » External geometry for hair groom
- jardenruss
- 10 posts
- Offline
Houdini Indie and Apprentice » External geometry for hair groom
- jardenruss
- 10 posts
- Offline
Your method doesn't work for me either. Instead of ‘groom object’ I used ‘groom file’ and it works fine when I link the geo up directly.
Houdini Indie and Apprentice » External geometry for hair groom
- jardenruss
- 10 posts
- Offline
Whereabouts is the ‘external groom source’ you mention? There are a few options for file caching guides on the top level of the groom nodes - that could be an option for you (it's bgeo.sc by the way) if you save from the source file and load that in on the new file.
Might be helpful to know how/where you're inputting the exported geo however.
Might be helpful to know how/where you're inputting the exported geo however.
Houdini Indie and Apprentice » Renderman 23 Bokeh
- jardenruss
- 10 posts
- Offline
Turns out bokeh is working in Houdini in some cases. The DoFAspect parm seems to be broken. Something I didn't test initially made it work: set the depth of field aspect to a value greater than one. This isn't very useful, but proves it's working to some degree.
- This also relies on the camera being set to ‘lens shader’ in the dropdown menu of the view tab
- A pxrcamera node existing in the RISnet
- That pxrcamera node is connected to the lens shader parm in the renderman tab.
- This doesn't refresh during IPR. I've been switching the enable depth of field in the /out/ris1 on and off to see changes.
jsmack is probably right. Likely that it's broken, because when the DoFAspect value is less than one it glitches and makes straight line bokeh and loses all of the other shape settings.
- This also relies on the camera being set to ‘lens shader’ in the dropdown menu of the view tab
- A pxrcamera node existing in the RISnet
- That pxrcamera node is connected to the lens shader parm in the renderman tab.
- This doesn't refresh during IPR. I've been switching the enable depth of field in the /out/ris1 on and off to see changes.
jsmack is probably right. Likely that it's broken, because when the DoFAspect value is less than one it glitches and makes straight line bokeh and loses all of the other shape settings.
Houdini Indie and Apprentice » Renderman 23 Bokeh
- jardenruss
- 10 posts
- Offline
I've been trying for a while now to get the aspect ratio & other bokeh settings to change with Renderman 23.2 and Houdini 18.0.391. Nothing I've done seems to get the bokeh to be anything but a default circular shape.
I thought it could be something to do with needing to use a lens shader & link to pxrcamera inside the ‘risnet’ node. It doesn't make a difference though, and nor is it implied by the RfH docs on the bokeh: https://rmanwiki.pixar.com/display/RFH23/Bokeh [rmanwiki.pixar.com]
Plus - it works fine in Maya out of the box. Not sure what to glean from this apart from it's probably something like a hidden checkbox within Houdini… Images attached.
Would be very greatful if a solution to this is out there.
I thought it could be something to do with needing to use a lens shader & link to pxrcamera inside the ‘risnet’ node. It doesn't make a difference though, and nor is it implied by the RfH docs on the bokeh: https://rmanwiki.pixar.com/display/RFH23/Bokeh [rmanwiki.pixar.com]
Plus - it works fine in Maya out of the box. Not sure what to glean from this apart from it's probably something like a hidden checkbox within Houdini… Images attached.
Would be very greatful if a solution to this is out there.
Edited by jardenruss - 2020年5月29日 11:05:29
Technical Discussion » Masking gas dissipate with Sop Scalar Field
- jardenruss
- 10 posts
- Offline
6-months-later follow up on this, maybe it'll help someone down the line. It's really pretty straightforward.
The pyro look development page suggests to attach it to the density binding on the node, which works for turbulence but it more generically works when the custom-made scalar field is entered into the ‘control field’ of the dissipate/turbulence/disturb nodes and so on. If you dial up the control influence to 1, it should just work if the values in your scalar field are correct.
The pyro look development page suggests to attach it to the density binding on the node, which works for turbulence but it more generically works when the custom-made scalar field is entered into the ‘control field’ of the dissipate/turbulence/disturb nodes and so on. If you dial up the control influence to 1, it should just work if the values in your scalar field are correct.
Technical Discussion » Masking gas dissipate with Sop Scalar Field
- jardenruss
- 10 posts
- Offline
Haven't had much luck trying to create a mask for a gas dissipate node in a pyro solver. The mask I have set up currently works with the gas turbulence node according to the documentation:
https://www.sidefx.com/docs/houdini/pyro/pyro_look.html [www.sidefx.com]
However it isn't immediately clear how to use this to mask a gas dissipate effect. The goal is to ‘feather’ the top of a smoke sim. It's not something I think would happen in real life, which is probably why I'm struggling.
Picture attached - the increased turbulence at the top would idealy be more diffused after using this node. Any ideas? Might need to do multi solver and a seperate sim. Or something else entirely.
https://www.sidefx.com/docs/houdini/pyro/pyro_look.html [www.sidefx.com]
However it isn't immediately clear how to use this to mask a gas dissipate effect. The goal is to ‘feather’ the top of a smoke sim. It's not something I think would happen in real life, which is probably why I'm struggling.
Picture attached - the increased turbulence at the top would idealy be more diffused after using this node. Any ideas? Might need to do multi solver and a seperate sim. Or something else entirely.
Technical Discussion » 17.5 Bug? Cannot use Include in Take in Mantra node
- jardenruss
- 10 posts
- Offline
I'm running 17.5.327 and I was able to set some take info on a mantra node earlier today. Perhaps try a fresh install/update?
Technical Discussion » Voxel stretching in smoke object.
- jardenruss
- 10 posts
- Offline
Technical Discussion » Voxel stretching in smoke object.
- jardenruss
- 10 posts
- Offline
Working on a pyro simulation that is sourced with rasterized particles, which is working fine apart from some strange behaviour when making the simulation wider on one axis. It's a dust cloud approaching the camera.
When the smoke object container is 10*10*10 units w/0.1 div size - the smaller size I was to get it set up - the simulation runs correctly and the fluid moves in the right way and appears smooth.
Now that I'm ready to make the cloud the full width of the screen, when I create a wider source of particles & also change the initial size of the smoke object, it appears that the voxels are stretching on the width (z axis) without adding more. Despite being on 0.1 div size.
The object is showing a resolution of 100*100*900 voxels, but it has the appearance of 100*100*100 voxels scaled 9x out on the z axis. Pictures - both containers have the same 0.1 division size, onl thing changing between the two is smoke object resolution:
Can't figure it out. Might be a bug, might be a fool.
Any ideas?
When the smoke object container is 10*10*10 units w/0.1 div size - the smaller size I was to get it set up - the simulation runs correctly and the fluid moves in the right way and appears smooth.
Now that I'm ready to make the cloud the full width of the screen, when I create a wider source of particles & also change the initial size of the smoke object, it appears that the voxels are stretching on the width (z axis) without adding more. Despite being on 0.1 div size.
The object is showing a resolution of 100*100*900 voxels, but it has the appearance of 100*100*100 voxels scaled 9x out on the z axis. Pictures - both containers have the same 0.1 division size, onl thing changing between the two is smoke object resolution:
Can't figure it out. Might be a bug, might be a fool.
Any ideas?
-
- Quick Links