Skip to content

Conversation

@chillywillysoft
Copy link
Contributor

SubMeshes can specify a default Material that SubEntities may use or override. The SubMesh's default Material can have shader programs that take custom parameters as inputs. SubMeshes should be able to specify default values for those custom parameters that SubEntites may use or override.

While the parameters can be set at the Program level, the Material/Pass level, and the SubEntity level, I have a situation where a parameter is calculated during the procedural generation of a Mesh/SubMeshes and that would be the most natural place to stick the value.

I made a draft but am open to feedback. Specifically, I wasn't sure about exposing the Renderable::CustomParameterMap implementation and including its header in SubMesh.h

@chillywillysoft
Copy link
Contributor Author

If this is a welcome idea, I can code up the .mesh serialization for it...

@paroj
Copy link
Member

paroj commented Nov 30, 2025

can you elaborate more on your usecase? If you have a scenario where most of your entities share the same "custom parameters" then the should rather use a common material. The ones that use different "custom paramters" would use another

@chillywillysoft
Copy link
Contributor Author

The generated meshes are mechanical belts stretched around pulleys. Each belt is of different length depending on position and radius of the pulleys. To have seamless texturing, the shader uses the length of the belt to adjust the texture scaling to have an integral number of repetitions of the texture. Different Materials will have a different inherent texture size and choose a different number of repetitions for a given belt length. Since the length is calculated while generating the Mesh and before the Entity is created and before a Material is selected, and since its a characteristic of the Mesh, I thought it most natural to associate it with the (Sub)Mesh.

image

@paroj
Copy link
Member

paroj commented Dec 2, 2025

I wonder if you could bake the length into the UV coordinates instead? I know the current trend favors flexibility, but Ogre functions best with the traditional distinction between vertex and uniform data.

In this architecture, custom parameters are intended for data that varies per instance rather than per mesh or material. A classic example is team color in a strategy game: the mesh and material are shared, but the specific color value depends on the player ID

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants