Any chance of getting tesselation working on instanced terrains?

Tesselation doesn't work on terrains that have instancing enabled -- it's been like this since instancing was introduced in 2018.3. Is there any chance of getting that fixed? It's a huge limitation for terrain shaders.

 

Details:

- It started with 2018.3 and the new Draw Instanced option on terrain.
- It doesn't work with surface shaders with Draw Instanced. If you write a vertex/fragment shader you can get it to work.
- It appears that the ID needed for draw instanced isn't carried through the tessellation stages, so you get a compile error
- I submitted a bug on this ages ago, and after telling me it didn't repro on the latest version, and me giving them even more information that this isn't the case, I haven't heard from anyone regarding it since.

The bug number is 1111579


and a thread about it is also here:

https://forum.unity.com/threads/ter...-tessellation-surface-shaders-1111579.603670/

My best guess is that in abandoning surface shaders Unity has also abandoned any bugs associated with them, new, old, or otherwise.

 

Thanks for those details, Jason. @LeonhardP -- I'm not able to post on the original thread that Jason links to.... can you check the status of that bug report?

 

Any news about this @LeonhardP ? I'm also unable to comment in that other thread. Will this instancing+tessellation bug be corrected for 2019 LTS?

Searching the Issue Tracker for bug Id 1111579 from @jbooth in that thread doesn't yield any results.

 

Any news on this? This is still a very big issue which costs a lot of performance for when you want to use tesselation. In our situation is it around 80 drawcalls versus 3000+.

 

They did some investigation of the bug, and ended up confirming that it doesn't work. I think it's unlikely they will fix it since their focus is on making our lives harder with URP/HDRP.

 

Thanks for your reply Jason. It is a shame there is no further response on this issue. It is is really important that this also gets fixed on the built-in pipeline as HDRP is too unstable for our production at the moment. Is there still an active ticket for this? Perhaps we should resubmit?

@LeonhardP Do you know the status on this issue?

 

Wow. I'm sorry, but that is a perfect encapsulation of the sh*tshow that Unity graphics pipelines currently is.

"...is unfortunately not supported by Unity" -- passive tense. Wow.

 

Y'all should just file it as "Won't fix", since that is effectively what's going to happen, given that Unity is trying to push everyone to SRPs. I'd be fine with that, actually, if SRPs weren't completely unmaintainable like they are now..

 

So it's supported by URP, not HDRP, and not built in?

I could understand SRP but not builtin. Upgrades in new tech not being backported to tech that is being phased out.

If something should work on both URP and HDRP but doesn't because of some technical hurdle, it's really a bug. When you intentionally by design do something that's a feature. Like the by design differences between URP/HDRP. The dev teams are just doing mental gymnastics here to suit their own ends.

 

Thanks for the reply LeonhardP. This is a huge bummer since this feature is really important for high quality terrains for those being stuck in the built-in pipeline. For our type of project we'd need to switch to HDRP but that feels far from stable for a game that is in full production. The different pipelines and its varying support of features is really annoying.

Will HDRP eventually support this?

 

It's not so much a question of can the pipelines support this- it's really if the shaders support it. The problem with the Standard pipeline is that if your using a surface shader, the surface shader system needs to support it- and Unity has abandoned surface shaders, forcing everything into vertex/fragment shaders for the render pipelines.

The problem with vertex/fragment shaders is that there is no protection from Unity's constantly changing architecture - and Unity has basically refused to document the shader pipeline. So if you write vertex/fragment shaders, you're stuck digging through the shader source trying to figure out what changed on every minor release and apply that back to your shaders in a way that doesn't break previous versions. Across 3 pipelines, which have no particular release schedules, and even minor point updates can contain breaking changes. And with semantics you must include that you can't even test without specific hardware (VR, consoles, etc).

Their answer is to do everything through the shader graph, which is only useful for simple shaders, basically. You can't even write a terrain shader in it, let alone a complex one or use tessellation.

So basically, your choices are:
- Surface Shaders in standard, but you're out of luck if something doesn't work.
- Vertex/Fragment shaders, but expect to be constantly fixing them on every release. They are also 10x more complicated, and you'll have to do it for 3 entirely different renderer pipelines. So about 30x the work, with a pretty constant stream of new work just to keep up.
- Only write very simple shaders in the shader graph.

Basically, Unity has ruined their shader pipeline, and dumped the mess onto us..