geometryshader driven muscle rig

arrangemonk

i read about the wrinklemap shader sometime ago and i thought since geometry shader are able to change meshflow and vertexposition, it sould be possible to create muscle deformation in a similar way to the wrinklemaps (with something like the push modifikator in max)

i think this would increase the animation quality of models without that much effort
(im not able to test this, because im running on xp64, means no dx10)^^

http://ati.amd.com/developer/SIGGRAPH07/Chapter4-Oat-Animated_Wrinkle_Maps.pdf
link to wrinkle map paper

Rob Galanakis

A geo-shader-driven wrinkle shader is one of the first shaders I ever thought about making when I was learning HLSL. The shader would determine whether the edge shrinks or expands, and blend in a wrinkle map based on that. I can swear I saw a paper for this somewhere.

The geo-shader driven muscle deformation would be equally possible. Whether the edge shrinks or expands could determine what/how much 'push' (or vertex displacement) map to use on the verts. It would be like pose-based morph targets, but driven through a shader and texture rather than the CPU or vertex data/attributes.

Unfortunately I know no geometry shader stuff since I don't have a DX10 card- it is something I have been wanting to get into and probably will in the new year.

CrazyButcher

why need a geo-shader (which main purpose is to add geometry) ? deforms could be done with vertexshader as well, and you could encode "bulge angle" detection in some vertexattribs or uniforms passed from outside.

geoshaders "adjacency" information might not help you much, and in all cases require some sort of extra data passed from app...

and geoshaders performance even in the latest generation of cards, is pretty poor (said by IHVs themselves)

Rob Galanakis

CrazyButcher wrote: »

why need a geo-shader (which main purpose is to add geometry) ? deforms could be done with vertexshader as well, and you could encode "bulge angle" detection in some vertexattribs or uniforms passed from outside.

geoshaders "adjacency" information might not help you much, and in all cases require some sort of extra data passed from app...

and geoshaders performance even in the latest generation of cards, is pretty poor (said by IHVs themselves)

Quite honestly, anything done in the GS can be done on the CPU. The issue is exactly what you said- encoding some vertex attributes or constants. Doing things in shaders allows them to be much more self-sufficient and requires no additional engine code.

I haven't looked at GS performance, but yes I'd imagine it wouldn't be great- however it is interesting to come up with these ideas and examples none-the-less, especially shader-driven ones that are just drop in solutions.

arrangemonk

ok, verteshader, so i have to read about it

but the main thing is moving the vertex in its normal direction depending on angle of the bone its driven by, and some sort of weight

hmm needs some research^^

Eric Chadwick

You could also approach it from the direction of using morph targets driven by bone angles. Downside is you have to store the targets. But you could use vertex color to limit specific areas of the mesh. We talked about doing this at my last job, just didn't get a chance to implement.

Rob Galanakis

arrangemonk wrote: »

ok, verteshader, so i have to read about it

hmm needs some research^^

http://tech-artists.org/wiki/Portal:Shaders

CrazyButcher

Professor420 wrote: »

Doing things in shaders allows them to be much more self-sufficient and requires no additional engine code.

I think you overestimate the amout of info the GS has "more" than a VS, and how useful that adjacency would be for this specific problem. (not much I think). You would need pretransform adjacent vertices and then find "angles". But how reliable are those angles ? very much tessalation dependent.
And similar to what Eric suggested you would need some sort of per-vertex attrib that says "how much" an area might affected... imo there is no way around additional information that can only be passed via engine to detect "bulging". And then some per-vertex weight to detect strength and possibly direction (which might not be same as normal)

and if you some those "costs" up, it very much ends up being easier to just add a few small bones for the dominant bulges, and rig them accordingly.

as for sophisticated automatic muscle deforms you might want to search research papers from "olga sorkine", she gave a talk here about her work, and its pretty nifty (not really made for real-time so, more feature-film autmatic detection of deforms)