I see, Thanks for advices

While you're correct about the graphics module can live without a mathematics module, you're forgeting that a graphics module it's all about bringing the low-level graphics API to our users interface with it.

A graphics module should know about the mathematics module to facilitate its interface with the graphics wrapper, and it should be called CXApiWrapper or similar, instead of a renderer because it's not a software-side renderer nor rasterizer. The graphics wrapper it's a interface that needs to be pre-determined before re-building the engine and running the simulation depending of your current platform or some criteria. Example: DirectX® runs faster on Windows, so you should use that instead of OpenGL®—altough both are available. In iOS, we're only limited to OpenGL® ES and it's mandatory to use that.

I don't think the renderer is the same thing as a graphics wrapper. Sure, a renderer could utilize a graphics wrapper, or even double as one, but the two terms are not mutually exclusive.

A renderer should be above a wrapper, if any. All it should do is take relatively high-level commands and transform them to commands for the underlying graphics library, whether that be a wrapper or raw D3D/OpenGL. There doesn't need to be any abstraction with the renderer. The renderer is more of a convenience system rather than one necessary for an engine. It's not essential for the engine to do tasks without it. If you want multiple render backends then you should write the renderer to transform engine commands into the wrapper's commands.

A scene manager it's at the same level of the engine and knows what a graphics module, mathematics, physics, etc. are.

The scene manager should not be at the same level as a graphics module.

I don't think the renderer is the same thing as a graphics wrapper. Sure, a renderer could utilize a graphics wrapper, or even double as one, but the two terms are not mutually exclusive.

The OP mentioned GPU management, so it's basically what a graphics wrapper brings to a high-level visibility. If by "renderer" you mean a render queue or related, of course it's higher level than the graphics library, but still lives inside the graphics module.

A render queue has render items that can be texture IDs, shaders IDs, or even a shader technique type.

A renderer should be above a wrapper, if any. All it should do is take relatively high-level commands and transform them to commands for the underlying graphics library, whether that be a wrapper or raw D3D/OpenGL.

The user asks the graphics wrapper to set the current ambient color to the current shader, so the graphics library high-level interface ("renderer") provides that. The graphis API wrapper doesn't know what a renderer is. The correct it's that the "renderer" uses the graphics low-level interface.

There doesn't need to be any abstraction with the renderer.

Yes. As I stated before, the renderer should not be related to a scene manager and it is a high-level interface of the low-level graphics wrapper.

The renderer is more of a convenience system rather than one necessary for an engine.

The "renderer" it's not necessary in non cross-platform situations (even if it should be). If only have DirectX® 11 and you need to set a shader variable, just pick its constant buffer and update its data directly interfacing with the API, but even if you're not running, it is a good idea to keep this separation.

The scene manager should not be at the same level as a graphics module.

Check again. I said that it's at the same level of the engine. In the engine module you have the game, the game entities like animated skeletons, etc., and the scene manager has lights, cameras, and actors (it has game entities). The scene manager can use all modules because it's at the same level of the engine.

For example due to religious reasons I perform compilation using gcc or g++

Which religion is that? That might be a religion I can get behind! ;)

Nothing special. I sincerely believe that compiler should support all current language features - because only in that case it will be complete. Thus perfect.

Only those features that you actually use are important for compiler selection and there are also other reasons to compare which is best compiler for you. Compilers are never perfect nor they are complete.(Every complex piece of code contains bugs.) This just sounds superstition.

The OP mentioned GPU management, so it's basically what a graphics wrapper brings to a high-level visibility. If by "renderer" you mean a render queue or related, of course it's higher level than the graphics library, but still lives inside the graphics module.

A render queue has render items that can be texture IDs, shaders IDs, or even a shader technique type.

No no no... a render queue is just that - a queue. It doesn't take care of managing resources, the renderer itself does that. The render queue is just a stream of renderer commands.

The graphics wrapper itself should provide a low-level common interface for the renderer to interact with. I think your renderer and graphics wrappers are strongly coupled.

The user asks the graphics wrapper to set the current ambient color to the current shader, so the graphics library high-level interface ("renderer") provides that. The graphis API wrapper doesn't know what a renderer is. The correct it's that the "renderer" uses the graphics low-level interface.

