4 ms·

I wonder if there's something for people who are not game engine developers, but they need some 3D visualization for e.g. science. In my experience it is a pai

I wonder if there's something for people who are not game engine developers, but they need some 3D visualization for e.g. science. In my experience it is a pain point.

jxub 9y ago
This site has OpenGL tutorials focused more on visualization: https://open.gl/introduction https://open.gl/introduction
gmueckl 9y ago
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.
- thriftwy 9y ago
  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 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.
  - gmueckl 9y ago
    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.
  - monocasa 9y ago
    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.
megaman22 9y ago
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.
- thriftwy 9y ago
  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...

I wonder if there's something for people who are not game engine developers, but they need some 3D visualization for e.g. science. In my experience it is a pain point.

jxub 9y ago

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

gmueckl 9y ago

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.

thriftwy 9y ago
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 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.
- gmueckl 9y ago
  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.
- monocasa 9y ago
  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.

megaman22 9y ago

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.

thriftwy 9y ago
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...