4 ms·
Visualisation usually has much much smaller scope than game development. So frequent vs infrequent developer problems apply here, as in https://news.ycombinator
by 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 agoI 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 agoI 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.