Archived post by JeffLMnT

To quote @TOADSTORM you can punch tiny holes in the velocity field along the pressure front in order to break up big mushrooms. in a SOP solver connected to vel or sourcing input (set data name to “vel”), import the “pressure” field. use a volume wrangle to fit 0-0.1 to 0-1 (bind all volumes to density, f@density = fit(@density,0,0.1,0,1); ) then scatter points inside the density field, generate by density, scale ~7, max points maybe a million. fuse points by distance but keep unused points (not sure why this is done?) distance ~0.3 maybe. then in a volume vop/wrangle working on the vel field, open up a point cloud looking at these points. default radius ~0.25. get pcnumfound, if points are found, multiply vel by about 0.3, otherwise leave it alone. i think the basic gist is that you import the pressure field and then bind it temporarily to density, then ramp it to generate almost a band / isosurface so you isolate the main pressure front, then scatter points in it and use those points to “punch holes” in the velocity field. the easy way out is to just collide with scattered points but this A.) avoids collisions and B.) only applies at the pressure front so it might get cleaner and faster results

Archived post by trzanko

No, Initial state is the skin and tets at rest with the skin having the attrib pintoanimation set to 1. You don’t need a rest shape. Then target deformation is the deformed skin and the tets wherever, target strength parm can be 0 it doesn’t matter because of pintoanimation. You get the deformed skin of a tet mesh by setting the P to frame 1 and then piping the anim into an attrib, then after the solid embedd you set P of the skin to the attrib and there’s your target skin with matching topo. Here’s a file I had for debugging the workflow. Let me know if you have any questions.

you could honestly just change the inputs of this file and pipe the output into a wrinkle sim

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/createAnimTetMesh.hip

Archived post by TOADSTORM

yo @Fogelstrom not to toot my own horn but there’s a little section at the end of this blog post that goes into a similar kind of technique… you can generate “ribbons” of geometry or really any kind of surface and use it to drive volume shaders for nice sharp edges. it also means you don’t have to rely on pyro when things need to be more directable and less dependent on fluid dynamics.

www.toadstorm.com/blog/?p=465

Archived post by Wyeth

@mestela are you in forward or deferred? In forward, baseline shaders cost 4x as much as deferred in instruction count, however the shader complexity viewmode doesn’t remap to show you a normalized view of “expensive”, it’s remappable in INI but isn’t immediately apparent.
Also what do you mean when you say redlining in vertex shader but not pixel shader cost?

Or do you just mean the little vs/ps guy jumping around? I don’t trust that view AT ALL. Edit: to explain , shader complexity view is great and can be trusted, it’s the little ps/vs dude jumping around which means nothing

Do you *really* want some mad info? Do the following:
type r.showmaterialdrawevents 1
Then, type profilegpu (or hit shift-ctrl-comma)

Now expand scene/translucency, and you will see all your materials, and their discrete costs

On sprites, pixel fill will ALWAYS be the bottleneck compared to vertex shader. There are four verts per quad but in an overdrawn effect you might be shading 10,000 pixels 10+times each.

This is always why offloading work to the vertex shader on sprites is so powerful of an optimization. Anything that can be linearly interpolated can be offloaded to the VS on sprites (texture coordinate work, for example, which is inherently lerped), which might only subsequently happen 40 times in the frame (once per vertex) vs. 100,000 times (once per pixel).

Also note: whether the particles are simulated on the CPU or GPU has no bearing on the shader cost. the engine doesn’t care if they are simulated on the GPU or the CPU, once it hits the renderer, it’s all the same.

For reference, if I capture the “tuturialparticlesystem” in engine content using the aforementioned showmaterialdrawevent combo with profile gpu, it shows up as costing 0.11 milliseconds when in mostly fullscreen

If we were working on VR I generally like to keep my GPU under 9 milliseconds, so that’s a small chunk of our frame, and I likely wouldn’t pay it too much mind in comparison to other costs.

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/unknown.png