It might be a very good tech for games if used right (by talented devs). But nobody knows as Euclideon are not telling enough about their tech. They are also not game developers, so they don't know how to market for game developers. We don't care about PR bullshit. We want to know exactly how every piece of tech we integrate works, especially all the limitations. Every veteran programmer in games tech industry has burned their fingers multiple times by chasing perfect tech only to later notice a "minor" shortcoming that invalidates an otherwise good idea completely. I believe many of us would also be interested to know whether their algorithm could be ported to GPUs. This could make it much more viable. Their performance is pretty good on CPU (albeit only for primary rays), but how well does it parallelize to millions of SIMD lanes.
That's where they completely contradict themselves. Other devs, stuck with their stone-age ideas of triangles, spend hundreds of man hours creating triangle based assets, whereas Euclidon has invented SolidScan that enables one guy to get photorealistic assets in no time at all. They showcase it in the video, photorealistic environments captured from the real world. Having boasted how awesome their asset creation is, how then do we justify their crap game art?
In the second video I posted, in minute 11 you can see some animated animals with specular lighting.The biggest flaw in those captured forest scenes is the complete lack of specular lighting. Every material has some specular. Not only shiny ones. Id-Software's Rage had the same problem with fully baked lighting (remember, it was a 60 fps game on Xbox 360 and PS3).
If Euclideon could scan normal maps and extract material properties (specularity, roughness) from the surfaces the results would look significantly better. Also these scenes are very small. Super low resolution background is just a few meters away. Unique scanned geometry takes just too much storage space for big environments. Scanning and storing a single tiny forest would take terabytes. Imagine now much storage Everquest or WoW game world would take
Normal information is stored so you know the surface normal per pixel.
Gamestop/GAME/Walmart should partner with Sony to brings its new 3.3TB storage optical medium to Xbox and PC gamers. Then support developers who utilize datapoint rendering and this drive to combat the rise of digital games taking it marketshare.The biggest flaw in those captured forest scenes is the complete lack of specular lighting. Every material has some specular. Not only shiny ones. Id-Software's Rage had the same problem with fully baked lighting (remember, it was a 60 fps game on Xbox 360 and PS3).
If Euclideon could scan normal maps and extract material properties (specularity, roughness) from the surfaces the results would look significantly better. Also these scenes are very small. Super low resolution background is just a few meters away. Unique scanned geometry takes just too much storage space for big environments. Scanning and storing a single tiny forest would take terabytes. Imagine now much storage Everquest or WoW game world would take
Thank you for the explanation.
Yes, you can obviously reconstruct surface normal from geometry if your scanned data is dense enough. We do it as well in our renderer. But normal + albedo is not enough for high quality PBR lighting. You need a rgb specular map (esp for non-dielectric materials such as metals) and a roughness map (or two for anisotropic specular). More complex materials need even more data.
Rage also had dynamic lighting only for moving objects. Static scenery had baked lighting with no specular ("printed cardboard" look). Dynamic objects looked sometimes out of place. These problems were OK for last gen 60 fps console game. A modern lighting pipeline needs unfied lighting model that applies the same lighting data to all surfaces. Specular occlusion is also very important. Otherwise objects seem to float (geometry is not blocking specular reflections). I am just wondering how well Euclidion's tech is suited for querying specular occlusion (spatially varying query points with highly incoherent direction).
Yeah, I remember that.
I wonder the same... If Euclideon's tech has room for improvement (or maybe a hybrid solution) or if the limitations are in the very roots of it.
The thing that bugs me is that I don't know. Euclideon's structure might be a perfect data structure for incoherent ray queries or it might be very bad data structure for it.
It almost takes on a different meaning.
Yes. There are many methods for baking the view-angle-dependent radiance distribution. SGs are one way. Spherical harmonics (lightmaps or volumes) are another. One of the earliest methods was called "Radiosity normal mapping" and was used in Valve's source engine (http://www.valvesoftware.com/publications/2006/SIGGRAPH06_Course_ShadingInValvesSourceEngine.pdf). They store 3 lighting values per surface pixel. Each stores different incoming lighting direction. At runtime these 3 lighting samples are interpolated based on view to surface vector. This is pretty good already, and only 3x uncompressed storage cost (it compresses pretty well, so real storage cost is not 3x higher).
