Perfomance issue loading multiple tiles

[barren knoll]

many materials cause issues with unity is what i heard
might just be rumors tho

[primal karma]

so more materials is better?

because that is exactly what im doing yet the setPass calls amount is quite high

[agile bone]

Different mesh with same material would batched and cause less draw call

[primal karma]

isnt that better?

[agile bone]

Yes

[primal karma]

mm any idea how can i easily create mutliple quads as seperate meshes for the texture atlas?

its just mainly tiles represented as quad meshes

i did create a script that would instantiate quads and change their uvs to fit their texture

[agile bone]

So you are doing texture atlas, maybe look for MaterialPropertyBlock

[primal karma]

but in frame debugger it shows me that it loads each of them separately

not as batch

[agile bone]

What does frame debugger say for reason

[primal karma]

this is mainly what i did

[primal karma]

one sec ill hcek again

[agile bone]

You have GPU instancing enabled for your material

[primal karma]

true

[agile bone]

Which requires to be same mesh

[primal karma]

oh i see

so its like a 3rd option of batching?

as its not dynamic nor static batching

[agile bone]

Yeah it's kind of .. batching for meshes

Again I think MaterialPropertyBlock is best fit for your requirement

[agile bone]

https://www.ronja-tutorials.com/post/048-material-property-blocks/

[primal karma]

i mean i used it for animated materials, but im not sure how i would use it in this case

in animated materials i mainly used the propertyblocks to change the texture without changing the material

[agile bone]

With offset/tiling
https://answers.unity.com/questions/767646/materialpropertyblock-main-texture-offset.html

[primal karma]

wouldnt changing the uv of the mesh do the same?

[agile bone]

yes but changing uv create different mesh

[primal karma]

which is what we want, no?

for mesh batching

[agile bone]

If you use MaterialPropertyBlock you can keep your mesh, gpu instancing, and use same material

[primal karma]

ok fair point, so then lastly, whats better?😅

dynamic or this mesh batching?

[agile bone]

Using single mesh, single material, setting offset/tiling with MaterialPropertyBlock

[primal karma]

alright then, ill try it out, thank you so much 😁

if you have any tips on improving performance, i would love to hear

[agile bone]

I think SpriteRenderer would do things for you

[primal karma]

true, but it cannot display normal maps

the game is mostly 3d

[agile bone]

It could if you extend their shader

Though you may need same work for normal map if it is also atlased

[primal karma]

interesting, but then its depth would not work in the 3d enviroment

[agile bone]

Why not?

The sorting order?

[primal karma]

as much as i played with sprites in 3d enviroments, it always displayed the sprites in a weird order

yes sorting

i can fix it wish simple command script

but then the last issue is how will it react to other light sources?

[agile bone]

Lighting is also up to shader

[primal karma]

wouldnt i just end up making regular standard shader?

[agile bone]

Yeah maybe, lol

[primal karma]

mainly what seriously killed my performance is the second cam

i use it for water reflection

[agile bone]

With stencil buffer?

[primal karma]

so now im searching every way to boost performance while maintaining with water reflection

stencil? mm no i dont think so

its just upside down camera and render texture

[agile bone]

Hmm I see can't you just bake them and make fake reflection lol

There may be lot of room for optimization

[primal karma]

thats another issue, the levels are randomly generated

so i cannot bake anything

therefore occlusion also does not work

so i made my own sort of occlusion

[agile bone]

Reflection probe kinda thing

With PBR

[primal karma]

yeah reflection probe requires baking no? never used it

[agile bone]

There is realtime one

[primal karma]

from what i heard its much heavier

but i dont mind trying

im using legacy built-in pipeline

[agile bone]

I see , isn't it still PBR?

[primal karma]

i guess so, yeah

[agile bone]

You can manually refresh Realtime probe when you want, then it's basically baking

[primal karma]

if its less time than Camera.render, that would be great

[agile bone]

Hopefully. You can try.. 😄

[primal karma]

that i will, regardless, thank you very much 😁

as i expected, realtime reflection probes require for the scene to be static 😅 well it was worth trying

[agile bone]

https://docs.unity3d.com/Manual/class-ReflectionProbe.html
You have option

Actually it's Custom with Dynamic Objects

🤔

Nvm, they may be not work dynamically

[primal karma]

apparently its also not a solution...

[agile bone]

If you are using [PerRendererData] it should work, which shader and properties are you using?

[primal karma]

unity's standard shader

i need to make custom shader?

alright i have the custom shader, where do i insert [PerRendererData] for material offset?

[agile bone]

On the texture 🤔 you are using texture atlas right?

[primal karma]

like this?

because it doesnt work 😅

[agile bone]

https://www.ronja-tutorials.com/post/048-material-property-blocks/

If you can show the code how are you setting MPB might help

[agile bone]

Oh you should put PerRendererData for other properties you are using

Why on OnValidate, though?

[primal karma]

to check it in editor

[primal karma]

i commented the other ones out while i was testing the offest

[primal karma]

ok wow it asks me to completely modify the shader and i have little to no knowledge in shader scripts.. how do i turn standard shader into instantiable standard shader?

the example you've sent only explains how to change colors with MPB, but nothing is written on every other aspect of the shader, no mainTex or metallic or normal map

[agile bone]

I mean PerRendererData and MaterialPropertyBlock should already helping your performance
Also standard shader supports GPU instancing by default 🤔

