Skinned mesh instancing? What's that?

Quoted from Unity 4 website page:

Can someone elaborate on this? It's too vague for me to be sure what it means. I don't want to be disappointed afterward...

 

It means you can compute a skinned mesh once and use it multiple times with only the rendering cost of each instance. Well, Unity still have to perform the world transform for each instance vertices but you avoid performing the costly skinning computation multiple times. This is used typically to render crowds : you can display dozens or even hundreds of characters where there are in fact a few unique different instances (mesh + pose) at the same time. You just have to mix them adequately to hide the best you can they are only clones. The most common situation for this is a supporter crowd in a stadium for a sport game. If you look closely (or even not that closely), you'll see that every person have multiple twins with the exact same pose at the exact same time.

 

Does it? Unity doesn't need to use that data, right? Just the GPU needs to transform every single one.

 

You're right. Technically the GPU handles that... well at least for uniformely scaled objects. In my mind though, GPU or CPU side is just something that's handled by Unity and doesn't change the fact that it does have a cost however small it may be.

 

Does this instancing means that each character is still unique in terms of script (AI) configuration, it just has to use the same skeleton and animation data than rest of characters, or does that mean that character has to use exactly the same animation at the same time that other characters are using, at least thats what it seems from video. For example if players character is playing one animation, does that mean that other characters have to play it too if they are using this kind of instancing? From all engine grouping systems it seemed that way, i am wondering if this one is anything more useful than the rest.

 

I believe it requires exactly the same mesh at the same frame of the same animation, otherwise it couldn't be instanced correctly (or cheaply).

 

Ah:/..............Just wondering, in what cases is that even useful, to have all characters performing same act at the same time? I cant find a one example.

 

Crowd in a sport stadium, crowd along the road for a racing game, large army of soldiers marching in a tower defense game, huge flock of birds or animals for whatever real time cutscene... There's plenty of real world applications for this.

The point is not ALL individuals need to be the same, you can have 5 to 10 different characters and mix them to create huge crowds.

 

i think i will work with same mesh same skeleton but not same animation at the same time.

i expect the same thing at 00:53 in this video: http://www.youtube.com/watch?v=-m4pe6UAS2M

 

Yes, what you described is the "cheaply render multiple instances of a mesh in the same pose" part.

There are three parts been mentioned:

1. Unity 4 gives you script access to the output from a skinned mesh renderer,
   Q: What output? The mesh after being transformed by the bones? I really wish this can be confirmed.
2. so you can precompute animated poses,
   Q: I don't follow this one...
3. or cheaply render multiple instances of a mesh in the same pose.
   This is what Krobill said.

 

The feature description specifies it needs to be the same pose hence the same animation at the same time. You can also precompute poses, so I imagine you will also be able to attribute different poses to different instances if you have precomputed the whole animation cycle.

 

@sunnydavis

1. the mesh transformed by bones. I'm not a UT developer but I can't see what this would mean otherwise if it's related to a crowd rendering system as mentioned in the feature description.
2. you will most probably be able to store a set of data for any pose you wish. It's computed once and can be used cheaply multiple times on different instances or at different time.
3. actually the 3rd is the logical conclusion, the benefit if I may say, of what you call the first part and the second part of the phrase...

 

You'll probably find the biggest benefit with someling like grass where you have thousands of instances and don't mind that they're the same.

 

errrrr... for grass you'll most probably stick to vertex shader animation which will allow variations in instances by storing variables in the geometry, or using the world position.

 

When will be the time we get the mesh output from skinned mesh renderer? LateUpdate() is not late enough since the bones still can be changed at that time. Will there be a LateLateUpdate()?

I really need the transformed mesh for ray casting, currently I have to manually do the bone transformation by C# while knowing that Unity has a transformed copy just don't want to share with me.

 

Could you use this to say, duplicate the pose of a character for the purposes of making something like an after image? If anyone's played the PS2 Shinobi game, something like that where the after image is basically a copy of the character's model in the last pose (with a different material tossed on for effect).

Or am I not understanding correctly?

 

