Hello,
Thanks for all the improvements. I have a question.
Are you basically saying that tessellation will now run fastest on the largest landscape size? (largest size being 8129x8129
Hello,
Thanks for all the improvements. I have a question.
Are you basically saying that tessellation will now run fastest on the largest landscape size? (largest size being 8129x8129
Not sure if I’m missing something.
With these settings the maximum size I get is 8x8km. Total resolution is 8161x8161 to be specific, which means 8161x8161 meters.
Sounds awesome! Will there be any way to increase terrain resolution independent of component size/number of components? For example, let’s say I want 4 vertex per meter resolution in LOD 0 for my terrain. Right now the only way to do that is to increase the number of components, which just leads to a ton of overhead
Hmm maybe you’re right, i was assuming 16x16 because i’m currently converting LandscapeMountains for my testing and at 255x255x2 i’m at 16kmx16km.
No, the underlying mechanic of how landscape are built wasn’t touched at all, only the rendering aspect of it.
Got some issues with tessellation and shadowing, I have posted some images for you on the 4.19 preview thread here:
https://forums.unrealengine.com/unreal-engine/announcements-and-releases/1413780-unreal-engine-4-19-preview?p=1414902#post1414902
Thank you very much for working on this, we really appreciate it.
Hi @
Can you try not using the VertexNormalWs, i think i saw a jira on my side talking about issue and this.
Also, i know you haven’t seen the release note yet, so you probably don’t exactly know what changes and how it work.
I’ll try to repro locally and see how it goes, but in theory it should work as before, as shadow were not affected in this phase, only rendering optim, LOD distribution changes,more options to control tessellation, etc. The shadow specific one will come for 4.20 as i couldn’t finish it in time for the 4.19 deadline.
In any case i would guess if you push the tess multiplier and compare with 4.18 you should see major gains.
@Michel.Dupuis tried without VertexNormal node but still as soon as landscape is deselected these black spots appear.
http://uupload.ir/files/ytkd_512.jpg
If I skip these couple nodes and don’t push dark values downwards then it looks fine.
http://uupload.ir/files/etb_5122.jpg
But pushing dark values downwards and white values upwards is necessary otherwise entire surface just goes upwards and too much clips with player and other assets.
@ Hmm im wondering if what you’re seeing is simply not the difference in shadow in tessellation handling between dynamic rendering code path and the static code path.
i.e in Editor if the landscape is selected you will see it rendered in dynamic code path, otherwise by default it’s static.
Can you try to use console command without having the landscape selected in the editor, and see if it change something(i.e if you see the same issue then when selecting the landscape)?
Landscape.Static 0 ← Disable static rendering
Landscape.Static 1 ← Enable static rendering
If you don’t know to enter console command while in the Editor simply open the Output Window, then at the bottom of this window you can type console command there.
Let me know if it change something!
@Michel.Dupuis I gave those commands a try, they toggle the issue regardless of which one I enter. For example if I set it to 1 it looks fine then, but if I re-enter it with same 1 value issue is back.
But I got something for you, I’m going to post my results step by step and I’ve wrote descriptions on the right side of images.
http://uupload.ir/files/fxe_1.jpg
http://uupload.ir/files/is5o_2.jpg
http://uupload.ir/files/6grn_4.jpg
http://uupload.ir/files/rc_5.jpg
So basically if we want it to look fine we must keep the settings only like that. We can live with it for now until the issue is solved and we can try different settings.
Just out of curiosity, are you aware of CSM blocky shadowing on smooth surfaces, affecting landscape surfaces?
You can see it in my last image here (this issue is not related to tessellation issues, it’s been there since the start):
http://uupload.ir/files/kr3v_6.jpg
https://i.imgur.com/Ok2CFVj.jpg
Thank you for your time.
@
Thanks for the test and clarification, i’ll look into it. As for the Shadow blocky effect, it’s due to something else that was changed, it should affect everything, not only landscape, and i don’t know if it will be fixed for 4.19. (Hopefully )
@Michel.Dupuis Loving how the new LOD system works. Shapes hold up much better it’s great!
And yes that blockyness is visible on everything. I was just trying to find out if this issue is known to you because the thread about this went on for 13 pages but nobody from Epic replied yet neither on thread nor on answer hub reports so we really don’t know if anyone at Epic is aware of this and has it somewhere on a long term to-do list.
And one last thing.
Sometimes when I create a new landscape for testing I see LOD 0 has unequal triangle sizes.
https://i.imgur.com/uS8IP1V.jpg
That’s without having tessellation enabled.
And it wasn’t doing this before? This is simply the morphing applied to LOD that was being done before too. I’ll validate if it’s something new, in any case it’s not having any more impact than before on perf, or anything. The only thing i could think of, is that maybe you weren’t seeing it in wireframe mode before.
The issue seems to appear only on specific parts where LOD 0 transition to LOD 1 happens. I’m going to zoom in on these two spots:
http://uupload.ir/files/mrd4_1.jpg
Red spot from close up looks fine:
http://uupload.ir/files/ojjf_2.jpg
Blue spot from close up looks uneven:
http://uupload.ir/files/xnob_3.jpg
In 4.18 and before, blue spot starts to look just like red spot when approached.
In 4.19 this uneven-ness (new word?) in triangle size makes some tris become way denser than others when tessellation is enabled.
@Michel.Dupuis
Finally got my hands on 4.19 preview.
Firstly, let me thank You for implementing separate LOD falloff curve for LOD0 and other LODs and especially for allowing to cap tessellation rendering to a certain shadow cascade. Essentially that seems to fix all undue shadow rendering costs for landscape tess.
As @ reported, you get different results with landscape selected and unselected in the editor. Setting Landscape.Static 0 removes discrepancy between selected and unselected landscape, but also makes landscape tess settings have no effect… With Landscape.Static 1, everything works fine, when the landscape is not selected.
@ regarding the shadow artifacts, you have shown on the screenshots, they should only appear in regions, which are located in shadow splits, which already have tess disabled through Restrict Tessellation option, but where displacement in your material is non-zero.
Here is example of what is happening:
Near the bottom of the screen, there is a line where first cascade transitions into the second one. Only first cascade is rendering tessellation. What happens in second cascade, is that it renders shadow depth as if landscape had no tessellation, but tests this depth against a surface, which has tessellation, resulting in a circular region noticeably pushed out of the shadow(I’m using only positive displacement. Should I bias that into positive and negative, there would be mix of overshadowed and unshadowed pixels.). This is totally expected and correct.
Dealing with it involves ensuring that material displacement reliably fades to 0, before it reaches shadow cascade where tess is disabled. In case of the scene on the screenshot, Restrict Tessellation To Shadow Cascade should be set to 1, to include first and second cascade.
Part 2 due to char limit.
With that in mind, testing performance against the same scene in 4.18, drops nearly 3ms on shadow depth rendering.
It is also worth mentioning, that with separate LOD curves, one might not even need to restrict tessellation for shadow depth rendering and rely on LOD settings alone, but it is still good to have one .
@Deathrey Glad that you like the new exposed stuff, like you said there is a diff between satic rendering and dynamic rendering, i’m currently looking to fix this issue hopefully for 4.19 Release. As for the drop in shadow depth cost, keep in mind, that a phase 2 is closed to be finished that will completely eliminate the remaining case which is dynamic light aligned with the camera direction. With the new stuff it will remove more than 50% of the cost, while also lowering average shadow cost as it will use lower lod depending on the cascade if there is no visual quality drop. In big landscape this will be eliminating a LOT of primitives sent to the GPU while giving the same visual, but with a new setting to control if you want it to be more aggressive or not.
Hi @Michel.Dupuis, We got 4.19 and it’s so good thanks to you! I only have one question regarding this, in the first preview build I think there was a way to make tessellation cast shadow a bit further, but in the final release there’s no way to do that and we get a hard transition between shadowed tessellation geometry and non shadowed area which is pretty close to camera. Here I’m using 4 cascades with 20000 distance. Is there any way to help this a bit? because it’s really not looking good enough as you see here:
Hi @,
Glad that it’s now much better for you
This line you’re seeing was still there in other version, it’s where the cascade 0 stop (if i remember correctly). And should do that with any mesh you’re using but it might be more visible in the case of tessellation.
As for the other shadow params, they were simply pushed back to 4.20 with the rest of the phase 2 optim, so all shadow stuff will be together.