Here be dragons: the same 3D scene implemented with 10 different 3D APIs
21–30 of 67 posts
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#22I someone has time, could you record each one of these, splice the videos together and upload it, so we can compare them, without actually installing each one?
There are screenshots in each of the directories in the project.
Laziness squared... got it.
(lazy they didnt have a gallery already ready... lazy that (we) the readers dont ant to click through to each pic..
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#23Earlier quoted context omitted.
> the terrain The OpenGL version looks really aggressively bump mapped. The Cycle's version doesn't appear to have any bump mapping enabled. Edit: The depth of field in the Cycle's version also looks a bit weird, and blurs away most of the terrain's detail.
The OpenGL version is using parallax mapping, where the pixels of the flat plane are rendered by ray-marching into a depth map: https://github.com/kosua20/GL_Template/blob/3de4e116cdd24df3... The cycles version, on the other hand, is actually using the depth map to displace a high-res mesh -- a more general technique that should yield results as good or better than parallax mapping. I'd chalk up any perceived differe…
Im making over $7k a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do, ＡＭＡZＩＮＧ ＪＯＢＳ
----->>http://www.smartfinancemedia.com/?682
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#24Earlier quoted context omitted.
There are screenshots in each of the directories in the project.
Laziness squared... got it. (lazy they didnt have a gallery already ready... lazy that (we) the readers dont ant to click through to each pic..
Not to accuse anyone of laziness, but on mobile the UI is clearly not optimized to see the comparisons, assuming that wandering the directories is the intended method.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#25The 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?
No, but quite a few people who are familiar with OpenGL are interested in learning Vulkan, and it's really educational to have a side-by-side comparison of the same scene.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#26I am not an expert in some of these, but I CAN tell you that both GBA and DS can do much better than the author has done here.
The GBA could definitely do a real 3D engine but it wouldn't look very good at the low resolution anyway. I remember a demo from back in the day of a Quake-like 3D engine on the GBA but it really didn't look good. For the DS, note that he seems to be targeting the original DS (e.g. not DSi OR 3DS). I remember there being some slightly better stuff but not significantly better than what he made.
It looks much worse than my imagination accredited for - but Metroid Prime Hunters was a beautiful DS game:
http://www.ricedigital.co.uk/wp-content/uploads/2013/05/hunt...
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#27This 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 browser. After some fooling around I got that to work, however nothing shows up because the shaders need to be rewritten for WebGL. Looks like this was already done for the JS/WebGL version, but the shaders are less fancy and clearly don't map 1-to-1 to those in the C++/OpenGL version, so the code will need to be modified a bit either way.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#28I am not an expert in some of these, but I CAN tell you that both GBA and DS can do much better than the author has done here.
The GBA could definitely do a real 3D engine but it wouldn't look very good at the low resolution anyway. I remember a demo from back in the day of a Quake-like 3D engine on the GBA but it really didn't look good. For the DS, note that he seems to be targeting the original DS (e.g. not DSi OR 3DS). I remember there being some slightly better stuff but not significantly better than what he made.
I just ran the DS version on my DS lite, it looks pretty good - definitely comparable to games on the system, and the models seems more detailed then most of what you see on the system. The screenshots just make it look horrible because it's a fairly low-res screen, when you blow it up that big it looks a lot worse then you'd expect. The monkey shadow is definitely iffy looking, but I don't think any games ever did 3D shadows that detailed - there's probably a reason for that. It is worth keeping in mind that the original DS is weak (especial 3D wise), but it's not really that bad considering the low resolution it has to render for. That low resolution is the main reason why it looks so bad in the screenshot though.
The GBA version also looks pretty good on my DS lite (compared to games on the system). You can't rotate the camera though, so the dragon doesn't rotate. The monkey-head rotates on it's own though and looks pretty good. You're right that there are a few games that do 3D on the GBA, but I can't imagine it's fun coding wise since it the hardware support is basically zero in that regard. But there are some weird ones out there - Banjo Pilot comes to mind, which is a weird mode-7 3Dish flying game. Not exactly a great game, but pretty cool to see. Even with that game though, they have to sacrifice basically all terrain to be able to render the other characters at a decent speed IIRC, so the entire game is just flat.
And if you want to get really obscure, there is Faceball 2000 on the GB, which is a "FPS" and is 3D (And runs at like 15 FPS IIRC). There's no way you could render this scene on it though besides just pre-rendered sprites like was done with the GBA.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#29Why is one of the examples called "Unity"? Doesn't Unity just use the lower level rendering APIs or am I missing something?[1][2][3]
[1] https://docs.unity3d.com/Manual/UsingDX11GL3Features.html
[2] https://blogs.unity3d.com/2016/09/29/introducing-the-vulkan-...
[3] https://blogs.unity3d.com/2015/02/19/unity-4-6-3-metal-rende...
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#30Why is one of the examples called "Unity"? Doesn't Unity just use the lower level rendering APIs or am I missing something?[1][2][3] [1] https://docs.unity3d.com/Manual/UsingDX11GL3Features.html [2] https://blogs.unity3d.com/2016/09/29/introducing-the-vulkan-... [3] https://blogs.unity3d.com/2015/02/19/unity-4-6-3-metal-rende...
WebGL is ultimately translated into OpenGL calls. OpenGL calls are ultimately translated into bytes sent over the bus to the graphics card. It takes a lot of level descending before you reach the ground floor :-)
Unity is there, I imagine, because it's interesting to see how it translates code that expresses high level concepts like "meshes" and "materials" into code for to the backend, compared to the hand-written OpenGL or DX or Metal or whatever calls.