Ah right that makes a lot of sense

 

When will be the good time to call BakeMesh()? Say, if I have modified the bones in LateUpdate(), is it possible to call BakeMesh() in the LateUpdate() and get the transformed mesh? And similarly if the skinned mesh is a ragdoll and bones are updated by physic, should we call BakeMesh() in FixedUpdate()?

 

BakeMesh isn't relevant to geometry instancing, right?
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch02.html
How can I implement it?

 

Are there any example projects of this kicking around? Aras, care to whip a simple demo scene

pleeze?
~A

 

I would also appreciate to have a simple demo scene.

 

A simple demo example would be awesome (please Aras or other Unity helpers! ). Also, it sounds like the "SkinnedMeshRenderer.BakedMesh(Mesh outputMesh)" step performs a COPY. Is there a way for the instanced model to simply share the resulting skinned mesh via reference to greatly reduce the memory footprint. I would like to try this with a very large crowd.

 

Well, I expect that it has to do a copy, because it's copying the data from the original skinned mesh which will be changed next update.

There's no reason you can't do the copy once and reference it from a bunch of models simultaneously, though.

 

Hmmm ... I would settle for a bunch of models that share a single mesh and copy to that mesh once from the skinned mesh each Update (via BakedMesh). How can I achieve that in code? I have prefabs for the skinned model and a non-skinned model already working as described using BakedMesh in an Update. So how can I create in code some more instances of the non-skinned model that use the exact same mesh? (e.g. I don't want to have a separate copy of the mesh for each "instanced" non-skinned model. - that would take too much memory and CPU for all the multiple copies)

Thanks for help!

 

I would like to look more into this as well. KarelA I tried the little code snippet you posted a couple months ago, and I keep getting an error, something about skinnedref needs to be a skinned mesh renderer. Anyways, not quite sure how this works, or what it does exactly, but I'm developing an rts game and wondering if I could use this to save fps on units with the same mesh renderer etc....

 

Hello, I'd also like to render the mesh of a SkinnedMeshRenderer multiple times without performing a BakeMesh as it's incredibly slow. I only want to draw it two more times. 1 SkinnedMeshRenderer + 1 BakeMesh + 2 MeshRenderer is the same CPU cost as 3 SkinnedMeshRenderer's.

Is there a way of doing this? I don't need to keep a copy around as I only want to redraw the output a single SkinnedMeshRenderer 3 times in 3 different positions.

Thanks for any help

 

yup same here, curious to see how the thing actually works...
I should give it a try soon....

 

Sorry to wake an old post. I am wondering if it would be possible to get an instance of a skinnedmeshrenderer after the skinning process (apply anim bones to mesh, etc.) then use the mesh as a reference for a mesh collider.

 

mesh Collider as static mesh?
if yes then you can catch the triangles and vertices only from the skinnedMesh and to insert it in a new Mesh... It should be juste fine I guess?

 

Yes, Mesh Collider as static collider. And it can't hurt if it was dynamic, right. (well, except for the performance hit...)

 

Is that not what SkinnedMeshRenderer.BakeMesh() does?

 

Not sure about that. I actually haven't had time to test out that sort of stuff. can hopefully do it this afternoon and bring back results.

 

Has anybody tried to do this to do 'oldschool' interpolated-keyframe animations, as done in at least Quake 1 and probably many others?

- Convert animation to N baked frames
- Somehow insert frame N+1's position/normal in frame N's vertex data
- Use a vertex shader to blend between the two

As there's limits to the flexibility of Unity's vertex format, squeezing in the 2nd position/normal (or delta between them) would be interesting, but I suspect you could shove the positions in the tangents slot and the normals in vertex colours?, perhaps?...

Maybe this would allow a decent number of small animated enemy characters in a mobile game, so long as they were fairly low-poly and with limited anim sets, to keep memory usage under control

 

@bluescrn: that would be quite difficult, if not impossible, due to Unity's way of handling vertices!

Maybe this is something to ask Aras, who I believe is the UT graphics guru here.