Color option for MeshBuilder.CreateSphere?

I wonder if MeshBuilder.CreateSphere could have a color option to set the color attribute of its vertices to? Or maybe named faceColor to be more consistent with the other Create functions? Let me know if a PR sounds good and I’ll work one up for it. :slight_smile:

1 Like

Not quite sure what you are wanting to achieve.

You can set the color attributes of the vertices using Updating Vertices | Babylon.js Documentation

However because of shared normals you will get graduated colours across the facet triangles as in from the above docs page.

This also means you cannot have adjacent facet triangles of different colours unless you convert the sphere to a flat shaded mesh and so unless you do this a faceColors option would not work.


I mean setting all of the vertices to the same color, as an easier alternative to manually building the array and calling setVerticesData, by simply passing a Color3 object in the options to MeshBuilder.CreateSphere. :slightly_smiling_face:

So for instance you could do like below to quickly create a red sphere:

var sphere = BABYLON.MeshBuilder.CreateSphere("sphere", {diameter:2, color: BABYLON.Color3.Red()}, scene);

It could be useful for prototyping, debugging, and creating quick playground examples I think.

If the info in the buffer are all similar, why creating it in the first place ? instead of relying on materials ?


Because it would be easier and faster to just pass the color in the options than to write a few more lines of code making the material and setting its color. It doesn’t sound useful to others though so I’ll just make a helper function to use as wanted. :+1: :beers:

1 Like

In general for recoloring a mesh it might be better to use a material rather than vertex color data. Maybe you could make a helper function ColorMesh(mesh, color) which would generate a standard material with diffuseColor :slight_smile:


I would add a flag to define Standard or PBR material: ColorMesh(mesh, color, boolean) to generate for the mesh a standard material with diffuse color or PBR material with albedo color.


I ended up just supporting StandardMaterial for now in a little helper function. My goal was just to be able to quickly get different colored meshes on the screen for prototyping and debugging, in one line of code, but I ended up making the helper function more versatile, since it was just as easy to implement. So any property of the created standard material can be specified, not just the diffuseColor. I still might make createSpheres and createBox functions too thou, to create the mesh and material in one line of code. :beers:

1 Like

This is a nice API! I like it a lot. I am also lazy and don’t like typing out multiple statements for every material I create :stuck_out_tongue:

@sebavan thoughts on letting you optionally specify material properties in the constructor? Like:
new StandardMaterial('name', {diffuseTexture: new Texture('...')}, scene);

1 Like

Would checking if the second parameter is of type scene work for maintaining backward compatibility? I guess passing options as the last parameter would make backward compatibility simpler but passing the scene at the end is more like existing functions so better I think…

Let me know if it sounds good either way and I’ll work up a PR for it (with support for all of StandardMaterial’s public properties?). I might need help with the backward compatibility part though if it turns out to be more complicated than expected. :slightly_smiling_face:

LOL I’m all about the lazy single statements too, especially when just debugging or prototyping. :beers:

I am not sure about adding this one tbh as complexifying the API for this one as we had more checks and such in the code.

A separate helper is fine but not by changing the material or mesh constructors.

@Deltakosh any thoughts ?

1 Like

I agree. We should not complexify the constructors

Something like this then?

StandardMaterial.Create(‘name’, {diffuseTexture: new Texture(’…’)}, scene);

yep! that looks good

But I wonder if it is worth the cost? What do we really get as a simplification?


The benefit I think is just less code to write and can do little one liners for quick prototyping/debugging. For example little playground repos/examples could set meshes to diff colors easier without bloating the code as much, for keeping track of the meshes better.

IDK if it’s worth the tradeoff of bloating the Babylon codebase to make the user code smaller thou, and so far I think only @DarraghBurke and I are finding it useful, so maybe should hold off on this one and see if more interest develops… :slightly_smiling_face:

1 Like

thing is:

const mat = StandardMaterial.Create(‘name’, {diffuseTexture: new Texture(’…’)}, scene);


const mat = new StandardMaterial(‘name’, scene);
mat.diffuseTexture = new Texture(’…’);

which is about the same number of characters but I personally find the second one more readable.

I love this thread by the way cause it hightlights an API gap :slight_smile:

1 Like