Shading sprites based on sprite Y

That would be neat to try for some effects but for general purpose shaders you want to be able to use alpha.

I don’t know of a real solution, but maybe we could get a new sprite component / a checkbox that gives more freedom with those sprites but doesn’t work in batching.

1 Like

Maybe you may use two sprites: one with the normal sprite and another one with just the alpha to draw the fill of the sprite and the Y coordinate baked in the red channel. Of course this costs you two sprites.

If your effect is some kind of add-a-color or multiply-by-a-color then this should work.

1 Like

That certainly would be useful for some types of effects.

What I’m wanting to make right now is a top down dissolve of a sprite.

1 Like

Of course the local uv coordinate in the material is the right solution. Maybe it is not hard to add it to the engine. (I would guess so)

1 Like

What you want is not possible with the 2-sprites solution… You really need the local uv-coordinates.

1 Like

Local uv-coordinates or, better, multitexture for sprite.

1 Like

Does your sprite rotate? If not then you may pass the center position as a user-data constant and compute the local uv. But this breaks the batching of the sprites…

I am sorry for the multiple answers, I am looking for some solution and writing as I think :slight_smile:

2 Likes

If not then you may pass the center position as a user-data constant and compute the local uv.

I don’t know if this is possible because of the way atlases are composed and the lack of access to that info at runtime?

No, I mean the central position of the sprite on screen, not the central uv.

If the sprite does NOT rotate then you may compute the local uv from the vertex position

1 Like

If you can, please share an example of doing that!

Tomorrow I will write the shader for sure. Now going to sleep… :slight_smile:

1 Like
  1. Hopefully, in the future we have the ability to let the user set the vertex formatfor sprites (and others), just like they can do with meshes.
    I don’t think we’ll add an extra set of uv’s as default though, since most users don’t need it.

  2. This was something we said “we’ll add it later if it’s needed”, when introducing the notion of local space coordinates. The reason for that is that it will break the batching and create a unique drawcall for each such sprite. Probably not what you want here either.

  3. Since iOS is supporting Metal now (via our VUlkan backend) and the number of OpenGLES2 on Android is down to 10% (link) we’re looking into updating to OpenGLES 3.
    This, for instance, would allow you to use e.g. gl_VertexID to figure out your local uvs (if you’ve turned off sprite trimming so each sprite is 4 vertices).

Between these, I’d say the #3 is pretty close on the horizon and we’ll start working on it this spring.

9 Likes

What would happen to the web target? I seem to remember that GLES3 works only with Webgl2, which doesn’t work too well in mobile browser especially.

It’s part of what needs to be decided in the design phase.
But in short, you cannot have both OpenGLES 2 and 3 features in the same shader and expect it to work. You will have to make an active choice of what platforms you support.
E.g. you could opt to support WebGL2, but then only a few browsers would support it.

Here you have the shader for Y-based fade for sprite in atlas.

Some remarks:

  1. the vertex shader needs some constants: translation, rotation (euler.z in radians) and scale (x/y).
  2. Of course this approach is problematic for batching…
  3. The main.script in the attached example DOES NOTHING to optimize the use of the shader: I call go.get_world_position / scale in update.
  4. I have not (extensively) tested the shader!!!

The idea for the shader is very (too) simple: give it the data needed to recompute the local xy coordinates from the world-coordinates. Only this!

sprite_shader.zip (909.8 KB)

4 Likes

That’s fair enough Mathias. Thanks you.

Thank you for sharing. Here is a modified version with more logos bouncing around with the directions randomized and changing over time.

sprite_shader.zip (90.2 KB)

I’ll try to adapt this to other situations soon. For some special effects, having extra draw calls is fine. They can be disabled / swapped to less expensive ones at runtime now anyway. I’ll do a test with dynamically setting material of a sprite to reduce draw calls when not using the special batch breaking special effects.

3 Likes

https://caniuse.com/webgl2

75.83% global usage

Seems it may be coming to iOS Safari and that’s a large %. The other large % is IE which doesn’t actually matter.

If you don’t use scaling / rotation then you may write a specialized version: you have a lighter shader and less data to pass. But I am sure this was already clear to you.

Ciao!

2 Likes

Until other options are available, I may provide 2 versions of sprite shaders one with scale/rotation and one without.

2 Likes