Hacker News Reader

Comment by kayoone | Hacker News Reader

Isn't this more or less a problem of the past?

Today with tools like Unity3d, UDK, CryEngine, Shiva Engine, MonoGame etc, game developers are at a point where they can pretty much stop worrying about the OpenGL/DirectX layer beneath their engines. Those Engines have become so powerful and affordable that it hardly makes any sense to roll your own. In fact, imo you would need a very strong reason to build your own engine these days instead of focusing on your product.

Soon all of these will support WebGL/HTML5 as a target and even render most of the (still very basic) WebGL engines obsolete.

Now if you were in the business of creating your own tools or engine, you would need to support both of OpenGL and DirectX to be able to support all the major platforms anyway.

View on HN

> Isn't this more or less a problem of the past?

Yes and no.

If you want to be writing a typical 3d game like an FPS, and RTS or 3rd person platformer, you can and probably should use an off the shelf 3d engine and stay away from the lower level APIs, OpenGL and d3d.

However, if you want to do something more exotic, say processing your webcam input stream with your GPU, or write a space scale render of the solar system or do anything that diverges from the use cases you typically use 3d engines for, you might still be better off using D3D or OpenGL directly.

Then there are aspiring future game engine programmers and hobbyists who want to use OpenGL directly. It's arguably more interesting than paying for a 3d engine but it's more work of course.

So most people do not need to touch D3D and OpenGL, in the same way that most people do not need to write C. But some people must and some people want to.

Sure, they are some edge cases where it might make sense, but even then i would analyze requirements very carefully. I have quite a bit of experience with Unity3D and besides being really simple to use you can basically extend it with any C#/C++ library that you see fit. Support for Webcam input streams is there out of the box and id argue theres hardly anything it cant do.

Of course, if you want to be (or are) an engine programmer, go for it and get your feet wet using OpenGL/DirectX, but for the broad mass of game developers, these aren't issues anymore.

Playing with it directly can be fun yes, but it can also be frustrating if all you want is so much easier with a game engine.

Not sure I would call it an edge case. It's really a use case. These days, there are many developers who use the GPU for other things than plain vanilla 3D graphics. If there was ever such a thing.

I'm doing a combination of scientific and practical computing, and I'm currently in the middle of the choice of whether to use DirectX or OpenGL. Portability counts, but so does simplicity. It's a very relevant question.

> Sure, they are some edge cases where it might make sense, but even then i would analyze requirements very carefully. I have quite a bit of experience with Unity3D and besides being really simple to use you can basically extend it with any C#/C++ library that you see fit.

Sure, Unity3d is very flexible and has given us some outstanding games. Like Kerbal Space Program, for example. KSP has quite a bit of modifications to make Unity3d work for them, they have had to do some black magic to make Unity3d work in space scale scenes on both, the physics and graphics departments.

When looking at dev talks given by the KSP team, it begs the question whether or not they would have been better off not using Unity at all and doing a specialized engine from scratch. There's no real answer to this question and Unity probably made their time to market shorter so they could actually ship and sell the game to keep the development alive. And then they went on later to rewrite a lot of the stuff they did early on.

But from a purely software engineering standpoint, they might have been better off not using an off the shelf 3d engine, because there are no space scale 3d engines available.

Again, for most people it makes sense to pick up an engine and go with it but there are use cases where it might pay off to invest the time and effort to build your own tech from scratch.

Hindsight on projects is 20/20, and you can't discount the productivity boost that using something that let's you focus on the game straight away gives you.

I know KSP lead designer, they use Unity because of him, he is not a programmer, and knew only how to code more or less with Unity, that he learned on university ( I was student with him ), now they have professional coders, but kept Unity for legacy reasons ( that is: they already started on it, so keep it...)

Actually, RTS games are also a hard problem for engines because they require a lockstep shared-state for multiplayer. This means you need a very high level control of the language your game-logic is built in to make sure your floating-point calculations are identical across all devices and everything is perfectly deterministic. This is a problem for "complete-platform" cross-platform engines like Unity.

Lockstep simulation isn't required--though it was a popular solution.

What is the alternative and more popular solution used now?

Abandoning online multiplayer completely.

Ouch, harsh.

Anyways, client-server works fine.

I thought I'd provide an anecdotal supporting example to show that there are valid exceptional use-cases that don't practically fit into a pre-existing 3D engine -- specifically, a 3D visualization of a space-scale procedurally generated universe with trillions of stars and planets.

Several times I tried expanding an existing modular 3D engine (OGRE) towards my goal of displaying a huge virtual universe of planets and stars. While I got it rendering 3D planets after some work (where I basically had to implement manual rendering code anyway, since the engine didn't support the odd use-case of spherical terrain), contorting it to support massive coordinate spaces, huge view ranges, dynamic loading/unloading etc. was just far too messy to even hope to attempt in that engine.

After several attempts to cleanly implement a space-scale engine as an extension of an existing engine, I started over from scratch using pure OpenGL (WebGL). And this time, I managed to keep the code reasonably tidy while supporting trillions of stars, planets etc. as I had originally planned [1].

Would I have been able to do the same thing in OGRE if I kept trying? Probably... but likely with far more ugly code, terrible hacks, bloated engine, and slower loading times.

To be fair, I'm not advocating always "rolling your own" 3D engine. It's usually a huge task, and using a pre-existing engine will in almost every case be the smarter choice. But with some people trying to argue "you can make it fit in [Unity/OGRE/etc]", I thought I'd provide at least one anecdotal counter-example.

1. Kosmos: A virtual 3D universe in your web browser (https://github.com/judnich/Kosmos)

> Soon all of these will support WebGL/HTML5 as a target and even render most of the (still very basic) WebGL engines obsolete

Uh, most of those have their core runtime engine written in C++ and are probably not itching to port their CPU-side code to JavaScript.. Porting to WebGL is only trivial for the GLSL shaders, nothing else. If anything, these companies are waiting and holding out for either PNaCl/ASM.js/Emscripten to be able to generate fast fully-working web-compatible engine code.

And those engines aren't just loading 3D models and blit them to the screen, at least that's not their selling point. They have their occlusion culling system .. particle systems .. animations .. hardware audio .. fake wind simulation .. rudimentary pathfinding .. a reasonably fast terrain renderer .. some physics engine intimately integrated into the whole thing.

You wanna port all that to JS? Go right ahead!

Well i was referring to ASM.JS/PNaCL ports as we have already seen possible with Unreal Engine. Its a matter of cross compiling today, not porting to JS.

Of course there will still be usecases for Three.js and the likes, for more lightweight WebGL integrations. But full blown HTML5 games will pretty soon be possible through these engines. Unity3D already had a pretty feature complete Flash export and i am very sure they are already working hard on a html5 target option.

> You wanna port all that to JS? Go right ahead!

It is already done. https://github.com/kripken/emscripten/wiki

It's going to be an interesting race between the Web-native engines and the emulated C++ ones. Some of the WebGL based platforms have come pretty far already, eg. Turbulenz.

The Emscripten based competition only have a few tech demos so far and the possible coming of PNaCl outside Chrome doesn't look that probable at this point.

If you use pNaCl, you can have an Emscripten fallback.

> Isn't this more or less a problem of the past?

You are using Unity 3D, so NO, it's not a problem of the past. You have multiplatform because Unity developers decided to go with OpenGL.

Reply on news.ycombinator.com