Per instance vertex colors

[Niosop]

Is there any way to set the vertex color of an instance of a surface? SetVertexColor changes it for all instances of the surface. I suppose I could reconstruct the surface of the mesh in code and swap it out, but would be nice if there was a built in way.

[Flexman]

I think the engine is optimised in such a way that you can't do that. As you say you'd have to reconstruct the surface.

 

Without knowing what it is you want to do this suggestion might be useless; can you use "findchild" on the mesh? If iit's a child you can use EntityColor on it (but you probably know that already).

 

 

Create surface and copy from existing one would be your best bet then.

[Josh]

What do you want to use this for?

[Niosop]

Well, I'm trying to implement vertex painting so you can use the same model/mesh many times but each can have different vertex colors. Eternal Crisis is working on a shader that will blend different textures based on the vertex color. Hopefully it will make it so that you can have a ton of uniquely textured instances of objects without the overhead of creating a new texture for each of them. I thought about using the decal system, but that creates a new surface and thus a new draw call for each, which could get really expensive.

 

I'll try just creating a new mesh/surface on the fly and see how that works. Guess it will probably only work for things loaded with LoadMesh and not LoadModel, thus no LOD would be possible. Not even sure how well it will work with mipmapping. Only one way to find out I guess unless Josh has attempted this in the past and has any comments about the viability/hurdles/etc.

[Josh]

This is how I did vertex lighting in very old versions of the engine. Each instance had a unique color array that was switched when instances were drawn.

 

This is not part of the design of the modern engine.

[Niosop]

Would you recommend making it a user defined sized RGBA texture to map the other textures instead (like the terrain layers do)? That has the advantage of not requiring a high vertex count to be able to add layers, but may require a second non-overlapping/non-tiling UV set to be defined on the mesh to work properly if they use tiling or shared UV space. Doing it per-vertex allows you to use it regardless of UV layout but doesn't work well on very low poly meshes. I guess having both methods available would be ideal, but I figure I'll just focus on one for now.

 

Where does using a single shared instance of models/meshes/surfaces help performance? Just RAM or VRAM/GPU as well? I'd assume every instance is still an additional draw call, right?

[TylerH]

Depends on what you actually call a "draw calls".

 

As in a call to glDrawArryas or glDrawElements, that is done once per Vertex Buffer Object (VBO) or once per Vertex Buffer Array (VBA [collection of VBOs]) depending on your setup.

 

Last I heard I thought Leadwerks Engine used VBOs per-mesh, and just translated, rotated, scaled Object Space and then made a call to glDrawElements of the same VBO, on a per-instance basis.

 

Anyways, I am not the one to have the answer.

[Josh]

The engine uploads an array of matrices and draws a batch of like objects in one call.

 

The texture offset idea is not bad. You could use the per-instance color to control the texcoords for it.