Hacker News Reader

Comment by mxmxnxor | Hacker News Reader

What about Dreams engine? It doesn't use triangles for rendering, how it fits into techniques described in the article?

I mention the Dreams in the passing - as it is such a special gem and special case that it would require much more care and analysis, probably material for multiple posts. What makes Dreams special is that it is a platform for creativity and content creation by its players. It's not a machine for making AAA products that cost 100s of millions of dollars and takes teams of hundreds people. (Also - I don't have any data nor insider knowledge despite working at Sony, but I am almost sure this project lost Sony money because of never-ending production... Which only speaks great of Sony for supporting it)

Brilliant creators of Dreams didn't care if software like Maya or 3ds Max are not compatible with their approach - as it wasn't the target audience. They didn't care for scalability of the tools, pipelines, and the renderer in terms of business practices, parallelism, finishing on time, reusing existing technology, packing with certain features. If your core feature is something unique like this, many other constraints can just go away. Is it the future of rendering? I don't think so. Btw. Media Molecule's Alex Evans (amazing person, he used to create beautiful art for demoscene) has long history of innovative rendering tech - like LBP used lots of voxel and volumetric representations (look for "Voxels in LittleBigPlanet 2" Siggraph talk) on PS3 and it also didn't catch up. Different use-cases = different constraint.

See also another example I mentioned in the post - Claybook, it uses SDFs for rendering representation (and physics!), but is also a very unique and special case.

But don't you think that Dreams engine is the sight of more superior rendering approach than current triangles pipeline and will dominate in the future? Can't we achieve more in terms of performance and flexibility if we skip triangles pipeline and do all rasterization and pixel color calculation in computed shaders? For example you don't need to carefully choose tesselation level (or spend memory for many different zoom level lods and then trying to avoid lods switching artifacts) for models and fases with many smooth curves if you can do resolution independent rasterization straight from sdf/nurbs/b-splines in realtime. And it seems like having much less overhead due to 2*2 pixel overdrawing of many triangles just for visual curve effect.

The whole point of my post was trying to answer why such approaches won't dominate (at least short and mid term, who knows long term!). :) We know "costs" of such a change - rewriting every single existing system, tool, offline software like Maya, retraining artists, figuring out from scratch how to do things like open world this new way... At the same time, do you know the benefits? Do you know if it's better, faster, have you measured it? I haven't and MM's goal also wasn't to be better or faster, IIUC the main drive was user editing content in new ways + painterly style of rendering.

And btw. artists absolutely hate modeling with nurbs, splines and anything similar. :) They love sculpting in ZBrush, or editing polys directly (for man-made and city objects). SDFs are +/- compatible with it (but come at huge memory and disk space costs - think of it this way, with meshes you encode "surface", so O(N^2) complexity, with SDFs volume, O(N^3), implicit representations not really...

I don't think this is the latest iteration of the tech, but http://advances.realtimerendering.com/s2015/AlexEvans_SIGGRA... goes into the history and R&D behind Dreams's rendering engine.

Reply on news.ycombinator.com