Why not use gpu tesselation? about crest HOT 8 CLOSED

Hi dizzy! Thanks for the question and apologies it took me a while to get back to you!

Our method originates from projects that shipped on a wide range of platforms, not all of which had tessellation units. We did at one point do some comparisons with tessellation-based solutions but unfortunately we didn't get as far as conclusive comparisons/timings. I'd love to do this as future work. However from initial experiments it appears that tessellation becomes expensive for high expansion ratios (generating lots of geometry). Our technique has no such problem, and supports a large dynamic range of detail levels (7+ orders of magnitude).

I believe there are ways to mitigate the problem of high expansion ratios, such as dividing the surface into tiles before tessellation. But at the logical extreme, if one places enough tiles then they would arrive at either our method or CDLOD, both of which do not require tessellation.

One of the strongest contributions of our approach in my opinion is the efficient multiscale shape rendering that is inherently LOD'd and matches geometry density 1:1. Its simple fractal structure allows a compact implementation. Each LOD level always blends between 2 shape textures, and always transition between two geometry densities without needing hardware tessellation. Employing tessellation would likely add complexity rather than removing it, for our use case at least.

Finally, I would assume using tessellation takes additional power and may be less suitable to low powered/mobile devices as well. However this is only an assumption without evidence to back it up.

It's a shame i don't have hard numbers for you, rather than giving you unsubstantiated claims and intuitions, sorry about that! If we do get around to doing rigorous comparisons I'll be sure to let you know.

from crest.

Thanks for the really in depth reply.
I'm working in a small fulltime team on a game that heavily features ocean and sailing.
At the moment we are using an asset store solution (heavily modified) but are keeping an eye on your work :)

from crest.

Cool! We'd love to hear if you can make use of any of our stuff, it would make us immensely proud :). Where are you guys based out of interest?

I've just given the readme a long overdue update and it talks about some of the work in progress stuff which may be of interest. I think the stuff in the fx_test branch would be super interesting to incorporate in a game (especially with some art love), and definitely check out the local_sim branch if you haven't already :). Notes about both are added to the readme.

from crest.

Based in Brisbane Australia.

Had a more in depth look today, first issue is we dont have enough layers available in our project.

It looks to me like you are using the layers to render out the displacement textures for each lod using a dedicated camera and a quad per lod with each having its own render layer.

Pretty sure the same effect can be done removing the camera and calling Graphics.Blit() passing in the material. Would just need to setup those worldspace positions differently calcing them from uv's. I will take a look at making that change maybe tomorrow.

from crest.

Nice! From Melbourne myself.

Yeah its a massive hog for layers, its high on my list to sort out - I'd ideally not use any layers at all. You are correct about how they're being used.

I never quite know if Graphics.Blit will triggers stuff to happen in the right order (i.e. after the right cameras have rendered). I was thinking to attach command buffers to cameras (there is some code lingering around to do this for rendering ocean floor depths) which involves a bit more hoop jumping but at least makes the order of things clear(ish). Let me know if you do look at it, I'll also try and experiment on my side and let you know if I can sort them out.

from crest.

I had some luck removing the layers, all the per-lod layers are gone from master now. The code settled pretty well but i'll be on the lookout for issues.

I also attempted to merge this into local_sim but ran out of time midway through, will pick this up again hopefully tomorrow.

from crest.

In case its still interesting, i can confirm that local_sim now makes minimal use of layers (scene: boat.unity). This definitely belongs in a dev branch for the time being, but should be sufficient to demonstrate the concept. Happy to hear any more feedback about issues or blockers for using our system.

from crest.

There is a thread evolving on Twitter about tessellation - thought it would be useful to add it here for the record.

https://twitter.com/Atrix256/status/1032666876264894464?s=19

from crest.