Vertex color (again)

Questions
#1

I would like to know where we are with vertex colour for sprites. Without vertex colours, every change to the tint of a sprite generates a new draw call.

Is it possible to use a mesh to implement sprites with vertex colours? I mean to replace the sprite component completely with a sprite-mesh component. You could always use the same square mesh with sides 1 and centred in 0 (so a position buffer shared by all sprite-mesh). There seem to be several key points here (as far as I understand it…): (1) updating from lua all vertex colours of all sprite-mesh could be very expensive (2) is it possible to reference a region of an atlas with a mesh?

Alternative. How complicated is it to implement a new sprite type with vertex colours via an extension?

Thank you!

1 Like
#2

The plan is to update our builtin sprite component with a color attribute.
It is not planned however, so ETA is unknown.
I’d guess we’ll do it sometime this year.

3 Likes
#3

Sounds great! Also, the alternative plan is https://github.com/defold/defold/issues/5393
@Pkeod mentioned once (we, too) that sprites need more attributes, not only a color. For example, a local position (not world) of a sprite to create visual effects. In this game, I adapted meshes as sprites for the dissolve effect.

3 Likes
#4

I forgot your feature request… and I voted for it already in the past…

But your “mesh as sprite” uses a single texture for each sprite, right? Or do you know how to access the sprites within an atlas?

2 Likes
#5

Thanks! Probably my new game will take more than one year… :slight_smile: So I hope to see color attribute before ending. Let me say that custom attributes as @aglitchman suggested is very very welcome!

2 Likes
#6

And If I can wildly dream: blend type for sprite is perfect for simulating lights via sprite without having to mess with renderer.

2 Likes
#7

Yes, you can:

  • Use any third-party texture packer, like Texture Packer, SpriteUV2, etc.

  • Load/parse the output from those texture packers at runtime or prepare at build time - it depends on your needs - and prepare buffers for meshes for each “sprite”.

  • Use material with the vertex space “World” to batch meshes as a single draw call as the engine does that for sprites.
    image

  • The performance will be almost the same as for the sprites.

2 Likes
#8

Thank you! Let me see if I understand correctly: You parse the atlas and create a 4-vertex buffer for each sprite in the atlas with the uv-coordinates. Is this right?

EDIT: can one parse the atlas generated by Defold?

The problem I see is that now it is quite hard to use the editor to create collections with this mesh-sprite. For example to build a character like in spine using go-es. Or is the editor capable of previewing the meshes… I haven’t tried this yet, sorry.

1 Like
#9

Yes. I parse the output (i.e. an atlas) of a third-party texture packing app, and create a vertex buffer for each sprite in the atlas.

Yes, the editor displays meshes!

I think it’s not possible. Defold packs atlases during build time, and developers can’t access raw data of compiled atlases files.

I can publish an example project of how we adapt SpriteUV2 to pack atlases for using meshes as sprites. But the example doesn’t support custom vertex colours, i.e. you will need to improve it by yourself.

2 Likes
#10

Yes, the example would be great!!! Thank you!

2 Likes
#11

I think we’ll do it in two steps.

  • First, we’ll add the color attribute to the sprite component
  • Secondly, we’ll add support for generic vertex formats for the sprites

I think the first task is a lot easier and take less time to complete, and at the same time be a big improvement to what we have.

8 Likes
#12

I studied your project issue_mesh_buf_change (the one you prepared for an old issue now fixed). I think I understand how to implement mesh-sprite.

However I am a bit scared about the management of the buffer resources. It seems to me that I have to explicit declare in a script the buffers I am going to use in a scene as go.properties… If it is so this is really complex for a real game while the atlas/texture resources are automatically managed by the engine.

There is something I am missing or I have misunderstood? I hope so…

EDIT: I think if I attach a mesh component to a go with a reference to a buffer then that buffer (as a resource) is automatically managed by the engine. But if I need to animate the sprite like a flipbook and the frames have different shapes then I need a buffer for each frame. So I need a reference to all these buffers somewhere (as go.properties). It seems to me that I have to use a go as a kind of atlas with a lot of properties for the buffers…
Okay, I hope what I wrote is not completely obscure… :slight_smile: