celd

Coronavirus must be a global pandemic! It has even infected my odforce!

Hi, I came across this problem couple of times, go inside the particlefluidsurface/FLATTEN and after "flatten_geo" vop drop down a Poly Fill. This should fix your problem.

In case anyone ever stumbles upon this thread and wonders what caused these problems, I think I solved it. Inside the gas guiding volume dop, there are 2 gas linear combination nodes for guidingsurface and guidingcollision fields. These nodes should make sure that collision fields are properly accounted for in the guiding surface field, however if your collision field is set up in static object as a "Volume Sample", it produces very stepped guiding surface in the domain of the collisions. The solution to this is to either use "Ray Intersect" on the static object and so calculate the collision field every frame, or disable the 2 gas linear combination nodes, and do the same operation in sops - using vdb combine->sdf difference, and then bring it over with a sop solver. This produces a nice smooth guiding surface and so no weird artifacts happen.

Hi, I am summoning all of you flip gods! In the images you can see the flip explodes upwards for no apparent reason, this seems to happen along the boundary of the collision object. I am using guided ocean layer setup. The collisions otherwise behave correctly. I have tried high res sim, low res sim, changing grid resolution, changing collision geometry (submarine model, simple scaled sphere), deforming collision geometry, object transform collision geometry, zeroing out collisiovel field, high resolution collision vdb, low resolution vdb, playing around with depth of the guided ocean layer, different amount of substeps(both flip solver and autodop), reseeding settings, changing integrator types in the flip solver and probably more... Quite frankly I am at my wits end and I wonder if anyone has ever seen this kind of a problem and if there is a solution to it. I would also like to avoid making the boundary layer exceedingly deep, as this would most likely kill all the detail. I have attached a simplified hip file where this problem occurs. Thank you exploding_water_problem_v1.hip

This is exactly what you can use the new TOPs for - They give you the option to run these water simulations essentially at the same time, with caches further down the stream beginning to run as soon as their dependencies are available.

Hi,I have a multiparm block (list) folder with 2 parameters : 1)label and 2)integer parameter with different values for each parm instance. I would like each instance of the label to reference its pair instance of integer parameter (and then hide the integer parm so users can only see the label displaying its value). I tried writing this: `ch("intparm#")` into the label field, but it seems to always look at intparm1, even for additional instances. Is there a way to do this somehow? Maybe force a python script into the label field? Any other workarounds? Thanks

if you unlock the POP force node and go into the noise_force VOP, you can see on the right how it combines the force every frame, there are two bind nodes: one to bring the force into the vop, and second to output it. Between them there is an add node and it combines the force with a calculation from the current frame. If you want to kill the additional force you are adding on one axis, you could drop down multiply node and multiply it with a constant vector - for example (1,1,0), that way it will only add the force on x and y axis.

Oh are you just trying to retime the simulation? in that case you can just delete the expression in the timeshift (after transformpieces) and keyframe your own values, so for example on fr. 1 you set it to 120 and on fr 120 you set it to 1, then it will run it backwards according to that animation.

The first and third input into your transformpieces is your fractured + packed geometry. Instead, the third input should be the same as the second one, except before you connect it, you also need to drop timeshift and set it to a static frame. It wont fall down if you dont add gravity? Seems to me like your sim is already really broken up by the wind anyway

Looks to me like you basically set it up correctly, but last input for transformpieces should also be the point representation coming from dop, with timeshift on the rest frame. Also why not do an proper bullet sim with pop wind plugged in?

You can volume sample the fields and replicate the same setup that pyro shader has. You can do this in the shader as well. color_attribute_transfer.hip

I would say it depends on the studio, usually the larger studios should have plenty of space to spare. If you are however really starved for space I dont see why you couldnt do it, just be careful when compressing vector fields like this, I found it can remove too much information sometimes.

Think of it as comparing an 8bit jpg and 32bit exr formats, they capture different ranges of data but can display the same thing. 16 bit volume will have a smaller range but still look correct enough under the right conditions. So its the bit depth of the value of individual voxels.

You havent provided the source geometry so people cannot really help you. I would however suggest you use vellum for this, instead of the old cloth solver, it was never very good.

You could use Set Vector Component VOP to pick a specific component of a vector and set its "fval" to be the output of your ramp. The geometry vop outputs however expect P to be a vector and you will need to give it a vector. I dont think you can export just a specific component directly.