3 ms·

While the final rendering code for visualizations may look very differently from game rendering code, the underlying techniques are exactly the same unless you

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.

3 ms·

While the final rendering code for visualizations may look very differently from game rendering code, the underlying techniques are exactly the same unless you

by gmueckl 9y ago

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.