Opacity of an instanced mesh

Questions
1

Hi,

I am instantiating a bunch of spheres like this:

`
const instanceCount = 50;

for (var index = 0; index < instanceCount - 1; index++) {
    let instance        = sphere1.createInstance("sphereInstance" + index);
    instance.position.x = 26.05 - Math.random() * 52.1;
    instance.position.y = 14.55 - Math.random() * 29.1;
    let s = Math.random()  + 1;
    instance.scaling = new BABYLON.Vector3(s,s,1);
}`

But I also would like to randomize their opacity.
I’ve seen two ways to do this:

  1. use mesh.visibility.
    The problem is, it doesn’t work with instantiated meshes
    (BJS - [22:34:00]: Setting visibility on an instanced mesh has no effect)

  2. use material.alpha
    The problem is that when I instantiate my spheres, the material is already applied to the original sphere, before the loop.

So, how can I achieve that?

Here is a playground with the code:

Thanks.

2

Instances don´t support different materials as they use that of the main mesh
It all depends on the complexity of the project you want to develop

  • One option that I assume you have considered is to use clone.
    Note that using clone simply creates a deep copy of the original mesh and saves memory by sharing the geometry.

  • Other option is SolidParticleSystem (SPS), maybe this is a good choice for your case. Here you´ve a nice Playground:

And also check the Documentation

2 Likes
3

Thanks for this.
I used instances because I read that this is the way to go if you want each replica to be a unique object.
My end goal (when I get more confortable with Babylon, as I’m just discovering it) is to get each element to be a unique cell, with its own “genome”, doing its own thing. And by the end of the animation, I will vet the performance of each in doing a specific task. Their replication later on will depend on how well they each performed a task. So I will need to be able to query each one of them eventually.
As such, they clearly have to be their own thing while sharing some graphical similarities.
Making them all unique would be graphically costly but making them all clones or part of a particule system might prevent them from being somehow unique, AFAIK.
Knowing that, do you think one of the other options would still be the way to go ?

As I said, I’m just discovering the library here. But the visual put aside, I would have created a “cell” class and a few inheriting subclasses and then instantiated objects from those.
I would have liked to have about the same thing graphically : a “cell” Mesh corresponding to the “cell” class with specific graphical attributes attached to the subclasses (different sizes, opacities, colors, etc… according to the type of cell).
So that each cell is eventually unique but still, baked from a shared pool of graphical and logical molds.
That would be:

  1. easier to manage
  2. more economical in terms of resources.

So I thought that instances was the best pick. But I’m really not sure.

Thanks for your help.

1 Like
4

Of course, for performance instances are the best method but they´ve their limitations and from what I see you will need to modify different attributes.

In such a case, as you comment at the end, the idea may be to create a series of master spheres with the defined attributes and later you will be able to instantiate those elements always considering that you cannot modify the material or the mesh itself.

You could also do a stress test using clones to see the behavior of your application, see the DrawCalls, FPS performance or test it on old mobile devices.

I hope it has been helpful

1 Like
5

You can use the vertex color to have a different alpha per instance:

If all (or most) of the cells will be visible on the screen, you may want to consider using thin instances rather than instantiated meshes, as they perform better. You can have some degree of variability for each cell with custom buffers.

2 Likes