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

Render world via an intermediate FrameBuffer #17308

Merged
merged 6 commits into from Dec 8, 2019

Conversation

@pchote
Copy link
Member

pchote commented Nov 3, 2019

This PR completes the series of changes that started with #16996, #17026, #17042, #17095. The basic idea here is that everything in the world (i.e. drawn by the WorldRenderer that isn't an annotation) is first drawn into an offscreen buffer at 1:1 zoom. This guarantees that each world pixel maps to exactly one pixel in the depth buffer, which is the only reasonable way to avoid bugs like #12876.

When rendering switches to the UI layer we flush everything in the world layer and render that into the screen buffer as a single textured quad. Annotations and Widgets are then drawn on top as before.

Fixes #12876.
Fixes #11332.

This also lays the groundwork for a bunch of future renderer improvements:

  • Distortion effects like #12289 and #9778 and RGBA-sprite aware color effects (#6734 etc) by ping-ponging between a pair of frame buffers with custom shaders that resample the world texture.
  • Moving the world rendering into its own widget instead of relying on a collection of engine-level hacks.
  • The world part of #10382 and arbitrary mouse zooming after implementing a contrast-preserving fractional-pixel sampler (proof of concept in a027222)
  • Full-map editor previews (#2762) by implementing a bodge that renders the full map into the world frame buffer then saves that directly to disk instead of to the screen (proof of concept in ff84d2f)
@pchote pchote added this to the Next+1 milestone Nov 3, 2019
@pchote pchote force-pushed the pchote:render-framebuffer branch 3 times, most recently from 273df7e to 9463c12 Nov 3, 2019
Copy link
Contributor

reaperrr left a comment

Looks good as far as I'm able to tell, spotted no regressions on RA, D2k and TS shellmaps

@pchote pchote force-pushed the pchote:render-framebuffer branch from 9463c12 to 6bcd2d2 Nov 24, 2019
@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Nov 24, 2019

Updated and rebased.

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Nov 24, 2019

Adding the dependency label for the zooming PR that will come next.

@reaperrr

This comment has been minimized.

Copy link
Contributor

reaperrr commented Dec 4, 2019

Still working fine as far as I can tell, there's just one thing I wonder about:
I was always under the impression that the render cost graph would basically represent the culminated cost of render_widget + (implicitly) render_world, maybe with a tiny extra.
Yet at least in my test in TS, render_widget was far less than half of render, while render_world was actually so low I could barely make it out, meaning even both combined don't seem to be responsible for even half our render cost. Where does the rest come from?

@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Dec 5, 2019

The perf graphs measure the CPU time for the render methods, but a lot of the work happens on the GPU. The render methods submit draw calls that start to run asynchronously, then we have to wait for it to catch up at the end of the frame.

@pchote pchote force-pushed the pchote:render-framebuffer branch from 6bcd2d2 to 08cfc77 Dec 6, 2019
@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Dec 6, 2019

Rebased and added fixes for the issues discovered while testing #17424:

  • Fixed depthScale calculation, which now needs to be using the viewport height instead of the window height
  • Ported the ModelRenderable annotations to the UI renderers - these were missed by #17095.
@pchote

This comment has been minimized.

Copy link
Member Author

pchote commented Dec 8, 2019

I have a growing number of features/PRs blocked on this, so if nobody else is planning to review this we should go ahead and merge it.

@tovl
tovl approved these changes Dec 8, 2019
@reaperrr reaperrr merged commit 2603a49 into OpenRA:bleed Dec 8, 2019
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@pchote pchote deleted the pchote:render-framebuffer branch Jan 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

4 participants
You can’t perform that action at this time.