4 ms·
Looking at the API here, it feels very much driven by OpenGL. You create a shader, send some parameters, push/pop some of the state, and bam - here is some rend
by kvark 5y ago
Looking at the API here, it feels very much driven by OpenGL. You create a shader, send some parameters, push/pop some of the state, and bam - here is some rendering.
I'm curious if there is still ideas to discover in the space of code-only 3d engines. Something more tied to modern API concepts, such as render passes and pipeline states.
- alice-i-cecile 5y agoHave you seen Bevy's new rendering experiments? Very much along the lines of what you're describing.
- cmdr2 5y agoNice, I hadn't come across Bevy, thanks for mentioning this. For others: https://bevyengine.org/news/introducing-bevy/ https://bevyengine.org/news/introducing-bevy/
- soylentgraham 5y agoI've gone back to an approach from the mid 2000's where high level i generate the most basic draw calls (setrendertarget,clearcolour) (Draw shader+geo+uniforms) As data, which i can serialise, stream, debug, pause&tweak, generate on multiple threads, etc and then low level batch together, generate pipelines, reduce state change, whatever the renderer needs, or just pump to a gui. Finally starting to build up little libraries of commands (generating text "draw calls", gizmos etc) which work project to project. Not very cutting edge tech, but lots of room for lower level (or even high level) optimising (culling, front to back, transparency sorting etc)