Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Here be dragons: the same 3D scene implemented with 10 different 3D APIs

github.com

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#41

Post by chairmanwow »

osmala wrote: post #39

A nice project, but I didn't find the license for the source code. As without one no-one can really legally use parts of it for anything that can become serious. Of course it might be that I have missed it or it is hidden somewhere. I hope it really exists somewhere in the repository, but I didn't find it. I might be too tired to find it and someone else has better luck.

After a quick search, there is no license file in this project. Whether that was done intentionally or unintentionally has yet to be determined.

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#42

Post by ocdtrekkie »

madez wrote: post #35
ocdtrekkie wrote: post #33

When I was in school, I had an assignment to make the same super simple scene in OpenGL and DirectX. That was when I learned I didn't want to be in a career field that would have me using DirectX.

Would you mind explaining in more detail why you didn't like using DirectX? When I was reading up for some games if they would get an OpenGL version, I was reading more than once that OpenGL were a mess.

It was a really simple project, like a couple of colored rotating triangles. I think it was like... maybe 10 short lines of code for OpenGL, and over 50 to do it with DirectX.

Of course, I can't speak for how hairy OpenGL might get at doing more advanced features, and of course, in a lot of cases games are built on established game engines which do most of the DirectX and/or OpenGL coding for them.

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#43

Post by greggman »

pierrec wrote: post #27

This is a really useful codebase to compare what the code looks like for different APIs and the tooling around each (not so much for directly comparing the graphics, which should go without saying, but a lot of people seem to be missing the point here...) It would be interesting to add an emscripten version, ie. slight modifications to the original C++/OpenGL code to make it compile with emscripten and run in the bro…

If you target WebGL2 you can likely do it without hand modifying the shaders. In a small test I did I just patched the emscripten library_gl.js to do a very simple search and replace of the version string of shaders and stuff just worked.

code: https://github.com/greggman/doodles/tree/master/glfw-imgui

demo: https://greggman.github.io/doodles/glfw-imgui/out/glfw-imgui...

You do have to decide if you want to restructure you code to be event based or if you want it leave it as is and set emscripten to generate really slow code for your main loop

https://kripken.github.io/emscripten-site/docs/porting/emter...

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#45

Post by golergka »

Mikeb85 wrote: post #11

Very interesting. What's striking is how much better the OpenGL version looks than everything else. Not sure if it's because that was the reference version or if some of the other APIs require more work or the dev is simply unfamiliar with them. The Cycles renderer creates some really cool looking materials on the dragon, but the terrain doesn't look great. The Metal version in particular looks terrible, but then aga…

Do you think it's better than Unity's codeless solution?

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#46

Post by sipos »

Mikeb85 wrote: post #13
sipos wrote: post #5

The Vulkan version will really add a lot I think. I would guess most people are most interested in an OpenGL to Vulkan comparison. Similarly (possibly more interesting to people, I don't know?) the DirectX version. Nice comparison.

Will it? Vulkan is meant as a low-level version of OpenGL for vendors who want to optimise their engines and have more control over draw calls and whatnot. Does it actually add any features that will be noticeable in a small, static scene?

Visually, no - it should look the same. For comparison of the code, it will be interesting, even if it doesn't necessarily show everything you can do with Vulkan and DirectX (which has some similar low-level features in recent/latest? version).

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#47

Post by masklinn »

sipos wrote: post #5

The Vulkan version will really add a lot I think. I would guess most people are most interested in an OpenGL to Vulkan comparison. Similarly (possibly more interesting to people, I don't know?) the DirectX version. Nice comparison.

Shouldn't it be fairly similar to the Metal version, which is basically Apple's Vulkan/Dx12? (IIRC Metal is more between OGL and Vulkan, it does more hand-holding and implicit than Vulkan, but way less than OGL)

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#48

Post by dark_ph0enix »

chairmanwow wrote: post #41
osmala wrote: post #39

A nice project, but I didn't find the license for the source code. As without one no-one can really legally use parts of it for anything that can become serious. Of course it might be that I have missed it or it is hidden somewhere. I hope it really exists somewhere in the repository, but I didn't find it. I might be too tired to find it and someone else has better luck.

After a quick search, there is no license file in this project. Whether that was done intentionally or unintentionally has yet to be determined.

It's worth noting that the author just added a license (MIT) to the repo.

Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs

#49

Post by exDM69 »

ocdtrekkie wrote: post #42
madez wrote: post #35

Earlier quoted context omitted.

Would you mind explaining in more detail why you didn't like using DirectX? When I was reading up for some games if they would get an OpenGL version, I was reading more than once that OpenGL were a mess.

It was a really simple project, like a couple of colored rotating triangles. I think it was like... maybe 10 short lines of code for OpenGL, and over 50 to do it with DirectX. Of course, I can't speak for how hairy OpenGL might get at doing more advanced features, and of course, in a lot of cases games are built on established game engines which do most of the DirectX and/or OpenGL coding for them.

You've hit the nerve there.

OpenGL has so much implicit state and "defaults" set for you that you can get a "hello world" -style app done really quickly, but then it all falls apart.

And if I'm guessing correctly, you probably used legacy, fixed function OpenGL (ie. no shaders) with immediate mode rendering (glBegin/glEnd). Because you can't do anything in 10 lines with modern OpenGL.

As soon as you start doing something practical, you start fighting OpenGL all the time. It's a badly designed, very error prone API that requires much more developer effort than any of the competing APIs.

If you apply best practices to OpenGL code (don't rely on global, implicit state, use shaders/buffers/etc) , it's about on par with the "lower level" APIs.

My OpenGL boilerplate code and my Vulkan boilerplate code have about the same number of lines of code in them while they do about the same things (create rendertarget, framebuffer, clear the screen, draw some text, draw a triangle, blit to screen, measure performance counters). OpenGL is a bit less by a small margin, but the difference is only in the verbosity of Vulkan code (ie. you have to explicitly type every single pipeline state, even if it doesn't matter, e.g. depth test mode when depth test is disabled).

In my opinion the bottom line is this: Vulkan is verbose but OpenGL is complex. I'll take verbosity over hidden complexity any time.

Post reply on HN