Jump to content
Niosop

Non-instancing copy command

Recommended Posts

Thanks for looking into this Niosop. If it's that much of a pain and still has restrictions like only 4 parts of the body that you can do that, I'll stop worrying about it and hope that Josh will one day put in a way to handle this that is more flexible.

Share this post


Link to post

Just for those of you who are curious as to how much instancing actually helps I did a little test with a 2.4k tri model.

 

200 models

Instanced: 117 fps

Non-instanced: 79 fps

 

100 models

Instanced: 132 fps

Non-instanced: 97 fps

 

25 models

Instanced: 177 fps

Non-instanced: 152 fps

 

Anyways, just thought it might be nice to have some solid numbers. If you don't have many instances of the same object then instancing doesn't make much difference, but if you do then it can be a pretty massive performance boost.

Share this post


Link to post

I think instancing works great for scenery, and even the shader part would help with tree's and rocks and stuff to give different looks, but when it comes to characters I think is where it hits some road blocks. This is probably one of the reasons you don't see 200+ characters on the screen at one time very often in games, and if you do they are probably pretty much the same looks because of instancing and texture limitations. I'm guessing this is probably great for an RTS where groups of units all look the same.

Share this post


Link to post

Just out of curiosity, couldn't you, at runtime, swap out the texture atlas in the material, in say the case of the 256 shirt textures in the 4096x4096 atlas, giving you an infinite number? Or does that succumb to the same flaw that the material file is shared globally across all instances?

Share this post


Link to post

Where would you do that though? I think that would have to happen at a level where you can swap in a texture then draw model x so it's on the screen with texture 1, then swap in a different texture, then draw model y, etc. If we could do that then there wouldn't be a need to use an atlas at all. You could just swap textures before drawing.

 

At a code level ideally you'd be able to "save" what material file per instance to use. Then when the instance is drawn it would do the swapping of what mat file you assigned it, then draw that model. Continue on with all instances.

 

So something like:

 

mat1 = LoadMaterial("red_shirt.mat")

mat2 = LoadMaterial("blue_shirt.mat")

 

model1 = LoadModel("mymodel.gmf")

model2 = LoadModel("mymodel.gmf")

 

PaintEntity(model1, mat1)

PaintEntity(model2, mat2)

 

 

So internally the engine would need to save off that model1 needs mat1 and model2 needs mat2 so when it comes time to draw these models, even though they would be the same instance, it would swap the materials then draw.

 

 

I like the idea, but I'm thinking it would need to be internal to the engine.

Share this post


Link to post

Even then, if we could have non-instanced materials across instanced models, we still wouldn't need atlases. We could just paint with different materials accordingly.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×
×
  • Create New...