The Metal version in particular looks terrible, but then again low level APIs like Metal, Vulkan and whatever subset of Direct X are all meant for vendors, not individual developers.
Here be dragons: the same 3D scene implemented with 10 different 3D APIs
11–20 of 67 posts
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#12Very 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…
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.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#13The 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.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#14Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#15Very 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…
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#16Very 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…
Actually, if continue under this world with unlimited developer resources, the Cycles version should look the most realistic. It's markedly different than any of the other renderers included in this list because it's an offline path tracer whereas Unity and friends are for real-time rendering. We rely on a lot of hacks (Phong shading, FXAA, normal mapping) to produce an interactive 3D scene at 30+ FPS, but once you remove the real-time constraint, we can apply a lot of very fancy algorithms to more realistically render your scene. Cycles might take minutes or even hours to render a single frame, but it spends this time on a whole host of involved computation (physically-based BSDFs, Monte Carlo integration, Metropolis light transport, etc) that more accurately model how light interacts with materials.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#17I 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.
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.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#18The 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?
So, in practice, if they are noticeably different in the dynamic case, you'll see those differences in the "as if it were dynamic" case, which is most graphics demos of this sort.
Re: Here be dragons: the same 3D scene implemented with 10 different 3D APIs
#19Very 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…
> 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.
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 differences to lighting and material parameters.