And why is that? You could have the possibility to set vertex attributes for sprites as well to be used for tinting (or other things) in the sprite shader as well.
Or do you use them internally for something?
Could you post your overdraw shaders?
If we could get the ability to set tinting / alpha with sprites in a way which didn’t break batching it would be super great.
The answer to that is customizable vertex formats, which I think is on our roadmap for this second half of this year. (@britzl knows more)
agree,
sprite tinting is required to create a retro lighting like the old X-Com, for example:
Yeah, it’s in our roadmap. Not sure when we’ll tackle it, but if I’m guessing it’s somewhere in December or January.
Hi! When are you planning on fixing the issue(batching tint and other)?
We mentioned custom vertex formats in our most recent Roadmap Post. We’re slightly behind in terms of what we had hoped to deliver by now due to in part some stability issues during the autumn and in part because of internal needs that was given higher priority. The roadmap post is still accurate, but I will post an update in beginning of January with some updates.
any news?
News on custom vertex formats or on the roadmap (there was a new roadmap post made in January as promised)?
News about this:
as I understood “custom vertex formats” solve this.
I’d like to hear some clarifications on this amazing post, namely if and how the situation changes when using custom render predicates / materials / shaders, since if I understand it correctly, this guide assumes that the builtins are used everywhere.
Would different component types break batching if they were to use the same material? Or different materials but the same rendering predicate?
Do different materials break batching by themselves, or is it ultimately because they use different shaders?
Tint is explicitly said to break batching (as long as the values are not the same), but I assume this goes for any other custom constant I might be using, right?
Does this apply only to fragment shaders, or do different vertex shader constant values also break batching?
Thanks for any insight you can give me.
The batch rules are documented here:
Ah, interesting. I didn’t realize the z level comes into play like it sort-of does in gui, but there it can be solved by layers.
So a tinted sprite on z level 0 will prevent batching of non-tinted sprites on levels 0.5 and -0.5, right?
I think I can save some draw calls in my current project when rendering a light map - I can group lights with the same tint on the same z level and put all the ones using other variable shader constants “aside” so they don’t break anything.
Thanks!
Also we can set few lights sources as constant_buffer for whole predicate (‘tile’ for example) and then calculate light intensity in the sprite/other component shader.
Or render lights into texture in renderscript and use it as lightmap texture in sprite shader, calculating tinting on sprite position within lightmap. So, this way prevents from setting tint to each sprites.
One part is still not clear to me - Why does the difference in shader constants break batching?
One part is still not clear to me - Why does the difference in shader constants break batching?
We need to send the shader constants (uniforms) before each draw call.
(Yes, there are uniform buffers, but we also still support older OpenGL versions. And uniform buffers don’t exist in OpenGLES)
It makes sense now. Thanks a lot