Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardware skinning #7

Open
Codewyvern opened this issue Jun 7, 2016 · 9 comments

Comments

@Codewyvern
Copy link

commented Jun 7, 2016

Is hardware skinning a possibility? something like dual quaternion skinning? I guess there would have to be a bone limit though. Would be cool to see this library working on mobile devices with skinning done in the vertex shader.

@jazzbre

This comment has been minimized.

Copy link

commented Jun 8, 2016

Already did this, works great, sadly I can't share the code/project.
To maximise possible bone count I always transpose the 4x4 matrix (on the CPU side) and just use 3 constant vectors instead of 4. Then in vertex shader for x,y,z just do a dot product with the three bone constants.

@guillaumeblanc

This comment has been minimized.

Copy link
Owner

commented Jun 8, 2016

Thanks for your comments.

Hardware skinning
I think hardware skinning would break the renderer agnostic aspect of ozz library. Hardware skinning is performed on the gpu, using vertex shaders, which requires a setup and a language (CG, hlsl, glsl...) specific to every API (DX, OpenGL...). So not sure there's really a possibility. I have to think more about it to see how this could fit in different renderers.
On the other hand, as @jazzbre has experimented it's quite doable. The good point is that the data input format of ozz SkinningJob is very close to the input format of hardware skinning. Vertices, normals, tangents, weights, indices need to be sent as attributes (via vertex buffer object in OpenGL), in the same format ozz job uses. Skinning matrices (model space * inverse bind pose) are uploaded as uniforms (constants). This can be optimize/packed indeed as the last matrix row isn't meaningful.
I'm not really up to date the gpus, but I think hardware skinning brings a bone count limit indeed, one that cpu doesn't have. Skinning matrices are passed as constants which have a limited size. I'd recommend to split the mesh into pieces that are influenced by a fix/small number of joints, and do a draw call per piece.
Would a "hardware skinning" sample help ?

Dual Quaternion
That's definitely something I want to investigate. There's a conversion stage (from ? to dual quaternion) required at some point of the pipeline, probably after (or while) converting to model space. It should be handled by the library. It would work for software skinning as well as hardware, but at that point I think ozz should still provide software skinning only. I don't know how joint scaling would work though.

Mobile devices
I never had a chance to see ozz working on a mobile, except through web/emscripten samples at least. It should compile properly but would most probably lack SIMD acceleration and fall back to the scalar implementation. Is CPU the bottleneck on those platforms, to justify hardware skinning?

Thanks,
Guillaume

@Codewyvern

This comment has been minimized.

Copy link
Author

commented Jun 9, 2016

A sample would be great yes, it would certainly attract a lot more users to this library, there is hardly any other open source skeletal animation libraries out there. One sample for opengl and one for directx would be awesome. From what I know the GPU on mobile devices is usually a lot faster than its CPU, so hardware skinning is ideal. I would attempt to write such a thing myself but all this math heavy stuff is really not my strong point.

@kylawl

This comment has been minimized.

Copy link
Contributor

commented Jun 9, 2016

Add any new features you want, but keep the main components lean. Ozz is excellent because doesn't force a tonne of arbitrary features and systems on you.

@Codewyvern

This comment has been minimized.

Copy link
Author

commented Jun 9, 2016

Well as long as its optional and cleanly separated as an extension to the main library, I don't see a problem.

@shakesoda

This comment has been minimized.

Copy link

commented Jun 9, 2016

Hardware skinning is fairly easy to implement yourself - I don't think it's the lib's business and it introduces platform (graphics API) dependence. A sample is a good idea, though.

@guillaumeblanc

This comment has been minimized.

Copy link
Owner

commented Jul 8, 2017

A bgfx sample using ozz-animation would be awesome to demonstrate hardware skinning. Anyone interested?

@Alan-FGR

This comment has been minimized.

Copy link

commented Jul 16, 2018

I don't think it's the lib's business

This! We need a focused high-quality lib for animation (that does just animation and does it well). Samples are fine ofc.

@shartte

This comment has been minimized.

Copy link

commented Dec 12, 2018

I've been using Ozz for sampling and Google's filament for actual hardware skinning successfully together.
The skinning aspect just seems highly rendering engine dependent.
One aspect however is object picking, for which CPU side skinning might be needed, but Ozz already has that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.