Thank you!! Yes both methods worked!
P.S. All the documentation I found said that there needed to be a velocities attributes. So seeing that I had no motionblur, out of desperation I tried that.
Found 11 posts.
Search results Show results as topic list.
Solaris and Karma » Cannot get velocities blur to work in Karma, Houdini 20.0.59
- memo
- 11 posts
- Offline
Solaris and Karma » Cannot get velocities blur to work in Karma, Houdini 20.0.59
- memo
- 11 posts
- Offline
I'm trying to get velocities blur (and motion vectors AOV) to work in Karma, Houdini 20.0.59, and just cannot.
Attached is a test case hipfile and screenshot.
I tried:
1. Particle system with @v attrib copied to @velocities. Velocity Blur enabled. Cache node after my render settings. No motion blur at all.
2. Animated mountain and transform SOP on sphere. Random huge @velocities attribute (also copied to @v to visualize, see screenshot below). Velocity Blur enabled. I'm getting motion blur, but it's the correct (i.e. deformation) blur, and ignoring my velocities attributes.
Even though I can see the velocities attribute in my scene graph! (and they are the random huge ones).
Why are the velocities being ignored?
P.S. I also want motion vectors AOV, but it keeps appearing black. See attached hip.
Attached is a test case hipfile and screenshot.
I tried:
1. Particle system with @v attrib copied to @velocities. Velocity Blur enabled. Cache node after my render settings. No motion blur at all.
2. Animated mountain and transform SOP on sphere. Random huge @velocities attribute (also copied to @v to visualize, see screenshot below). Velocity Blur enabled. I'm getting motion blur, but it's the correct (i.e. deformation) blur, and ignoring my velocities attributes.
Even though I can see the velocities attribute in my scene graph! (and they are the random huge ones).
Why are the velocities being ignored?
P.S. I also want motion vectors AOV, but it keeps appearing black. See attached hip.
Edited by memo - Jan. 21, 2024 17:36:56
Technical Discussion » Workflow wrt hip, render and cache folders and filenames
- memo
- 11 posts
- Offline
I ended up writing a little HDA to manage this. It browses and lists all subfolders of a specified cache root folder, and constructs a path to be used by other nodes (such as FileCache, Render etc).
Details at https://github.com/memo/msa_pathversioner [github.com]
Details at https://github.com/memo/msa_pathversioner [github.com]
def listdir(path): '''list only directories in a path''' return [_ for _ in os.listdir(path) if os.path.isdir(os.path.join(path, _))] def get_hipname(): '''return current HIP name''' return hou.expandString('$HIPNAME') def menu_from_list(l): ''' return a list suitable for displaying as a dropdown menu i.e. each item is listed twice ''' return [x for x in l for _ in (0, 1)] def get_path(node): '''construct the path to search''' root_folder = node.parm('root_folder').eval() name = node.parm('name').eval() path = os.path.join(root_folder, name) return path def menu_from_dirlist(node): ''' given a root directory path, return folder contents suitable for displaying as a dropdown menu, ''' path = get_path(node) try: l = menu_from_list(listdir(path)) except: l = [] pass hipname = get_hipname() if hipname in l: # if current hipname is in the list, add info that it's current # add to next index, because first occurence is value, second occurence is label l[l.index(hipname) + 1] += ' (Current HIP file)' else: # if not found, add it to the top as current l = ['$HIPNAME', f'{hipname} (Current HIP file, no folder available)'] + l update(node) # update UI return l def update_env(): hou.putenv('HIPBASENAME', get_hipname().split('.')[0]) def update(node): '''update UI''' update_env() path = get_path(node) msg = path + '\n' if not os.path.exists(path) or not os.path.isdir(path): msg += 'Directory not found\n' else: l = [] try: l = listdir(path) except: pass msg += f'{len(l)} entries found:\n' msg += '\n'.join(l) msg += '\n' msg += '------\n' msg += f'Current HIP: {get_hipname()}\n' node.parm('info').set(msg)
Edited by memo - Sept. 5, 2023 11:46:40
Technical Discussion » Workflow wrt hip, render and cache folders and filenames
- memo
- 11 posts
- Offline
I have a question regarding tips for folders and filenames for hip, render and cache.
Let's say I'm working on a project called `MyProject`. I like to increment hip versions so I have `MyProject.001.hip`, `MyProject.002.hip`, `MyProject.003.hip` etc.
I might have multiple simulations in a hip, and for each one I might try different settings and versions, and then cache and render them.
What I'd like to be able to do is: when I view any render, I'd like to be able to go back to see those exact settings.
So I include `$HIPNAME` and `$ACTIVETAKE` and `cache version(s)` in my cache and render paths.
The problem is, if I include the full versioned `$HIPNAME` in the cache path, when I increment the version of the HIP, the cache cannot be found anymore (because the cache might be called `cache/MyProject.017/fluid/v4/*` while the new HIP v18 will be looking
for `cache/MyProject.018/fluid/v4/*`).
If I exclude the HIP version from the cache path, then I can increment HIP version, but then I don't have a way of recalling those exact settings which led to that cache or render.
I tried using the Houdini Take system, and the Preset system, but both get very messy very quickly. Especially when I'm working with custom OTLs which I'm continuously updating, and adding new features and parameters to.
The only solution I've found so far, which actually achieves what I want - but is ridiculously cumbersome - is to:
1. Use the cache versioning system, and NOT include the full hipname in the path, but just use the base hipname without version. e.g. `cache/MyProject/fluid/v4`, `cache/MyProject/particles/v8` as opposed to `cache/MyProject.018/fluid/v4`, `cache/MyProject.018/particles/v8` etc.
2. As soon as I cache a simulation, increment the `$HIPNAME` version number
3. Log in separate spreadsheet to keep track of which version of which simulation is in which $HIPNAME with version. E.g. `fluid.v4: MyProject.011.hip`, `particles.v8: MyProject.018.hip` etc.
This feels like a problem many others might have encountered, and solved more elegantly. I'm open to suggestions!
Let's say I'm working on a project called `MyProject`. I like to increment hip versions so I have `MyProject.001.hip`, `MyProject.002.hip`, `MyProject.003.hip` etc.
I might have multiple simulations in a hip, and for each one I might try different settings and versions, and then cache and render them.
What I'd like to be able to do is: when I view any render, I'd like to be able to go back to see those exact settings.
So I include `$HIPNAME` and `$ACTIVETAKE` and `cache version(s)` in my cache and render paths.
The problem is, if I include the full versioned `$HIPNAME` in the cache path, when I increment the version of the HIP, the cache cannot be found anymore (because the cache might be called `cache/MyProject.017/fluid/v4/*` while the new HIP v18 will be looking
for `cache/MyProject.018/fluid/v4/*`).
If I exclude the HIP version from the cache path, then I can increment HIP version, but then I don't have a way of recalling those exact settings which led to that cache or render.
I tried using the Houdini Take system, and the Preset system, but both get very messy very quickly. Especially when I'm working with custom OTLs which I'm continuously updating, and adding new features and parameters to.
The only solution I've found so far, which actually achieves what I want - but is ridiculously cumbersome - is to:
1. Use the cache versioning system, and NOT include the full hipname in the path, but just use the base hipname without version. e.g. `cache/MyProject/fluid/v4`, `cache/MyProject/particles/v8` as opposed to `cache/MyProject.018/fluid/v4`, `cache/MyProject.018/particles/v8` etc.
2. As soon as I cache a simulation, increment the `$HIPNAME` version number
3. Log in separate spreadsheet to keep track of which version of which simulation is in which $HIPNAME with version. E.g. `fluid.v4: MyProject.011.hip`, `particles.v8: MyProject.018.hip` etc.
This feels like a problem many others might have encountered, and solved more elegantly. I'm open to suggestions!
Technical Discussion » OpenColorIO ACES workflow for final comp output
- memo
- 11 posts
- Offline
Problem solved, I needed to add an 8-bit conversion node before the ROP, doh. And then I can use Gamma=1 in the ROP. The 8bit tif is then (perceptually) identical to the ACES corrected view in Houdini.
Edited by memo - June 10, 2021 07:34:12
Technical Discussion » OpenColorIO ACES workflow for final comp output
- memo
- 11 posts
- Offline
I've read and watched many helpful tutorials on using OpenColorIO ACES within Houdini, and I think I have it down, except for the final final (comp) output.
I'm rendering my 3D scene as 16bit EXRs, then I'd like comp, postfx & grade in Houdini, and finally render that out to 8bit tifs so I can convert to mp4 with ffmpeg. This final step is what the problematic step.
Before my ROP I have a VOPCOP which converts my image from "ACEScg" to "Output - sRGB". And when I compare the image on my screen between "VOPCOP on and viewer OpenColorIO Transform disabled" to "VOPCOP off and viewer OpenColorIO Transform set to SRGB", the results are identical. So it seems that the workflow up to this point is good.
When I export this to tif however, an additional (gamma?) transform is applied in the ROP. I have tried a number of things but can't get the perfect results.
This is my reference. My VOPCOP transform (ACESCg to Output - SRGB) is disabled, Viewer transform is enabled.
Checking my VOPCOP transform: VOPCOP transform enabled, Viewer transform is disabled. This is identical to the previous image. So the VOPCOP transform is working correctly.
All of the following tests have the VOPCOP transform enabled.
ROP writing to TIF with "Convert to Image Format's Colorspace" enabled. Definitely very wrong.
ROP writing to TIF with "Convert to Image Format's Colorspace" disabled, and gamma=1. I would have hoped this to work. As I want to write the raw values at this stage after the VOPCOP transform. But it's much brighter. So something is still going on.
ROP writing to TIF with "Convert to Image Format's Colorspace" disabled, and gamma=1/2.2. This is very close to the reference image. However it is a bit higher contrast, and detail in shadows is lost.
ROP writing to TIF with "Convert to Image Format's Colorspace" disabled, and gamma=1/2.4. This is also very close to the reference image, but slightly darker. And more off than gamma=1/2.2
If gamma=1/2.2 would have provided perfect results, I would have assumed that the TIF export is adding an additional gamma correction of 2.2, so I would need to counter that by setting gamma=1/2.2 in the ROP node. But even that is not producing perfect results. And I feel like there should be some theory going on here and I shouldn't have to trial and error find the perfect gamma to match the output.
I'm rendering my 3D scene as 16bit EXRs, then I'd like comp, postfx & grade in Houdini, and finally render that out to 8bit tifs so I can convert to mp4 with ffmpeg. This final step is what the problematic step.
Before my ROP I have a VOPCOP which converts my image from "ACEScg" to "Output - sRGB". And when I compare the image on my screen between "VOPCOP on and viewer OpenColorIO Transform disabled" to "VOPCOP off and viewer OpenColorIO Transform set to SRGB", the results are identical. So it seems that the workflow up to this point is good.
When I export this to tif however, an additional (gamma?) transform is applied in the ROP. I have tried a number of things but can't get the perfect results.
This is my reference. My VOPCOP transform (ACESCg to Output - SRGB) is disabled, Viewer transform is enabled.
Checking my VOPCOP transform: VOPCOP transform enabled, Viewer transform is disabled. This is identical to the previous image. So the VOPCOP transform is working correctly.
All of the following tests have the VOPCOP transform enabled.
ROP writing to TIF with "Convert to Image Format's Colorspace" enabled. Definitely very wrong.
ROP writing to TIF with "Convert to Image Format's Colorspace" disabled, and gamma=1. I would have hoped this to work. As I want to write the raw values at this stage after the VOPCOP transform. But it's much brighter. So something is still going on.
ROP writing to TIF with "Convert to Image Format's Colorspace" disabled, and gamma=1/2.2. This is very close to the reference image. However it is a bit higher contrast, and detail in shadows is lost.
ROP writing to TIF with "Convert to Image Format's Colorspace" disabled, and gamma=1/2.4. This is also very close to the reference image, but slightly darker. And more off than gamma=1/2.2
If gamma=1/2.2 would have provided perfect results, I would have assumed that the TIF export is adding an additional gamma correction of 2.2, so I would need to counter that by setting gamma=1/2.2 in the ROP node. But even that is not producing perfect results. And I feel like there should be some theory going on here and I shouldn't have to trial and error find the perfect gamma to match the output.
Edited by memo - June 10, 2021 06:19:31
Technical Discussion » hbatch: Can't open dophints.cmd. No module named viewerstate
- memo
- 11 posts
- Offline
If anybody comes across this post with the same error, I've discovered it's because I had separately defined a environment variable pointing to (for my own convenience). So even though I was running AFTER defining , it was still breaking something. (And the reason why it worked as root, is not because of permission issues, but because HOUDINI_PATH was not defined for root).
HOUDINI_PATH
/opt/hfs18.5
source houdini_setup
HOUDINI_PATH=/opt/hfs18.5
Technical Discussion » hbatch: Can't open dophints.cmd. No module named viewerstate
- memo
- 11 posts
- Offline
I'm still struggling with this. Freshly installed Houdini many times and same problem.
I've discovered that I can run the script via root. i.e.
this doesn't work:
does work:
OR
Is this normal behaviour? Can I not run houdini without root privileges? If I source houdini_setup in my .profile, then none of that env gets carried on over to my sudo, so I'd need to source it as root.
I've discovered that I can run the script via root. i.e.
this doesn't work:
cd /opt/hfs18.5 source houdini_setup => The Houdini 18.5.532 environment has been initialized. hscript => gives all of the errors above
does work:
sudo /opt/hfs18.5/bin/hscript
OR
sudo su cd /opt/hfs18.5 source houdini_setup => The Houdini 18.5.532 environment has been initialized. hscript => works
Is this normal behaviour? Can I not run houdini without root privileges? If I source houdini_setup in my .profile, then none of that env gets carried on over to my sudo, so I'd need to source it as root.
Edited by memo - June 5, 2021 11:29:03
Technical Discussion » hbatch: Can't open dophints.cmd. No module named viewerstate
- memo
- 11 posts
- Offline
UPDATE: I tried redeeming my second Indie (with GUI) license (even though docs say that Indie Engine is sufficient for commandline renders https://www.sidefx.com/faq/question/indie-renderfarm-setup/ [www.sidefx.com] )
And then I managed to VNC in and run Houdini Gui. I still get the same errors, this time with loads of other errors beforehand. See end of the post.
---
I'm trying to setup a remote render node via command line, and I'm getting some errors.
I don't have physical access to the remote PC. It does have graphics card and a monitor, but I can't screen share (it's problematic, I'm not sure why, my internet is too slow perhaps), though I can ssh into it.
(Remote PC is Ubuntu 18.04.5 LTS, 5.4.0-73-generic, Geforce 2080 Ti, NVidia 465.19.01, CUDA 11.3)
I've installed
- 1 "Houdini Engine Indie 18.5"
- 1 "Renderer (Indie/Apprentice) 18.5"
- 1 "Karma Renderer (Indie/Apprentice) 18.5"
I
Then when I run
Interestingly, if I run hython, I get all of the same errors, but at the end there is:
Should this be using my system python or
I also tried rendering a very simple test hip, and again I get all of the same errors, and at the end there is:
What can I do?
More details in the attachments (including my environment).
----
UPDATE: I tried redeeming my second Indie (with GUI) license (even though docs say that Indie Engine is sufficient for commandline renders https://www.sidefx.com/faq/question/indie-renderfarm-setup/ [www.sidefx.com] )
And then I managed to VNC in and run Houdini Gui. I get the same errors, this time with loads of other errors beforehand.
And then I managed to VNC in and run Houdini Gui. I still get the same errors, this time with loads of other errors beforehand. See end of the post.
---
I'm trying to setup a remote render node via command line, and I'm getting some errors.
I don't have physical access to the remote PC. It does have graphics card and a monitor, but I can't screen share (it's problematic, I'm not sure why, my internet is too slow perhaps), though I can ssh into it.
(Remote PC is Ubuntu 18.04.5 LTS, 5.4.0-73-generic, Geforce 2080 Ti, NVidia 465.19.01, CUDA 11.3)
I've installed
houdini-py3-18.5.532-linux_x86_64_gcc6.3.tar.gz
remotely via command line, and successfully redeemed licenses for - 1 "Houdini Engine Indie 18.5"
- 1 "Renderer (Indie/Apprentice) 18.5"
- 1 "Karma Renderer (Indie/Apprentice) 18.5"
I
source houdini_setup
from /opt/hfs18.5
(it's at the end of my .bashrc
)Then when I run
hbatch
or hython
I get lots of errors starting with:Can't open dophints.cmd
Error running event handler:
Traceback (most recent call last):
File "kinefx::Sop/adapttoterrain, opdef:/kinefx::Sop/adapttoterrain?ViewerStateInstall", line 1, in <module>
ModuleNotFoundError: No module named 'viewerstate'
Interestingly, if I run hython, I get all of the same errors, but at the end there is:
/usr/bin/python3: No module named houdiniInterpreter
Should this be using my system python or
/opt/hfs18.5/python/bin
?which -a python3
also returns /usr/bin/python3
Is this normal? And could this be the reason?I also tried rendering a very simple test hip, and again I get all of the same errors, and at the end there is:
hbatch Version 18.5.532 (Compiled on Mar 30 2021)
WARNING: Entered limited commercial session mode.
Error loading: test_remote_render.hiplc
OP: unknown error: 50
OP: unknown error: 50
OP: unknown error: 50
OP: unknown error: 50
OP: unknown error: 47
OP: unknown error: 48
/ -> cd out
/out -> render mantra1
Can't open dophints.cmd
ROP: unknown error: 20
Render failed.
/out ->
What can I do?
More details in the attachments (including my environment).
----
UPDATE: I tried redeeming my second Indie (with GUI) license (even though docs say that Indie Engine is sufficient for commandline renders https://www.sidefx.com/faq/question/indie-renderfarm-setup/ [www.sidefx.com] )
And then I managed to VNC in and run Houdini Gui. I get the same errors, this time with loads of other errors beforehand.
Could not find scene mouse modifier file: SceneMouseModifiers
Unrecognized modifier key token: scene.handle.floor.mirror
Unrecognized modifier key token: scene.handle.rotate.inc_snap
Unrecognized modifier key token: scene.handle.common.scale_delta
Unrecognized modifier key token: scene.handle.orientknob.lock_axis
Unrecognized modifier key token: scene.selector.plane.fullspec.pick_normal
Unrecognized modifier key token: scene.selector.plane.quickspec.align_only
Unrecognized modifier key token: scene.selector.plane.quickspec.move_only
Unrecognized modifier key token: scene.selector.plane.quickspec.point_at
Unrecognized modifier key token: scene.selector.plane.quickspec.sec_point_at
Unrecognized modifier key token: scene.selector.plane.quickspec.sel_point_at
Unrecognized modifier key token: scene.floor.xy
Unrecognized modifier key token: scene.floor.h
Unrecognized modifier key token: scene.common.extend
Unrecognized modifier key token: scene.handle.bbox.mirror
Unrecognized modifier key token: scene.handle.bbox.uniform
Unrecognized modifier key token: scene.handle.crosshair.scope
Unrecognized modifier key token: scene.handle.crop.mirror
Unrecognized modifier key token: scene.handle.crop.restrict
Unrecognized modifier key token: scene.handle.domain.mirror
Unrecognized modifier key token: scene.handle.domain.copy
Unrecognized modifier key token: scene.handle.hose.group
Unrecognized modifier key token: scene.handle.hose.uniform
Unrecognized modifier key token: scene.handle.ikpivot.lock_click
Unrecognized modifier key token: scene.handle.isosegment.extend
Unrecognized modifier key token: scene.handle.pill.mirror
Unrecognized modifier key token: scene.handle.translate.inc_snap
Unrecognized modifier key token: scene.handle.slider.mode
Unrecognized modifier key token: scene.handle.motionpath.insert
Unrecognized modifier key token: scene.handle.motionpath.delete
Unrecognized modifier key token: scene.handle.motionpath.move_key
Unrecognized modifier key token: scene.handle.scale.inc_snap
Unrecognized modifier key token: scene.handle.mousewheelbump.slow
Unrecognized modifier key token: scene.handle.mousewheelbump.fast
Unrecognized modifier key token: scene.handle.mousewheelradius.slow
Unrecognized modifier key token: scene.state.brush.brush_radius
Unrecognized modifier key token: scene.state.brush.brush_radius_wheel_slow
Unrecognized modifier key token: scene.state.brush.stencil_clear
Unrecognized modifier key token: scene.state.capturelayerpaint.select
Unrecognized modifier key token: scene.state.edit.brush_radius
Unrecognized modifier key token: scene.state.edit.brush_radius_wheel_slow
Unrecognized modifier key token: scene.selector.join.flip_click
Unrecognized modifier key token: scene.state.stroke.cursor_radius
Unrecognized modifier key token: scene.state.stroke.cursor_radius_wheel_slow
Unrecognized modifier key token: scene.selector.uvpelt.hint_click
Unrecognized modifier key token: scene.state.bone_create.split
Unrecognized modifier key token: scene.state.bone_create.parent
Unrecognized modifier key token: scene.state.capture_weights.bone_toggle
Can't open dophints.cmd
Edited by memo - May 26, 2021 09:59:21
Houdini Lounge » weird artifact with timeblend +timewarp on FLIP
- memo
- 11 posts
- Offline
I have a flip + whitewater sim which I've cached with all properties, now I'm slowing it down 4x (i.e. timewarp frames 1…6000 stretched to 1…24000) and I'm using timeblend (i.e. cache -> timeblend -> timewarp -> NULL_OUT)
Most of it is working, but for some reason there are some artifacts, some (very few) particles are not being interpolated. You can see what I mean in these videos (I'm rendering as seq of tiff with alpha and I've tried 3 diff alpha matting methods -ignore, straight, premult - and it's noticable on all).
https://www.dropbox.com/sh/wo2fm2qjd87vhbw/AACkLgoOCqFzehwz8pLyLEfGa?dl=0 [dropbox.com]
(especially obvious when watched frame by frame).
in the link above I've also included a tiny segment of my raw data and a minimal hip file which shows how I'm doing the timewarp+timeblend
I have no idea what this is, or even how to debug it. Any ideas welcome!
Most of it is working, but for some reason there are some artifacts, some (very few) particles are not being interpolated. You can see what I mean in these videos (I'm rendering as seq of tiff with alpha and I've tried 3 diff alpha matting methods -ignore, straight, premult - and it's noticable on all).
https://www.dropbox.com/sh/wo2fm2qjd87vhbw/AACkLgoOCqFzehwz8pLyLEfGa?dl=0 [dropbox.com]
(especially obvious when watched frame by frame).
in the link above I've also included a tiny segment of my raw data and a minimal hip file which shows how I'm doing the timewarp+timeblend
I have no idea what this is, or even how to debug it. Any ideas welcome!
Technical Discussion » Is whitewater broken in H14.0.444 ?
- memo
- 11 posts
- Offline
Hi All, I just opened up a hip I had made with H13 a few years ago which involves a simple flip sim with whitewater, you can see a render here
https://www.dropbox.com/s/7dofebetwftrwia/waves_foam_2_cam1_halfspeed_60fps_40Mbps.mp4?dl=0 [dropbox.com]
(this is just the whitewater foam)
I have the cache of the raw flip output by itself, and I'm using that to feed into the whitewater sim.
When I generate the whitewater, the results are very different to what I had before (I still have the cache of the original whitewater too so I can compare).
What I'm observing is that no whitewater particles are going into the body of the fluid, instead they are just disappearing instantly and staying around the edges of the fluid. There seem to be other weird artefacts that I can't put my finger on (bits of whitewater particles appearing and disappearing instantly)
I've tried some of the shelf tools for waves etc but I have no comparison since I don't have H13 installed anymore. But the shelf wave tank also looks like the whitewater is mainly around the edges and surface and doesn't sink into the fluid with forces.
I am downloading H13 again to compare, but I was wondering if this is a known issue, or if a setting has changed that I can't find or have forgotten about!?
I'm on Indie edition btw.
—————-
UPDATE
I was pointed to these journals
https://www.sidefx.com/index.php?option=com_journal&Itemid=213&page=index&journal=default&view=FULL&logfile=COM14.0&icon=ALL&version=ALL&buildstart=&buildend=&perpage=20&search=whitewater [sidefx.com]
Unfortunately none of those mentioned issues seem relevant. I.e.I tried enabling the Jitter Birth Time and increasing Velocity offset as mentioned, but it didn't address my issues.In fact I could hardly tell the difference.
for those that are curious, here are the two sims overlaid, the dark particles are my original cache from a year ago, the bright particles are a new whitewater sim, with the same hip file but opened in H14, and using the same flip cache as I used to generate the whitewater a years ago. You can see they're dramatically different
https://www.dropbox.com/s/ls2ne63xpi6ihc3/H14_whitewater_problem.mp4?dl=0 [dropbox.com]
note that there seem to be more random noise on the new sim. I don't know if that's new, or just magnified
to avoid the dreadful dropbox video compression you may need to download the video.
https://www.dropbox.com/s/7dofebetwftrwia/waves_foam_2_cam1_halfspeed_60fps_40Mbps.mp4?dl=0 [dropbox.com]
(this is just the whitewater foam)
I have the cache of the raw flip output by itself, and I'm using that to feed into the whitewater sim.
When I generate the whitewater, the results are very different to what I had before (I still have the cache of the original whitewater too so I can compare).
What I'm observing is that no whitewater particles are going into the body of the fluid, instead they are just disappearing instantly and staying around the edges of the fluid. There seem to be other weird artefacts that I can't put my finger on (bits of whitewater particles appearing and disappearing instantly)
I've tried some of the shelf tools for waves etc but I have no comparison since I don't have H13 installed anymore. But the shelf wave tank also looks like the whitewater is mainly around the edges and surface and doesn't sink into the fluid with forces.
I am downloading H13 again to compare, but I was wondering if this is a known issue, or if a setting has changed that I can't find or have forgotten about!?
I'm on Indie edition btw.
—————-
UPDATE
I was pointed to these journals
https://www.sidefx.com/index.php?option=com_journal&Itemid=213&page=index&journal=default&view=FULL&logfile=COM14.0&icon=ALL&version=ALL&buildstart=&buildend=&perpage=20&search=whitewater [sidefx.com]
Unfortunately none of those mentioned issues seem relevant. I.e.I tried enabling the Jitter Birth Time and increasing Velocity offset as mentioned, but it didn't address my issues.In fact I could hardly tell the difference.
for those that are curious, here are the two sims overlaid, the dark particles are my original cache from a year ago, the bright particles are a new whitewater sim, with the same hip file but opened in H14, and using the same flip cache as I used to generate the whitewater a years ago. You can see they're dramatically different
https://www.dropbox.com/s/ls2ne63xpi6ihc3/H14_whitewater_problem.mp4?dl=0 [dropbox.com]
note that there seem to be more random noise on the new sim. I don't know if that's new, or just magnified
to avoid the dreadful dropbox video compression you may need to download the video.
-
- Quick Links