Framebuffer re-use WIP #13492
Framebuffer re-use WIP #13492
Conversation
…py to texture, opaque object copier before transparent objects are rendered
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13492/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/13492/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/13492/merge#BCU1XR#0 |
|
Visualization tests for webgl2 have failed. If some tests failed because the snapshots do not match, the report can be found at If tests were successful afterwards, this report might not be available anymore. |
|
Visualization tests for webgl1 have failed. If some tests failed because the snapshots do not match, the report can be found at If tests were successful afterwards, this report might not be available anymore. |
|
I don't get why my builds are failing. Seem to work earlier. Job description on CI is unclear.. |
|
Every imports should be relative and complete (I mean to the file itself) like import { Engine } from "core/Engines/engine"; should be import { Engine } from "../Engines/engine"; maybe with more ../ depending on the hierarchy. The formatting / linting should be according the rules in the repo (there are npm tasks to help fixing them) Comments (in ts doc style) should be added. |
|
Let us know when you have validated all your code and the PR is ready for review. General comments:
|
|
@grimdeathr , you also need to add a test, you can use the code you are using to validate your PR as I wonder how it could work in the current state. I will actually move it to draft as it is not ready to be reviewed. |
… use existing callback for onBeforeTransparentRendering
|
@grimdeathr I will close the PR for now to prevent other ppl to spend time on early review. I let you reopen it once ready. This commit 85e212c is not the right approach, you need to copy the GPU content of the texture not the CPU references to it. |
|
Visualization tests for webgl1 have failed. If some tests failed because the snapshots do not match, the report can be found at If tests were successful afterwards, this report might not be available anymore. |
|
Visualization tests for webgl2 have failed. If some tests failed because the snapshots do not match, the report can be found at If tests were successful afterwards, this report might not be available anymore. |
|
So using engine._currentFramebuffer; is wrong? @Popov72 Is engine.readPixels better? Theres no early review but I will be asking a bunch of questions.. |
|
_currentFramebuffer is a cached value of the currently bound frameBuffer and can not be assigned as you do to a texture. You cast it to assign it to a texture (not making a copy but swapping it) by passing important type checking which was probably letting you know of the error. As @Popov72 mentioned, the purpose of the PR is to copy the existing data from the framebuffer to the RTT, not to render the scene in the RTT. Basically, copy the GPU content of the current frame buffer inside of the RTT GPU content. readPixels won t be better as it is highly inefficient and will need to copy the data from GPU to CPU and then back to GPU. You want to do the copy GPU side. The bounty is not necessarily an easy one if you never developed with Babylon or WebGL in the past. It would be great if you can show us a working Draft we would grow from. |
|
Thanks for the detailed response. I will continue with this in my fork. I've developed extensively with BabylonJS and WebGL, albeit mostly working on games and experiences. I will update the story on the original bounty issue. |
BitReelCo/BJS-PR-Bounty-Pool#4