Author: admin

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