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

Post process framework roadmap #5808

Open
15 of 46 tasks
pjcozzi opened this issue Sep 2, 2017 · 16 comments
Open
15 of 46 tasks

Post process framework roadmap #5808

pjcozzi opened this issue Sep 2, 2017 · 16 comments

Comments

@pjcozzi
Copy link
Contributor

pjcozzi commented Sep 2, 2017

Initial implementation: #5615
5-year old notes

  • Finish full screen effects in Post processing #5615
  • Per-entity effects. Any entity should be able to have post processing effects applied to it.
    • Per-feature effects for 3D Tiles
    • Write object ids to a gbuffer - or separate render pass for entities with effects applied to them.
      • Use MRT, handle translucent issues.
      • Use scissor test around entities with effects applied.
      • Use textureLOD to determine if an id was written to part of texture?
      • Use object id gbuffer for picking
  • Consolidate depth buffers into a single depth texture rather than use the closest frustum's depth texture.
    • May not be needed if we move to a log depth buffer, where the first frustum will be a lot larger. Log depth buffer #5851
  • HDR rendering
  • Effects
    • Black and white
    • Brightness, contrast, hue, saturation
    • 8-bit
    • Night vision
    • Texture overlay
    • Depth view
    • Gamma correction
    • Lens flare
    • Ambient Occlusion
    • Silhoutte (replace stencil-silhoutte in Model)
    • Edge detection
    • Depth of field
    • Bloom (simple)
    • Bloom (advanced - requires HDR)
    • Fog
    • Gaussian blur
    • Motion blur
    • Glow
    • SSRTGI?
  • Use the post-processing framework wherever applicable throughout Cesium:
    • FXAA
    • OIT
    • Sun bloom
    • Picking buffer
    • Invert classification
    • Point cloud surface generation
    • Atmosphere coloring
  • Wide range of sandcastle examples highlighting use cases of post processing
  • Tech blog post
  • Reuse ping-pong textures: if we're not already doing this, I realized that when we are rendering to down-sampled textures, it would probably be better to just reuse a larger texture and render to a subset of it so we overall allocate fewer textures. Somewhat related, check out the Transient resource system in Frostbite. Note that I expect our textures to have a lifetime of multiple frames, and eventually be deallocated like the shader cache.

Later

  • Post processing effects on particle systems (like heat haze, combining particles)
  • Highlight objects that are occluded
  • Cesium rendering blog post
  • Longer-term transpiler/optimizer to combine multiple post-processing passes into one pass. Basically we provide a set of filters/effects/passes to a pipeline/whatever object, then the pipeline object is free to optimize as it sees fit. For more inspiration, see Designing a next-generation post-effects pipeline.

Links

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Sep 25, 2017

Nice article with a bit on their post processing: Godot 3's Renderer Design Explained

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Nov 29, 2017

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Dec 10, 2017

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Dec 10, 2017

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Dec 10, 2017

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Dec 10, 2017

@lilleyse
Copy link
Contributor

Possible idea from the forum: https://groups.google.com/forum/#!topic/cesium-dev/DJiirg0L5Cs

Render translucent buildings, but have the buildings still occlude each other.

extrude

It would require rendering the tileset to its own framebuffer with depth test/mask on, and then blending that framebuffer with the scene's framebuffer. It may not be hard to add this to the post processing branch as is.

@lilleyse
Copy link
Contributor

Another request from the forum which should be very straightforward with post processing - change a tileset's contrast or saturation, especially useful for photogrammetry.

https://groups.google.com/forum/#!topic/cesium-dev/zQ0GEQ2SXDU

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Jan 12, 2018

This could also replace the current approach for contrast/saturation/etc for imagery.

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Jan 14, 2018

@bagnell @byumjin two questions on the current HBAO. If we haven't done these yet, they could be good roadmap items.

  • Have we looked at Line-Sweep Ambient Obscurance to reduce the number of depth buffer reads by splitting the occlusion calculation into two steps?
  • Instead of using the HBAO occlusion factor, have we looked at ground truth ambient occlusion (GTAO)? Is it fast and simple enough and produce notably better results for us to consider using it instead?

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Apr 17, 2018

@pjcozzi
Copy link
Contributor Author

pjcozzi commented Jun 17, 2018

@bagnell can you please update the tasklist at the top of this issue?

@laurensdijkstra
Copy link

laurensdijkstra commented Dec 10, 2018

Now that HDR rendering is (at least partially) implemented, is it possible to use floating point textures in the post processing stage?

@bagnell
Copy link
Contributor

bagnell commented Dec 11, 2018

@laurensdijkstra Yes. You can pass pixelDatatype: PixelDatatype.FLOAT as an option to PostProcessStage, but you must also check that Context.floatingPointTexture and Context.colorBufferFloat are supported.

@laurensdijkstra
Copy link

laurensdijkstra commented Dec 17, 2018

I have not been able to get the initial HDR rendered image of the Scene with pixelDatatype: PixelDatatype.FLOAT and HDR enabled. Is it possible to obtain the HDR rendered Scene texture in a PostProcessingStage?

Clarification as to how I have tried to determine whether the colorTexture uniform in the PostProcessingStage fragmentShader is HDR or not: I checked each RGB value to see if it exceeded 1.0 and output vec4(1e6, 1e6, 1e6) in the shader if so, black if not. The result was a black image.

When outputting vec4(1.0, 1.0, 1.0, 1.0) the image was white. This should not be the case with gamma 2.2 should it? I'm new to HDR stuff so please correct me if I'm wrong.

It seems Scene._view.sceneFramebuffer.getFramebuffer() is passed to PostProcessingStage.execute as the colorTexture, which I have checked to be HALF_FLOAT when HDR rendering is enabled. I do not understand why the values I checked with the method above do not exceed 1.0. They seem to be between 0.0 and 1.0. Are the HDR values collapsed before being sent to the post processing stages?

Looks like this is somewhat related: #5932

@GeorgeS2019
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants