This site has OpenGL tutorials focused more on visualization: https://open.gl/introduction

While the final rendering code for visualizations may look very differently from game rendering code, the underlying techniques are exactly the same unless you are doing some really hard out of core stuff or something else that is really extreme. So I do not see the point for separate resources, to be honest. Visualization is much more about the pipeline that you execute before you start rendering.

Visualisation usually has much much smaller scope than game development. So frequent vs infrequent developer problems apply here, as in https://news.ycombinator.com/item?id=16561901

Any new concept or tool dependency, e.g. 3D editor or shader, is a pain point here since it increases project compexity superlinearly.

Also, many "game engines" which aim to speed up development impose a lot of constraints on client code. For example, they're not compatible with non-GL windows from same process or with external event loop. I made a mistake trying to use a few of those and impedance mismatch was really painful. Had to divest to plain OpenGL.

I mean, yeah. If you try to use a framework intended for games, it won't be a great fit for other use cases. Look into Open Scene Graph if you want a higher level API that isn't as opinionated towards games.

Vulkan isn't a higher level API though, which might be why you and the other guy are kind of talking past each other.

I do not think I understand your point at all.

Realtime rendering is independent from game engine implementations and especially from content creation pipelines. If you are looking at resources that explain how to use game engines then you're looking in the wrong place. What you want is resources that teach how to write rendering code.

They probably should not be dealing with all the pain of Vulkan at all.

I've been playing with Monogame (used to be Microsoft's XNA) lately, which is cross-platform and very easy to get up and running with.

As I have been explained, Monogame is not even a game engine, rather a framework for writing game engines.

That's a particularly poor fit for 3D visualisation. No primitives, expectations of bringing your own shaders, inability to work with Forms in the same process...