Hacker News Reader

Comment by Mikeb85 | Hacker News Reader

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.

View on HN

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.

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.

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

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

I would say the later, either unfamiliarity with the hardware/software or time constraints because the PS2 is capable of much better than what is shown here.

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

Unity has a rendering pipeline coded for you, using DirectX or OpenGL, depending on platform and settings.

Isn't the point of this repo to compare the usability of different developer tools?

Not really. The Readme says this:

"This repository contains multiple implementations of the same 3D scene, using different APIs and frameworks on various platforms. The goal is to provide a comparison between multiple rendering methods. This is inherently biased due to the variety of algorithms used and available CPU/GPU configurations, but can hopefully still provide interesting insights on 3D rendering."

It's a mixed bag of APIs, software, hardware and tools, approaching the rendering in very different ways. There's even an offline renderer (Blender Cycles) and a software real time renderer in the repo.

> The goal is to provide a comparison between multiple rendering methods.

Well, isn't usability the most important criteria to compare it on?

No, one of these methods takes seconds to minutes for a frame to render. One takes a lot of CPU and a bunch are letting the GPU doing the work. Not to mention that a few examples run och very specific hardware only (PS2, GBA etc).

It seems like they actually

Reply on news.ycombinator.com