Magnum: C++11/C++14 and OpenGL Graphics Engine | Hacker News Reader

Magnum: C++11/C++14 and OpenGL Graphics Engine

github.com

64 pointsadamnemecek20 comments

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.

Do so! Especially if you can learn a thing or two. Using bloated engines isn't always the best solution anyway, and yoi seem to be well aware of that.

And don't forget to post it on HN in case you should publish something like that. It sounds awesome.

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.

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

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

This talk from Naughty Dog was really good. http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh...

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

Not really. Although I heard Mike Acton was asked to fix Ogre3D Node class, and it resulted in a 5x speedup (in a video linked on HN).

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.

The stingray engine seems to be data-oriented using the Entity Component Systems pattern. Their blog is an excellent read - http://bitsquid.blogspot.in/. This is the first post in a really good series about data oriented entity systems - http://bitsquid.blogspot.in/2014/08/building-data-oriented-e...

bgfx sounds like what you're looking for: https://github.com/bkaradzic/bgfx

The samples are pretty scary. Seems like a nice engine though.

If you want minimal you could always use something like glfast https://github.com/procedural/glFast

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.

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

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)

These days bgfx solves this problem. Why run around when you can target all graphics APIs at once.

Actually, I'm happy to see that this author didn't give into the temptation of making a "one ring that rules them all" abstract design.

OpenGL is a C API. This adds a decent C++ API around it. Seems to be a decent effort.

> until we stop using triangle meshes

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

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

Umm ray tracing is still triangles.

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

Voxels would be another possibility.

Reply on news.ycombinator.com