Renderer works: OpenGL freedom

manu3d

Active Member
Contributor
Architecture
Hi everybody!

With PR #3276 lining up for landing we are probably days away from opening up the renderer to modules, a goal I first envisioned some three years ago. In practice we will have to write some tutorials and further documentation before module developers can efficiently create new effects to plug into the renderer. But the door will be open.

One concern @vampcat and I are now having to grapple with is how much freedom we want to give to module developers, specifically in terms of direct OpenGL use. Through Terasology's sandbox model we can allow modules to access entire OpenGL packages/directives or otherwise limit access to them.

The question is: how much is too much, how much is too little?
More precisely, what don't we want modules be able to do OpenGL-wise? And given that in multiplayer the modules are downloaded from the server and
(presumably) have been vetted as "fair to use" already, is there really a need to limit direct OpenGL access in any way?

What does the community think in this context?

Tagging @Skaldarnar, @Josharias, @Florian, @readv and anybody else interested in the topic.
 

asie

New Member
Contributor
I feel giving direct OpenGL access can backfire pretty quickly once some important facet of the engine's rendering pipeline is changed in a broken manner. I feel a better idea is to expose higher-level wrappers.
 

manu3d

Active Member
Contributor
Architecture
Thank you for your contribution @asie. Can you elaborate a bit? What are the scenarios you'd like to prevent?
 

asie

New Member
Contributor
I'm not really sure if I'm making sense here - as OpenGL is not my area of expertise - but, to put it in broad strokes, let's say we're all - for some absurd reason - using immediate draws to feed our models' quads to the engine. Now, if we have direct OpenGL access, and we want to move to, say, using a geometry shader in some manner, that requires patching every mod to do so.

For a more sensible example - say, replacing OpenGL with Vulkan in the future, or providing an alternate Direct3D backend - both become much harder with direct OpenGL access.

For something I've seen in experience - giving mods direct OpenGL access can easily mean forgetting to restore a bit somewhere and ruining subsequent renderers.
 

manu3d

Active Member
Contributor
Architecture
Valid concerns @asie.

In regard to "revolutionary moves" such as Vulkan or a Direct3D backend admittedly you have me at a loss. Our ongoing transition to a node-based renderer architecture has the ambition to allow for less modern nodes, i.e. node based on OpenGL 2.1, to live alongside or be replaced by more modern nodes, i.e. using OpenGL 3.x or even 4.x. Capabilities-oriented nodes and node-managers might replace nodes at runtime in an effort to better cope with integrated GPU, as right now we don't really support them. Another endgoal is to make the renderer OpenGL-agnostic so that potentially you could replace all opengl-based nodes with, say, Vulkan-based nodes.

That been said, the whole application is currently based on an OpenGL context which is also used by the UI - UI being something I have no plan of touching. So, realistically, at this stage the scope of this discussion is limited to OpenGL and eventually using more modern releases of it.

The points you make about immediate draws, switching to geometry shaders and restoring bits are all relevant topics for this project. The node-based architecture helps in this context, in the sense that if you don't want to use the drawing modes provided by the existing nodes (i.e. opaque, simple blend, alpha-reject) you will be able to inject your own nodes into the renderer and use the available (or custom) StateChange objects to wrap state changes that need to be automatically undone after use.

Then there is the broader issue of how coarsely or how finely to wrap things. The coarser the wrapping the less freedom we give to module developers to come up with unforeseen effects. The finer the wrapping the greater the freedom but the higher the risk. Where should the threshold be in this context?
 
Top