mkultra333 wrote:1. What's the batching overhead? I already have a system that allows 6 to 12 entities to be rendered in a single batch. This is probably what the player would typically encounter, 6 to 12 of the same type of monster at once. I suspect for these low numbers, my system would batch better than the Ogre method, which I'm guessing uses at least 2 or 3 batches to render any meshes.
That's hard to answer. But if you're using the same material, and the same mesh; and you've given a good hint about the instance count per batch (i.e. don't tell the engine you'll have 1000 instances when you're going to use 6) then the overhead is very low.
mkultra333 wrote:2. Can I change the structure of the skeleton used by each individual entity? My entities explode into lots of wreckage when they die, and at that point I modify their skeletons, so that all the child bones become free from their parents. I'm wondering if this is also allowed in the Ogre instancing.
My guess is no. But I don't know what exactly are you planning to do. All instances share the same skeleton, so if you change the skeleton, it will affect all instances.
However, you can create a keyframed animation that sets positions & orientations as if the bones were parentless. If the interpolation doesn't screw it too much, you can get away with that; by playing the "exploding animation" for those entities.
Another solution is to swap the instanced entity with a normal Entity that can explode (or for instanced entities with skeletons that allow exploding). This is why InstancedEntity derives from MovableObject, so that you can treat them almost equally and swap with little issue.
mkultra333 wrote:
3. What are the limitations of the different Ogre instancing methods? I've read this whole thread now, looked at the api, and read the header files, and I still don't understand what the different methods mean. There's this in the header:
ShaderBased, //Any SM 2.0+ @See InstanceBatchShader
TextureVTF, //Needs Vertex Texture Fetch & SM 3.0+ @See InstanceBatchVTF
HWInstancingBasic, //Needs SM 3.0+ and HW instancing support @See InstanceBatchHW
HWInstancingVTF, //Needs SM 3.0+, HW instancing support & VTF @See InstanceBatchHW_VTF
I gather HWInstancingBasic doesn't allow any animation, while the other methods do. But apparently there are some limitations to the animation in the different version... what are they?
In short:
ShaderBased -> Crap, but runs on old ShaderModel 2.0. Number of instances per batch can be quite limited.
TextureVTF-> Crap, but runs on older OpenGL versions that didn't support HW instancing. Can be very fast, but can waste a lot GPU bandwidth.
HWInstancingBasic -> Awesome, use this one if your model doesn't use skeletal animations
HWInstancingVTF-> Awesome, use this one if your model uses skeletal animations. Needs DX10 capable hardware to run at full speed (even if you're using D3D9 or OGL rendersystems). In other words, any GeForce 8000+ or ATI Radeon HD 2000+
Note that the "crap" versions is compared to the "HWInstancing" versions. All of the techniques surpass normal Entity rendering.
mkultra333 wrote:Also, what's the difference between the version that uses scene nodes and the version that doesn't?
Using SceneNodes is more generic and easier to work with (since Entities and InstancedEntities are treated equally, and will behave in the same way)
Not using SceneNodes will give you raw performance (it's faster)