That should be the renderer's job. If the engine has a graphics wrapper, then it should aim to try to provide a near 1:1 interface with the underlying API while still keeping a common interface between other APIs.

The "renderer" it's not necessary in non cross-platform situations (even if it should be). If only have DirectX® 11 and you need to set a shader variable, just pick its constant buffer and update its data directly interfacing with the API, but even if you're not running, it is a good idea to keep this separation.

Well, the renderer shouldn't be necessary at all in my way of doing it, even in cross-platform situations. If you want cross-platform capabilities, then just use a wrapper instead of D3D.

Check again. I said that it's at the same level of the engine. In the engine module you have the game, the game entities like animated skeletons, etc., and the scene manager has lights, cameras, and actors (it has game entities). The scene manager can use all modules because it's at the same level of the engine.

Ah, thanks for clearing that up. I misread it.

That's how I do it anyways. I guess everyone has a different way of doing things.

No no no... a render queue is just that - a queue. It doesn't take care of managing resources, the renderer itself does that. The render queue is just a stream of renderer commands.

I didn't say managing resources. I said using a ID in order to bind a texture or a shader to a specific model to be rendered—a unique identifier. Resource management it's a competely separate concept, and for each type of loaded resource you should have manager, and that is when you bring proper GPU high-level vision and management to the project to enfatize what the OP said.

The graphics wrapper itself should provide a low-level common interface for the renderer to interact with. I think your renderer and graphics wrappers are strongly coupled.

That's what I clearly said. Check again:

the renderer should not be related to a scene manager and it is a high-level interface of the low-level graphics wrapper.

The user asks the graphics wrapper to set the current ambient color to the current shader, so the graphics library high-level interface ("renderer") provides that. The graphis API wrapper doesn't know what a renderer is. The correct it's that the "renderer" uses the graphics low-level interface.

Well, the renderer shouldn't be necessary at all in my way of doing it, even in cross-platform situations. If you want cross-platform capabilities, then just use a wrapper instead of D3D.

The correct way of doing it is having a separate functionality for the low-level graphics API.

If you ever used the Effects Framework or looked at it you know that it provides high-level functionality to the user. The user asks to set specific material color, and the wrapper translates that into DirectX functionality. I'm saying that because the "renderer" (if by that you mean, a high-level graphics wrapper) works in a similar way, but the only difference it's that it doesn't care which API you're using. Take a look here.

That said, a "renderer" isn't a scene manager, nor a render queue manager, nor a model manager, nor a compiled shader manager. The "renderer" only fits better in being a facade to a graphics interface.

There are tons of possibilities of something being rendered. If you have a "renderer", which of the following objects can be rendered and be related with it?

Renderable;

RenderableModel;

RenderItem;

RenderableText;

RenderableInstance;

You see? It gets more complicated to differentiate between renderables, game entities, render items, UI, while in the end, each of these classes would fit better in its appropriate managers or even modules.

-snip-

...So I pretty much misread your entire post then...

Lol, sorry. I was arguing about mostly the same thing that you were saying then. My bad.

The correct way of doing it is having a separate functionality for the low-level graphics API.

If you ever used the Effects Framework or looked at it you know that it provides high-level functionality to the user. The user asks to set specific material color, and the wrapper translates that into DirectX functionality. I'm saying that because the "renderer" (if by that you mean, a high-level graphics wrapper) works in a similar way, but the only difference it's that it doesn't care which API you're using. Take a look here.

That said, a "renderer" isn't a scene manager, nor a render queue manager, nor a model manager, nor a compiled shader manager. The "renderer" only fits better in being a facade to a graphics interface.

Yeah... we shared the same views. I wasn't reading what you said correctly and now I feel like an idiot for wasting both of our times.

EDIT: Edited out the last section because I of course read everything wrong, lol.

yes. been there, done that.

good idea?

no. not recommended for mission critical code. less performant than native machine code.

Huh? I don't understand what you're saying...

He isn't talking about implementing a full blown virtual machine... I think he's referring to the rendering engine.