#NSprites + BatchRenderGroup Sorting?

1 messages · Page 1 of 1 (latest)

slim patio
#

@delicate epoch (I hope you don't mind the direct ping, but a few items for you) or anyone who can help.

Firstly some general NSprites-Foundations feedback:

  • The Material on Sprite Renderer Authoring component is regularly set back to Missing after playing for some reason. I haven't had a chance to look into why this might be.
  • The RegularSprite Shader provided by Foundations requires certain URP settings. This is probably a safe assumption, but I was using the 2D URP Template (which isn't really supported) which the Shader doesn't work with it. The lack of errors was confusing until I dove into the shader and saw some required features/tags.

My main current issue: Sorting.

I'm using BatchRendererGroups for my terrain. While my setup is custom, my OnPerformCulling (where the draw commands are created) is very similar to the base example: https://docs.unity3d.com/2022.2/Documentation/Manual/batch-renderer-group-creating-draw-commands.html
From what I gather, NSprites is making a Graphics.DrawMeshInstancedProcedural call within the SpriteRenderingSystem, yeah?

From what I see with respect to Sort Order / Sort Layer stuff, I'm starting to assume that sorting is only within the draw specific draw calls? Is it possible to sort across my BRG and NSprites Sprite Rendering? Is it possible to do my Terrain Drawing first? I don't see any controls when setting up my BRG, and the sorting options on the BatchCullingOutput seem related to that draw pass only?

General shader question: Do shader passes control draw order? Maybe my shader (which I hacked together) could be modified to render first so sprites are drawn on top of it?

delicate epoch
#

Hi @slim patio !

I hope you don't mind the direct ping, but a few items for you) or anyone who can help
not at all 🙂

The Material on Sprite Renderer Authoring component is regularly set back to Missing after playing for some reason. I haven't had a chance to look into why this might be.
Have the same issue. My main guess is that it’s unity’s serialization mess in 2022.2 version. But I will look closely.

The RegularSprite Shader provided by Foundations requires certain URP settings. This is probably a safe assumption, but I was using the 2D URP Template (which isn't really supported) which the Shader doesn't work with it. The lack of errors was confusing until I dove into the shader and saw some required features/tags.
You switched to regular URP from 2D one or solve this issue without switching?

From what I gather, NSprites is making a Graphics.DrawMeshInstancedProcedural call within the SpriteRenderingSystem, yeah?
Yep

From what I see with respect to Sort Order / Sort Layer stuff, I'm starting to assume that sorting is only within the draw specific draw calls?
In foundation sorting implemented on shader side, where we change SV_POSITION z value. In such way sprites from different drawcalls should also be sorted.

Is it possible to sort across my BRG and NSprites Sprite Rendering?
I’m not sure how BRG works, so I can’t tell. But if you will use same sorting technique in your shader (which you use with BRG) then maybe sorting will performed right.
Anyway this kind of sorting is for 2D stuff only. Does your terrain 3D or 2D?

Do shader passes control draw order? Maybe my shader (which I hacked together) could be modified to render first so sprites are drawn on top of it?
Shaders have render queue value and AFAIK higher the value - lately it will be drawn. Maybe this can help?

slim patio
#

Thank! I'm on my phone so this is an incomplete response:

Yes I was able to solve it by switching my URP setup (I basically copied what you have in the Rome sample and then modified it to be compliant with BRG).

Thanks for the sort order details, I'll take a closer look at my shader and your shader and see what I can do about adjusting the ordering.

My terrain is 2d. Biome/tile based in a sense, but not using entities for each tile, and not using small repeatable textures or dedicated border rules. Using large textures that spans larger sections of the world with shader control over which texture to pull from and how to blend the borders.

slim patio
#

Sweet, I was able to get a quick fix by setting my SV_POSITION.z to 0. This should unblock me for now! Though I will probably look into the missing material situation also if that keeps happening. I wonder if it's anything to do with the abstract class, the fact that the RenderData is a nested serializable struct, and/or the fact that the RenderData isn't actually pulled off of the Authoring within the baker.

I'm just happy to have this working!

Screenshot attached (grass, sand, and water textures are placeholders)

image.png
delicate epoch
#

Sweet, I was able to get a quick fix by setting my SV_POSITION.z to 0. This should unblock me for now!
Nice to hear!

I wonder if it's anything to do with the abstract class, the fact that the RenderData is a nested serializable struct
Never be a problem as I know

and/or the fact that the RenderData isn't actually pulled off of the Authoring within the baker
What you mean "pulled off" ? The fact that material actually generated during baking process?

slim patio
#

What you mean "pulled off" ? The fact that material actually generated during baking process?

For most things you access the serialized fields like I'm used to:

authoring._sprite

https://github.com/Antoshidza/NSprites-Foundation/blob/ee32c1e850f39373caf375717b1c15dd82052e3e/Base/Authoring/SpriteRendererAuthoring.cs#L20

But for the material, you directly access it without going through the authoring reference of your Mono:

_spriteRenderData.Material

https://github.com/Antoshidza/NSprites-Foundation/blob/ee32c1e850f39373caf375717b1c15dd82052e3e/Base/Authoring/SpriteRendererAuthoring.cs#L129

IMO, the fact that the material is being Set seems like a possible problem area:

_spriteRenderData.Material = GetOrCreateOverridedMaterial(_sprite.texture);

https://github.com/Antoshidza/NSprites-Foundation/blob/ee32c1e850f39373caf375717b1c15dd82052e3e/Base/Authoring/SpriteRendererAuthoring.cs#L140

BUT, I am still very much a noob at this. I assume that because there is a specific Baker flow that means we have to access attributes from the Mono via the provided reference to the Authoring Mono rather than directly access/set those fields from within the Baker which you nest within the Mono.

delicate epoch
#

@slim patio actually you referenced problem place and I've found why this happened

#

I'm overriding SO's Material field while generating material

slim patio
#

@delicate epoch I think I fixed the Material issue by changing the Getter to this:

protected override SpriteRenderData RenderData
{
    get {
        if (_overrideSpriteTexture && _sprite != null) {
            return new SpriteRenderData {
                Material = GetOrCreateOverridedMaterial(_sprite.texture),
                PropertiesSet = _spriteRenderData.PropertiesSet,
            };
        }

        return _spriteRenderData;
    }
}
delicate epoch
slim patio
delicate epoch