Live data from Hacker News

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

github.com

11–20 of 67 posts

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

#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 again low level APIs like Metal, Vulkan and whatever subset of Direct X are all meant for vendors, not individual developers.

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

#12
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…

> 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.

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

#13
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?

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

#15
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…

OpenGL has a ton of implicit state. This makes the code look simple, but it's actually very hard to work with, as you always have to be aware of what the current state is. Other APIs are require explicit handling of state (Vulkan takes this to an extreme) which is more verbose, but actually easier to work with.

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

#16
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…

Theoretically, the OpenGL, WebGL, Vulkan, Metal, and Unity implementations can all have comparable quality with enough dev work. From a quick glance through the README, it doesn't seem like the OpenGL implementation is relying on any cutting-edge features of the specification, so everything can be ported to WebGL as well. If anything, the Vulkan and Metal versions have higher "potential" when compared to older APIs like OpenGL because if you optimize with the lower level primitives, you'll have more cycles for complex rendering techniques. Also, I'd argue that Vulkan can be used by individual developers because there are already a bunch of games that have Vulkan support: https://en.wikipedia.org/wiki/List_of_games_with_Vulkan_supp...

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

#17

I 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.

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

#18
post #13
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?

The difference between a moving and a static scene is surprisingly small: in one case you render a slightly different scene every frame, and in the other you re-render the same scene every frame. But the pipeline is set up the same, with the same shaders, the same rendering passes, etc.

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

#19
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…

> 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 differences to lighting and material parameters.

Post reply on HN