I don’t think my opinion has changed that much – but it wasn’t meant to be that negative either. My point is _not_ that Euclideon’s work is bad, lame, fake, or anything like that – only that the existing polygon-rendering “establishment” is a moving target, and it’s really moving quickly!

In particular, to me the big question is: will point rendering be enough of an improvement once displacement-based tessellation is wide-spread? Bruce Dell is absolutely right that displacement tessellation is not the same as an arbitrary geometry budget with smooth LOD fall-off. But I’m not sure how much that will actually matter for production games.

The devil will be in a bunch of details we don’t have:
– How does their rendering system interact with existing material systems and other key rendering-pipeline tech (e.g. screen-space effects, deferred rendering, lighting volumes, etc.).
– How well does it run on GPGPU hardware.
– How good is the compression ratio – in the end, the difference between point-search and multiple polygon meshes is storage efficiency. I feel a bit stupid saying that because multiple polygon meshes is a _lousy_ way to make continuous LOD (hence the interest in displacement tessellation) but still, if we had infinite machine resources we surely wouldn’t care.

And of course, I am totally sympathetic to a small number of programmers trying to do something a bit at odds with the “standard” design of the industry on a shoe-string budget…if they want to go hide and get work done, I can never ever fault them for that! 🙂

you can find it at:
HARDOCP Interview and demo show

http://www.hardocp.com/article/2011/08/10/euclideon_unlimited_detail_bruce_dell_interview

That actually sort of exists.
http://www.slideshare.net/DICEStudio/siggraph10-arrrealtime-radiosityarchitecture
See around slides 12 or so.
But since we’re not doing anything that’s vertex constrained (our lighting is all on the GPU and all screen space/deferred – we’re not trying for radiosity yet) we don’t need to reduce vertex count. If we can afford to save the detailed meshes at all (since RAM is the issue) we can easily afford to light them.

Thanks for explaining that. It is a fascinating process, and highly creative, in the original sense!

We already have pretty accurate terrain, but having full roads and rivers will make it easier to find one’s way around.

As far as lighting goes, you might be able to get away with approximating it in a lot of cases.

Even if this turned out to be the best thing since sliced bread, you’d still almost certainly need to retain some underlying, lower resolution meshes for other purposes, such as collision detection. It’s just a thought off the top of my head, but perhaps you could take the polygonal data from those meshes, calculate the lighting on them, and maybe apply some Phong shader or something. Then, using a depth map, blend the shading data onto the rendered scene.

I’m not really sure how well that would work, but it sounds good in my head!

That wouldn’t help. The input data for the global scenery is currently 69 GB, after zip compression – that is, it’s larger than the final scenery. As OSM grows, this will get even worse. (We might get slightly better ratios with 7zip but it’s still moot.) The scenery creation program took three days to run on an 8-core Mac Pro last time around, and may take quite a bit longer this time. The scenery creation program also requires a Unix environment, which hoses Windows.

Cool. Thanks for your reply.

I wonder though if the install program could generate the .dsf files from the raw 2d data, textures and objects?

Could this be a way of getting much more detail onto 6 DVDs?

The GPU cannot do this. Even if we could, the data wouldn’t fit on one DVD.

Could this be the direction for x-plane 11 with the next generation of graphics cards?

Any time the source mesh isn’t actually a mesh (e.g. it’s a nurb or height field) and the “refinement” from source data to mesh is on the GPU, then yes you can scale nicely.

Until relatively recently, this kind of refinement on the GPU wasn’t possible, hence Euclideon can take pot-shots at older games with their square trees.

But if the artist creates a mesh (and not some source format like a nurb or a height field that becomes a mesh) then re-evaluating the mesh to change LOD becomes extremely expensive. In other words, if you want to build the mesh with variable LOD on the fly, you really need an input data format that is amenable to doing that in real time; this means changing the tool chain for art assets in an extensive manner.