Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List of problems and possible ways to improve #3

Open
nicoell opened this issue Jul 29, 2018 · 0 comments
Open

List of problems and possible ways to improve #3

nicoell opened this issue Jul 29, 2018 · 0 comments

Comments

@nicoell
Copy link
Owner

nicoell commented Jul 29, 2018

Hi there,
since i'm not planning to futher work this project i'd like to share some problems with the current implementation and several ways to improve it. Some of them are implementation specific problems and can be solved by doing a little refactoring while others are more fundamental cons that were conclusions from my bachelor thesis.

Fundamental Cons

  • Geometric grass needs proper anti-aliasing. Currently the width of geometric is increased further away from the camera by a set amount. There should be a screenspace solution to adjust the size to always cover a single picture. Such a method is discribed in this paper: Xuan Yu et al. "A Framework for Rendering Complex Scattering Effects on Hair"
  • The third level of detail with screenfacing billboards should be replaced or extended by a volumetric lod representation to improve visuals from an aerial perspective and prevent aliasing. When replacing one should use vertical and horizontal slices, when extending just horizontal slices should be enough. Both of these volumetric methods are described in this paper: Rendering Grass in Real Time with Dynamic Light Sources.
  • Billboards are skewed to much when strong forces act upon them. Some form-conserving measures should be introduced by dynamically increasing the tessellation levels when needed and factor in the curvature. The goal is to reach sth. like in this paper: GPU-based Responsive
    Grass

Implementation Cons

  • Patches not visible are not being simulated, which can introduce visible seams when changing the view direction. This can by simulating all patches, not just visible ones. Since simulation is fast with <1ms for usual settings, this should not be a bottleneck.
  • One should work on a single texture containing all simulation data instead of one texture per patch. This greatly reduces a performance bottleneck from the original implementation since the texture does not have to be bound to the computeshader per frame and patch, but just once. Already implemented in branch: CVTagImprovements
  • The amount of draw calls is too high. Every grass patch procudes a draw call for geometry, crossed billboard and screefacing billboards grass when needed. Optimally there would be only one drawcall for each of those rendering methods. I didn't come up with a good solution for this, since all my ideas would have other cons. Yet i did not test if those cons would be less serious than the con of having to much draw calls.
  1. One idea is to fully rely on culling inside the tessellation phase by setting the levels to zero (which is currently done for fading rendering methods).
  2. Another idea is to use DrawIndexedInstanced or DrawIndexedInstancedIndirect (see d3d11 docs) to build an IndexBuffer. Unfortunately those methods are not (easily) available in Unity, afaik.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant