
Magnum: C++11/C++14 and OpenGL Graphics Engine - adamnemecek
https://github.com/mosra/magnum
======
jokoon
I'm waiting for Ogre3D 2.0 to be released.

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.

~~~
xyience
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.

~~~
Narishma
The ones I know of are proprietary and used on AAA console games.

~~~
xyience
Do any of the companies have blogs or GDC talks where they discuss bits of it?

~~~
corysama
This talk from Naughty Dog was really good.
[http://www.gdcvault.com/play/1022186/Parallelizing-the-
Naugh...](http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-
Engine)

tldw: High performance C++ is converging on something that strongly resembles
Erlang. Multiprocessing and issues with memory coherency between cores is
driving this.

------
bluesilver07
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.

------
partycoder
With the advent of Vulkan I would like to see if there are intentions to
support it in future releases.

------
jheriko
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)

~~~
n00b101
> until we stop using triangle meshes

Is this a realistic possibility? What would we use instead?

~~~
Kristine1975
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](http://www.pouet.net/prod.php?which=67433)

~~~
pixel_fcker
Umm ray tracing is still triangles.

~~~
Kristine1975
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](https://en.wikipedia.org/wiki/POV-Ray#Primitives)

Voxels would be another possibility.

