Achitecture of Personal real time rendering engine for experimenting

[oak canyon]

I recently got back to following LearnOpenGL tutorials, I did the first chapters a couple of times in the past.

This time I want to make a proper toy rendering engine for exploring and implementing different rendering features such as: Shadow mapping/volumes, Real-Time Atmospheric Scattering, volume/clouds rendering, compute shaders, voids simulations etc. I even want to add some scripting to control scenes, objects, etc

The thing is that I want to develop a relatively well structured framework to use as a main base to build this stuff and I dont know where to start.

• How can I structure it?
• What stuff should I abstract? How they should interact?
• Is there a standard architecture for rendering engines?

I know that architecture will grow/evolve with every new feature implemented, but:

• what basic stuff should I cover?
• Make a shader class? A material class? An object class that needs a mesh object and a material? How they should relate?

Im very lost here.

Thanks for your time.

Achitecture of Personal real time rendering engine for experimenting

[delicate seal]

Have you build anything out of the basics yet

Like the material from the first 3 chapters

Part of your confusion may just be from lack of experience in using the API

And lack of experience in understanding the needs of a 3D application

[hoary raven]

I suggest taking a look at Three.js. Try it out as a user to get an idea of what functionality it has. Trying to recreate this behaviour is a good starting point for thinking about engine architecture.

[oak canyon]

oh, maybe I should continue and end the whole course

[delicate seal]

Not really, or at least not necessarily

You should take the basics and build something large with it

You don't need anything beyond the lighting/mesh loading chapters to start building complex games and stuff

And then you can dip into the "advanced OpenGL" chapter for instancing and offscreen rendering and whatnot

[oak canyon]

I have no intentions to make a proper game engine, at least for now

My idea is to have a good rendering framework to implement advanced techniques eventually

[delicate seal]

You don't have to make a game engine but you need to make something that handles a bunch of heterogeneous data

Otherwise I'm not sure how you would know how to design your renderer's API

What is your renderer for? Realtime applications (e.g. games)?

[delicate seal]

The issue is that you're basically asking how to solve a structural problem that doesn't exist yet

I would just dive in and brute force your way through it sort of semantic-compression style until you identify an architecture that fits your needs

I wouldn't waste much time with generalization apart from maybe some C++ wrappers around buffer objects to make things easier

Hard-code a class per shader that just stores the shader program ID and a function that hard-codes whatever setup is necessary to invoke your shader

You will figure out quickly what does and doesn't work once you stop following guides and start forging your own path

[oak canyon]

The main purpose is experimenting and implementing rendering techniques, like atmosphere rendering, try some volumetric rendering, maybe dive into compute with some voids etc

yes you are right, maybe Im getting in trouble with architecture too soon

[delicate seal]

Abstraction helps if it fits your project but if it doesn't you end up just fighting it

Imo the best architecture for experimentation is one that's as close to a green-field project as possible

Basically just calling functions that are free to do whatever raw GL and data wrangling they need

To begin with I would make your renderer just one big free function that consumes your scene state and renders a frame

You can split it up and abstract it later once you have a good sense for how it makes sense to do so