Comments (2)
Currently render targets (WRenderTarget
) created by the user create their own (buffered and fenced) command buffers. This is requiring a vkWaitQueueIdle
operation (bad) because the two command buffers are not synchronized and the resources are being used in both. Investigate the possibility of using the same primary command buffer of the renderer? This way, it will be synchronized with the renderer's primary command buffer (i.e. render to secondary first, then render normally, as two consecutive begin/end renderPass in the same command buffer).
Additionally, currently WRenderTarget
s can only be rendered to if user creates custom WEffect
s (vulkan pipelines) for that WRenderTarget
or the render pass in the WRenderTarget
is "compatible" with the renderer's render pass (compatible means its similar in a compatible way, for now, it seems to me that it was to have the same target attachments (1 color 1 depth, with same formats). Investigate possibilities here... Do we need this limitation? can the engine automatically detect incompatible pipelines and fork out resources (and should it? or would that mess the user up...)?
from wasabi.
Implemented WRenderGroup
+ WRenderable
=> generic implementable rendering mechanism. Render group should be renamed to WRenderGraph
. The goal:
- One
WRenderGraph
for the renderer WRenderGraph
will index have all objects, terrains, sprites, particles, etc... (all inherit fromWRenderable
)WRenderGraph
will be primarily indexed byWEffect
. Each effect will have a priority andWRenderable
s of an effect will be rendered based on the effect's priority- A
WRenderable
also has its own rendering priority to sort within the same effect - Effects have render flags, this helps more sophisticated renderers (e.g. deferred renderer) to control the rendering (e.g. no 2D in GBuffer, etc...)
- E.g. a renderer can have multiple stages, each stage will use the
WRenderGraph
by supplying different render flags
- E.g. a renderer can have multiple stages, each stage will use the
For future:
WRenderable
s of the sameWEffect
that have the same render priority can be somehow grouped together into one (instanced?) draw call automatically. This is a big potential optimization.- Can use push constants as well to optimize (if all
WRenderable
s only differ in world matrix, for example). This is a common scenario. How can we optimize so that no unnecessary resources are created, but with minimal user interaction?
- Can use push constants as well to optimize (if all
- Can specify static objects, and possibly merge geometries of static objects that use the same effect.
- Maybe it is more optimal that the user specifies this, but perhaps this can create an easier experience if done automatically.
- How does this impact frustum culling loss? Need to make sure proximity also makes sense...
from wasabi.
Related Issues (20)
- Better error reporting
- Use Catch2 to make more meaningful tests
- Use TravisCI
- Basic Editor using IMGUI
- Create samples for newcomers HOT 1
- Compile Doxygen and update the /docs
- Anything with a custom effect won't render HOT 1
- Consider particle rendering in a worker thread
- Separate GLFW window creation and loop in a GUI-only thread
- Switching between renderers causes randomness in rendering HOT 1
- Complete terrain implementation
- Add DPI support
- Particle enhancements
- Complete the engine documentation
- Objects wobble when camera moves
- Lighting doesn't have proper spec
- Particles stop emitting after a while
- Render to texture sample broken HOT 7
- Run physics in a separate thread at fixed rate
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wasabi.