mrWolf Posted April 24, 2013 Share Posted April 24, 2013 I have been banging my head against a wall (with a static solver) for days now. I really cannot make this thing work. I hope someone can give me an insight of why is this not working cause my head kinda hurts. I have a sop solver inside a sop network. All the sop solver does, is the following: - move the input geometry off by a "stepsize" on the $TX - add a point and merge it with the previous geometry When I play the simulation I have a nice and clean series of points on the axis X, growing by one point every frame. That all works perfectly. Now, I add a timeshift with the number "100" in the "time" field. I expect to see 100 points in a line, on the X axis. And it works ! Now I change the parameter "timestep" (on the node "parameters" referenced in the sop solver) and I expect to see my line of points change interactively! But that doesn't work. The weird thing is that sometimes it works (like the first time I do it after playing the sim), and all the subsequent times I change the parameter only the first 'iteration' of the dop network gets executed. I attached a simple hip file to illustrate the issue. Any idea how to fix this ? Alessandro dopnetissue.hip Quote Link to comment Share on other sites More sharing options...
anim Posted April 25, 2013 Share Posted April 25, 2013 that may be an unnecessary use of SOP solver, in your case you can completely replace it with For Each SOP to get interactive feedback here is a little read on the differences http://www.sidefx.co...p=130969#130969 dopnetissue_mod.hip Quote Link to comment Share on other sites More sharing options...
mrWolf Posted April 25, 2013 Author Share Posted April 25, 2013 Update: If I force the cook with python after changing the parameter "stepsize": hou.node('/obj/dop_net_test1/dopnet1').cook(True) the geometry gets recalculated correctly, but only if "stepsize" doesn't contain keyframes. Infact... I tried to keyframe the "stepsize" parameter (for instance frame1 : 0.01 -- frame100 : 0.1) - If I play the sim, it doesn't work (nothing new here) - if I force the cook on a random frame (say 34), using the above python line (stepsize:0.034) I expect the dop network to be cook. But no, now it doesn't work anymore. Quote Link to comment Share on other sites More sharing options...
mrWolf Posted April 25, 2013 Author Share Posted April 25, 2013 Tomas, good point, it makes sense. The example I posted is a simplified version of a much bigger effect in which I need to use SOP VOPs (I need 3 inputs in the vop) to add a point to a the geometry A based on data (present on the geometry A itself) calculated the previous frame. So basically my geometry grows, and every iteration accesses the geometry in the previous state. I'll try a foreach version of my script. I've a couple of questions about the memory usage differences in foreach and sop solver: If i use a "merge object" into the foreach loop (say i merge a SDF volume) will houdini just reference the data outside the foreach, or will it copy the data temporarily in memory ? If it has to merge all the geometries, will it keep the outputs of all the iterations in memory, and them merge them at the end of the loop ? The reason cause i used the SOP solver is cause to me it seemed it was just referencing the geometry, without filling the memory with copies, during the calculation, but i might be wrong. It would still be great to understand why the DOP version is not working by the way. that may be an unnecessary use of SOP solver, in your case you can completely replace it with For Each SOP to get interactive feedback here is a little read on the differences http://www.sidefx.co...p=130969#130969 Quote Link to comment Share on other sites More sharing options...
anim Posted April 25, 2013 Share Posted April 25, 2013 it really depends on what you are doing in your real scene you can effectively combine For Each and SOP Solver for tasks they are best for in your example you weren't expanding your geometry on frame by frame basis but rather certain amount of times on a single frame and that's why is better to use For Each in that case in this mode For Each reuses geometry from previous iteration to compute next the same way as SOP Solver reuses previous frame, there is only geometry from previous iteration and current iteration kept in the memory until it finishes, then it will remember only the result so it will not accumulate any other referenced geometry than what you output each iteration for SOP Solver with Timeshift hack you should be able to get interactive feedback if you turn off Cache Simulation on DOP network, works at least in H12.5 but i wouldn't do it that way for this case and it's probably less efficient than For Each anyway Quote Link to comment Share on other sites More sharing options...
mrWolf Posted April 25, 2013 Author Share Posted April 25, 2013 dear Tomas, in the meantime, I copied and pasted the whole content of my SOP solver into the foreach node, changed literally 2 fields, and it worked like a charm immediately. Thank you so much for your hint, I have been stuck on this for days, blinded by the idea that forloop sops should never be used cause they're slow. In my specific case, it is exactly as fast as the SOP solver version , without the timeshift issue. that may be an unnecessary use of SOP solver, in your case you can completely replace it with For Each SOP to get interactive feedback here is a little read on the differences http://www.sidefx.co...p=130969#130969 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.