@jerome any thoughts on this?
Not sure to understand : the particle colors are the vertex colors.Do you mean setting the particle vertex colors when setting the particle vertices ?
https://doc.babylonjs.com/how_to/solid_particles#update-each-particle-shape
This should be doable…
Yes! That’s what I’m talking about. Apologies for the unclear description.
@jerome, should I attempt the code change?
I’ll do it.
Because of the Covid, I’m at home without my dev computer. I’ll try to install a dev platform on the laptop at home, but I can’t do it before a week or two.
Thanks @jerome !!!
Hi Babylonians,
As you may know, you can update each solid particle vertex by enabling the property computeParticleVertex in a SPS.
https://doc.babylonjs.com/how_to/solid_particles#update-each-particle-shape
Currently the passed parameter is a Vector3 called “vertex”, so you can only update the vertex coordinates x, y and z.
I’m about to implement the possibility to update also the vertex color and UV.
Please let me know which one of both following options you prefer :
- a little breaking change but more consistency, so the vector3 vertex would become an object like this
vertex.position: Vector3 (x, y, z)
vertex.color: Color4 (r, g, b, a)
vertex.uv: Vector2 (x, y)
and each property would be then updatable in the function updateParticleVertex() even by using the native Vector3, Vector2 and Color4 methods
OR
- no breaking change at all (*), but some addition to the vertex object (no more a Vector3 then)
// position
vertex.x
vertex.y
vertex.z
// color
vertex.r
vertex.g
vertex.b
vertex.a
// UV
vertex.u
vertex.v
I prefer the first option but I’ll implement your choice.
(*) in JS. TS would probably complain about this change anyway.
The first option makes the most sense to me and would it be then possible (wise) to preserve backwards compatibility by setting vertex.x = vertex.position.x, vertex.y = vertex.position.y, vertex.z = vertex.position.z as and when vertex.position is created and updated and vice versa?
1 Like
The best way would be to implement some getters/setters for each former property, I suppose.
1 Like
My vote goes for first option as well.
1 Like
I’m against ALL breaking changes so I need to understand the impact. How many demos / PG will be broken?
1 Like
Its 2 PG in the documentation only.
I think this feature wasn"t used until now (except by me 
)
And I think I can keep the current behavior with getter/setters probably. Not sure
I’ll make a test of this implementation and let you know if I’m able to keep the current behavior with getters/setters
1 Like
Working on it.
The feature seems actually quite interesting and versatile for many use case, imho.
[EDIT] and backward compatibilty saved for the existing user code 
What are the changes you are making going to allow that you can’t already do with your system?
This must be a very specific use if you are looking to update the vertices of the solid particle. I guess that makes sense if you are doing like a bunch of like squishy balls or something. Hmm, that’s an idea now. Ammo softbodies attached to a sps system, that might actually be fun.
I know in the past I was able to animate the particles by shifting the uv and had really no problems with that, isn’t this all the same stuff?
I’m just trying to catch up with what it’s really being proposed because I love the SPS system now that I have been using it.
1 Like
The change is just the ability to update the particle vertex color and uv as well as the position from the method sps.updateParticleVertex(particle, vertex, number). Not that many people use this actually.
Until now only the position was updatable. Now you can, for instance, change the color of only one box face at will, or the way it’s textured (uv).
PG and documentation coming soon.
The SPS can also be seen as some API now to “edit/update” a mesh (single particle or digested mesh) without handling the vertex data stuff.
https://playground.babylonjs.com/#CMS27E#8
I thought you could already do that? I am shifting each particles UV with its own timing offset in this example over a strip Sprite animation.
the cool part about that it it’s like three times animated, the texture is a dynamic texture with a 3d noise being applied over the cells for a “power effect” then they are animated over a sprite sheet, and then the particle is animated. Kinda cool and that’s when I fell in love with your system.
1 Like
yes
and now you’ll be able to shift the UV (or to set the color) also at the particle vertex level, not only for the whole particle.
AHHHHH gotcha so per vertex instead of per particle.
Cool, so I was right you could do like 20 sphere particles and give them all an ammo softbody but have the whole thing updating on one draw call.
Totally think I get it now.
Sounds cool!
This feature is going to be amazing!