You should add the part starting with UNITY_INSTANCING_BUFFER_START
https://docs.unity3d.com/Manual/gpu-instancing-shader.html

[primal karma]

in frame debuffer it keeps showing this and it loads each tile on a seperate call

[agile bone]

I see. You need the part starting UNITY_INSTANCING_BUFFER_START with it

[primal karma]

where exactly to i write it?😅

[agile bone]

If you see the API doc I sent you it's this part

UNITY_INSTANCING_BUFFER_START(Props)
    UNITY_DEFINE_INSTANCED_PROP(float4, _Color)
UNITY_INSTANCING_BUFFER_END(Props)

Umm you can see it from doc it's like same level as vert and frag

[primal karma]

alright, but this part is related specifically to _color change, where as i change material offset and tilling. not color

[agile bone]

I know, so it should be UNITY_DEFINE_INSTANCED_PROP(float4, _MainTex_ST)

And other stuffs

[primal karma]

oh.. so its that simple?

alright ill try it but the next question, on which pass do i add it to?

the standard shader seems to have multiple

[agile bone]

And when the access those variable, you need to replace it with UNITY_ACCESS_INSTANCED_PROP

[primal karma]

how do i know where it accesses that material?

i can show you the shader if it helps

in the shader script there is no place where it mentions _MainTex_ST

[agile bone]

Maybe defining surface shader like the sample yourself could be easier... 🤔

[primal karma]

it poses the same challange, i have no clue how to add normal and occlusion maps 😅

i mainly only need the offset and tiling

[agile bone]

That is not that hard with surface shader. All you do is sampling texture and setting to SurfaceOutputStandard member

[primal karma]

for you it might seem simple, for me i have no clue where to even begin, i have no experience with shader scripts at all

[agile bone]

Let me see if I can write one for you

[primal karma]

i would really appriciate it, thank you so much 😁

[agile bone]

You can test it out

[primal karma]

oh my god you are amazing!

i wont lie i was scaptical that it would work after trying everything i could find to batch tiles in the game, but it does work

again, thank you so so much, i truly appreciate it 😁

now only to understand how to let it also scale normal maps and occlusion 😅

[agile bone]

Yeah that part, you can see the shader I calculated main_uv separately
Easy way is replacing uv_OcclusionMap and uv_BumpMap with main_uv
That is assuming all your textures(diffuse/normal/occul) are sharing same coords

[primal karma]

yep they are the exact same texture but turned into normal and occlusion

[agile bone]

Then simply replacing them with main_uv should work, you can remove uv_BumpMap and uv_OcclusionMap in Input as they won't be used

[primal karma]

so replace everything after UNITY_INSTANCING_BUFFER_START(Props)?

[agile bone]

uv_OcclusionMap and uv_BumpMap are only used in surf function

[primal karma]

yup this does the trick, thanks again 😁

[agile bone]

Yay

[primal karma]

it seems i wont be able to escape from learning to code shaders 😅

[agile bone]

Eventually you will have to deal with shader 😂
The real question is : did it help with your game's performance?

[primal karma]

yess, it batches them together, loads them all in two calls which is incredible

not sure why but its two calls, first it loads everything close enough, and then the rest, ill have to check whats the reason behind that

[agile bone]

Sounds good enough 😄

[primal karma]

im shocked to find out there is little to no explenation or guides on batchable materials as the one you did, trust me i searched everywhere

maybe i wrote it wrong as i was searching, not sure if there is a correct naming for this

[agile bone]

Maybe ppl are just using URP/HDRP with shader graph and SRP batcher
It's called GPU instancing

[primal karma]

oh another question, how do i change normal map strength? everything else does allow me to change except for the normal strength

[agile bone]

Oh I forgot to implement that didn't I lol

[primal karma]

i do wander if there is any benefit in using built in pipeline or im just wasting my time

in terms of performance

bumpmap *= UNITY_ACCESS_INSTANCED_PROP(Props, _BumpScale); something like this?

oh wait theres another part

wait let me try it

[agile bone]

o.Normal = UnpackNormalWithScale(tex2D(_BumpMap, IN.uv_BumpMap), UNITY_ACCESS_INSTANCED_PROP(Props, _BumpScale));

I think this is correct way to do it

[primal karma]

like this?
half normals = tex2D(_BumpMap, IN.main_uv).g; normals *= UNITY_ACCESS_INSTANCED_PROP(Props, _BumpScale);

[agile bone]

Scaling normal needs some calculation, UnpackNormalWithScale would handle it

[primal karma]

i see, well it was worth a try 😅

does it matter after what line i enter it?

oh nvm, its suppose to replace the existing one

[agile bone]

Yes

The syntax is similar to C language

[primal karma]

yes now its perfect! thank you once again 😁

[agile bone]

Yay 😄

[primal karma]

oh wait.. now its on different calls 😅 , maybe its because of the normal scale

[agile bone]

Actually did you replace it to main_uv lol I write the code based on mine

[primal karma]

yup

wait im trying to see if its something that i did

huh ok yeah its something that i did

apparently when you add additional light source, it cancels the batched call for the affected tiles

[agile bone]

Ah lighting yes, it breaks some batch

[primal karma]

well, it shouldn't cause too much trouble i assume when the whole tile map is batched in one call

[agile bone]

Dynamic lighting is always expensive but yeah you should be fine if light source are not everywhere

[agile bone]

You might want to look into deferred rendering for this

If you use many dynamic lights

[primal karma]

yeah i did check about it and forward suits better for my design 😅