Initial SIM frame in all subsequent frames

[5DNick]

Dear ODForce people,

 

I've fed a frame from a pyro sim I did into another sim to be the initial data.

I then run that and cached it but it seems to still contain the initial data frame.

 

I've attached .hiplc file but not cache files.

 

Can you see or do you know the problem? Do I NEED to upload the cache files too?

 

Cheers

 

Nick

SLOMOPYROexplode05.hiplc

[bunker]

1) you need to separate the initial data fields, eg: Density SOP Path is expecting density only
2) your volumesource SOP Path, is set to the initial_data, instead you need a volume source (retimed for slowmo)

[5DNick]

So I've blasted in three different streams eg. not @name=density etc. and specificed those in the smoke object. Is that correct?

Then I'm feeding a convertvdb (converting to volume) into volume source SOP path. Is that correct? I'm not sure what you mean retimed for slowmo? A retime node? Don't know how to use that but will look into it if correct

 

Thanks for the help

[5DNick]

OK that problem seems to be fixed (without retime node)

 

However there is also a problem at rendertime. emission seems to be small at beginning and rise fast to levels which overexpose cam.

is there an obvious reason for this (error i made) ??

i'm using redshift and dont really wanna keyframe emission. plus redshift pyro seems to need a delicate balance of scatter absorption AND emission so this might be too hard

NB: my redshift setup is fine with normal pyro (like the first sim in the .hiplc file in the OP)

 

thanks for the  help

PS: i'm a happy bunny atm cos i feel like I'm actually learning Houdini whereas before I always felt out of my depth

[5DNick]

here is short clip

shadingproblem.mp4

[bunker]

that looks like a sim issue, not shading. can you upload your latest scene?

[5DNick]

oh ok. here:

SLOMOPYROexplode07.hiplc

[bunker]

you were mixing sparse pyro and old pyro solver, completely different solvers
you should have a look at this thread:

in your case, you can just plug the result of the last frame into a new sim
using the SOP pyrosolver (sparse), and copy the fields with the "copy" operation on frame 1:
note that I copy flame>flame instead of burn>flame since it doesn't exist in the cached sim.
hope that makes sense.

SLOMOPYROexplode07b.hiplc

PS: creating slowmo explosions isn't easy, have fun

Edited April 6, 2021 by bunker

[5DNick]

Thanks alot bunker. Yh i bet its not easy!!!!! I always dive in the deep end with my projects, even if they don't get finished sadly!

BUT NOT THIS TIME!!!!!!

[5DNick]

cool. i see what you did. thanks. so i am going to proceed by siming 50 sub frames and then putting these into the normal frame time range right?

not entirely sure how to do this but going to look into it

this is the way to do it isn't it?

i understand timescale breaks the physics equations under the hood? navier-stokes? i'm intermediate at maths.

[5DNick]

getting this error now:

 

Traceback (most recent call last):
  File "Sop/filecache/execute", line 1, in <module>
  File "C:/PROGRA~1/SIDEEF~1/HOUDIN~1.462/houdini/python3.7libs\houpythonportion\ui.py", line 1081, in decorator
    return func(*args, **kwargs)
  File "C:/PROGRA~1/SIDEEF~1/HOUDIN~1.462/houdini/python3.7libs\hou.py", line 69068, in render
    return _hou.RopNode_render(self, *args, **kwargs)
hou.OperationFailed: The attempted operation failed.
Error:       Cook error in input: /obj/explosion/filecache2/cast_attributes
Error:       Invalid source /obj/explosion/pyrosolver2/dopimportfield1/load_each_field_end
Error:       The sub-network output operator failed to cook: /obj/explosion/pyrosolver2/dopimportfield1/switch3
Error:       Invalid source /obj/explosion/pyrosolver2/dopimportfield1/load_a_field
Error:       pyro - /obj/explosion/pyrosolver2/dopnet1/pyro_solver/add_turbulence/add_forcvel_temp_to_vel: OpenCL Exception: clEnqueueUnMapMemObject (-30)....

 

WTF?

[5DNick]

this only seems to happen when attempting cache. i'm trying to troubleshoot atm

[5DNick]

it maybe VRAM problem. i have 24GB on a 3090 so thought it would not be a problem but decreasing voxel size massively solved it. so i reckon makes sense its VRAM prob yh? gunna try to find sweet spot now.