To be honest, I'm more and more tempted to make my own "engine" and implement just the things I need, instead of using an engine that will often have too many features I don't need.
All I really need is a camera, vertex geometry tools, and a flexible and well designed shader system (since shaders are now essentials for 3D graphics. Most of what an engine do, or should really do, is shader management).
I don't need:
* animation
* a scene manager
* sound
* inputs
* font
* texture
* physics
I'd really like an engine that only do graphics and do it well. That is what makes Ogre3D good at what it does. All I'd hope for is a data-oriented engine, instead of object oriented.
Have you seen any data-oriented 3D engines anywhere? Even the few engines I've looked at for e.g. Clojure are just needlessly OO on top of some Java stuff.
tldw: High performance C++ is converging on something that strongly resembles Erlang. Multiprocessing and issues with memory coherency between cores is driving this.
I can't imagine even a minimal graphics library providing "camera, vertex geometry tools, shaders" but no texturing. Even a lightweight wrapper over a graphics API like OpenGL or DirectX will have texturing support.
"Most of what an engine do, or should really do, is shader management"
Can you expand on this statement?
Either way what you seem to want is so minimal there's a probably a few libraries that you can use. OpenSceneGraph, VisualizationLibrary, OGLPlus, etc.
having worked on and written x of this class of thing over the years this made an interesting browse and read, but i've not been inspired to anything new by it sadly... and i wouldn't have a use for it in practice.
it seems a bit of shame this has the 'opengl is a target' and 'inline #ifdef for platform dependency' mentality given the following and the prolific efforts on it. the combination of the two will make it hard to make more generic... e.g. to target any graphics API in the future.
the level of abstraction is also missing to make that even easier... futureproof OO design is about abstracting the concepts generically. most of the classes here are very opengl centric... sure it can't be made 100% futureproof, but you can make something that becomes easy to port until we stop using triangle meshes (and actually... with a bit more thought even that isn't such a restriction that it needs baking utterly into the design at every level)
Raytracing or raymarching. Not sure if there are any games that use it, but raymarching is often used in the demo scene, for example here: http://www.pouet.net/prod.php?which=67433
Only if you use triangles to represent your scene. The (non-realtime) raytracer POV-Ray for example supports several other geometric shapes as an alternative: https://en.wikipedia.org/wiki/POV-Ray#Primitives
How does this compare against/differ from Ogre 3D? I'm trying to make an Entity Component System (ECS) based game engine purely for educational purposes and was looking for a graphics engine to integrate. Ogre 3D seems to be too rigid for my purpose.
21 comments
[ 3.4 ms ] story [ 46.2 ms ] threadTo be honest, I'm more and more tempted to make my own "engine" and implement just the things I need, instead of using an engine that will often have too many features I don't need.
All I really need is a camera, vertex geometry tools, and a flexible and well designed shader system (since shaders are now essentials for 3D graphics. Most of what an engine do, or should really do, is shader management).
I don't need:
* animation
* a scene manager
* sound
* inputs
* font
* texture
* physics
I'd really like an engine that only do graphics and do it well. That is what makes Ogre3D good at what it does. All I'd hope for is a data-oriented engine, instead of object oriented.
And don't forget to post it on HN in case you should publish something like that. It sounds awesome.
tldw: High performance C++ is converging on something that strongly resembles Erlang. Multiprocessing and issues with memory coherency between cores is driving this.
I don't know what Ogre3D 2.0 will look like, I did not try the RC, I don't know if it's usable without a scenemanager or scenenodes. I wish it was.
"Most of what an engine do, or should really do, is shader management"
Can you expand on this statement?
Either way what you seem to want is so minimal there's a probably a few libraries that you can use. OpenSceneGraph, VisualizationLibrary, OGLPlus, etc.
it seems a bit of shame this has the 'opengl is a target' and 'inline #ifdef for platform dependency' mentality given the following and the prolific efforts on it. the combination of the two will make it hard to make more generic... e.g. to target any graphics API in the future.
the level of abstraction is also missing to make that even easier... futureproof OO design is about abstracting the concepts generically. most of the classes here are very opengl centric... sure it can't be made 100% futureproof, but you can make something that becomes easy to port until we stop using triangle meshes (and actually... with a bit more thought even that isn't such a restriction that it needs baking utterly into the design at every level)
OpenGL is a C API. This adds a decent C++ API around it. Seems to be a decent effort.
Is this a realistic possibility? What would we use instead?
Voxels would be another possibility.