Live data from Hacker News

Exploring Euclideon's Unlimited Detail Engine

gameinformer.com

31–40 of 93 posts

Re: Exploring Euclideon's Unlimited Detail Engine

#31

As soon as I see animated objects moving about in a dynamically lit world, I will start to believe that Euclideon is on to something. Maybe there could be some middle ground like in the old voxel days, where you would have a static (unlimited detail) background world and some traditional, polygon-based actors in the foreground. Looking at any modern game, just about everything on the screen is constantly moving, so c…

Not sure if you want to SEE it. But in the article it says they are doing just that.

.

"Dell shows me an as yet unreleased demo – not real-time in this case – that suggests Euclideon has already made some positive inroads in ensuring Unlimited Detail is compatible with existing middleware. The short video shows traditional polygon objects happily coexisting and interacting in the same space as a small Unlimited Detail environment"

Re: Exploring Euclideon's Unlimited Detail Engine

#32

As soon as I see animated objects moving about in a dynamically lit world, I will start to believe that Euclideon is on to something. Maybe there could be some middle ground like in the old voxel days, where you would have a static (unlimited detail) background world and some traditional, polygon-based actors in the foreground. Looking at any modern game, just about everything on the screen is constantly moving, so c…

Collision detection is the big thing for me, sure you can fake it with invisible polygons but that usually leads to weirdness in the player experience.

Re: Exploring Euclideon's Unlimited Detail Engine

#33
post #30
post #26

Earlier quoted context omitted.

> It's actually the reverse! Voxels make it easy to figure out what's on screen and what's not. No no, I explicitly said "ahead of time". It's easy to determine what's on screen when you're about to render the frame, but you have to load every single object in memory because every single object is a "candidate" that may end up on the screen, you just don't know ahead of time. You can't cull the voxel tree, even thoug…

Can't you still have a normal octree or something with segments of the voxels split by their spatial location with voxel subtrees inside of that? I don't understand why you can't apply spatial division techniques to voxels.

I don't think it would accomplish much. But sure, you can precompute which objects are visible in which circumstances and do some culling based on that data.

My understanding is that the problem is that there's just too much stuff that you have to keep in memory if you don't use LoD to distinguish between nearby and far away objects.

Consider this screenshot from rage: http://pcmedia.ign.com/pc/image/article/116/1162072/rage-201...

What are you going to cull? There's just too much stuff to load in memory. Too much stuff that actually ends up on your screen. Too much point cloud data. Now games use low resolution models and prerendered billboards for far away objects. With a voxel octree you're just SOL, no matter how clever your spatial optimizations.

Unless hard drives (or SSDs) become a few orders of magnitude faster I don't see how the data can be fetched from disk quickly enough.

Re: Exploring Euclideon's Unlimited Detail Engine

#34
post #13

Interesting article. Judging by Dell's (the CEO) calm attitude towards "haters", I personally believe that he truly has something revolutionary to offer. Only time will tell though.

How is that indicative of anything but a thought-out publicity strategy?

If one were in the perpetual-motion machine business, taking a calm attitude towards haters would be pretty much the only option, since there would be no way to argue with them.

Re: Exploring Euclideon's Unlimited Detail Engine

#35
post #17

Earlier quoted context omitted.

But if the resolution of your grid is smaller than the size of the voxel, that wouldn't matter much - and you could keep rounding errors in check by anchoring larger units of voxels at a certain location in space. I can see the drawbacks of the voxel cloud approach (requires much memory, what algorithm is fast enough to do voxel culling on such a massive amount of data, what about animation) but the 'can't do rotatio…

I'm not saying it is entirely impossible. However, rotating volume data (which voxels are) is computationally a lot more intensive. With polygonal objects you can just change the transformation matrix and re-render the screen and you're done. At most, you have to deform the vertices that make up the outer shell of the object to do things like make a person walk. With voxels, you'd have to recompute all the voxels of…

I'm still not convinced by these arguments ;)

The displacement of the voxels can also be done with a simple matrix transformation, as far as I see it; same like you'd do for the nodes in a 3d model, same as you'd do it with a 'traditional' 3d pipeline (OpenGL/DirectX) - unless I'm behind the curve and animation itself is done on the GPU nowadays, but I don't think it is.

Ragged boundaries wouldn't be an issue as long as there are enough voxels. What I understand, that's the whole point - you just have lots and lots of voxels, at a much finer resolution than you'd ever want to render at, so that you just (by brute force) render once without having to worry about anti-aliasing, gaps between planes etc.

Re: Exploring Euclideon's Unlimited Detail Engine

#36
The article sensationally positions this as some incredible breakthrough that the "old guard" of gaming is trying to suppress. More likely, the code works, but has limitations -- the same limitations that led old guard luminaries like Carmack to defer the idea for another few years.

As others have pointed out, voxel-based games have been around for a long time; a recent example is the whimsical "3D Dot Game Hero" for PS3, in which they use the low-res nature of the voxel world as a fun design element.

Voxel-based approaches have huge advantages ("infinite" detail, background details that are deformable at the pixel level, simpler simulation of particle-based phenomena like flowing water, etc.) but they'll only win once computing power reaches an important crossover point. That point is where rendering an organic world a voxel at a time looks better than rendering zillions of polygons to approximate an organic world. Furthermore, much of the effort that's gone into visually simulating real-world phenomena (read the last 30 years of Siggraph conference proceedings) will mostly have to be reapplied to voxel rendering. Simply put: lighting, caustics, organic elements like human faces and hair, etc. will have to be "figured out all over again" for the new era of voxel engines. It will therefore likely take a while for voxel approaches to produce results that look as good, even once the crossover point of level of detail is reached.

I don't mean to take anything away from the hard and impressive coding work this team has done, but if they had more academic background, they'd know that much of what they've "pioneered" has been studied in tremendous detail for two decades. Hanan Samet's treatise on the subject tells you absolutely everything you need to know, and more: (http://www.amazon.com/Foundations-Multidimensional-Structure...) and even goes into detail about the application of these spatial data structures to other areas like machine learning. Ultimately, Samet's book is all about the "curse of dimensionality" and how (and how much) data structures can help address it.

In the late 90s at Naughty Dog, I used Samet's ideas (octrees in particular) for collision detection in the Crash Bandicoot games. In those games, the world was visually rendered with polygons, but physically modeled -- for collision detection purposes, at least -- with an octree. The nice thing about octrees is that they are very simple to work with and self-calibrate their resolution dynamically, making them very space-efficient. Intuitively, a big region of empty air tends to be represented by a handful of huge cubes, while the individual fronds of a fern get coated with dozens or hundreds of tiny cubes, because there's more surface detail to account for in the latter example.

I think the crossover point I mentioned earlier will come when GPUs become general-purpose enough to allow massively parallel voxel rendering implementations. That's what surprised me most about this article: they crow that it's a CPU-only technology... why? GPUs excel at tasks involving vast amounts of relatively simple parallel computation.

Prior to the crossover point, we'll see a bunch of cool games that use voxel rendering primarily for gameplay reasons. These games will look chunky compared to their polygonal peers, but will offer unique experiences. Minecraft is a good example. (I'm assuming it's voxel-based, but don't really know.)

Re: Exploring Euclideon's Unlimited Detail Engine

#37
post #13

Interesting article. Judging by Dell's (the CEO) calm attitude towards "haters", I personally believe that he truly has something revolutionary to offer. Only time will tell though.

I think Dell makes money the same way other scammers make money, produce as much hype as possible with half truths, and by the time people figure out what is real, you'll have already cashed in.

I guarantee he is optimizing his entire company for fancy demos. He'll sucker some idiot big company into buying his technology, then we'll never ever see it in a product.

These things are predictable as clockwork.

Re: Exploring Euclideon's Unlimited Detail Engine

#38
post #30
post #26

Earlier quoted context omitted.

> It's actually the reverse! Voxels make it easy to figure out what's on screen and what's not. No no, I explicitly said "ahead of time". It's easy to determine what's on screen when you're about to render the frame, but you have to load every single object in memory because every single object is a "candidate" that may end up on the screen, you just don't know ahead of time. You can't cull the voxel tree, even thoug…

Can't you still have a normal octree or something with segments of the voxels split by their spatial location with voxel subtrees inside of that? I don't understand why you can't apply spatial division techniques to voxels.

I think you can, and I think they do; but that still doesn't solve the memory issue, actually it makes it worse since now you have to store multiple 'resolution' versions for the same data.

But if they still need to use 'traditional' techniques like LoD, rendering at various resolutions, etc, then the complexity and running speed can't be all that much faster than a traditional approach. The way I've been reading these articles is that somehow he's got a very fast method of deciding which voxels to show, without any pre-processing or optimisation - just brute force. I'm curious to see the first demo they'll come up with, especially since they only now seem to be at a point where they can render without shading, animation etc, and they make it seem as if those are just implementation details that can be added on an afternoon. We'll see.

Re: Exploring Euclideon's Unlimited Detail Engine

#39
post #35

Earlier quoted context omitted.

I'm not saying it is entirely impossible. However, rotating volume data (which voxels are) is computationally a lot more intensive. With polygonal objects you can just change the transformation matrix and re-render the screen and you're done. At most, you have to deform the vertices that make up the outer shell of the object to do things like make a person walk. With voxels, you'd have to recompute all the voxels of…

I'm still not convinced by these arguments ;) The displacement of the voxels can also be done with a simple matrix transformation, as far as I see it; same like you'd do for the nodes in a 3d model, same as you'd do it with a 'traditional' 3d pipeline (OpenGL/DirectX) - unless I'm behind the curve and animation itself is done on the GPU nowadays, but I don't think it is. Ragged boundaries wouldn't be an issue as long…

The displacement of the voxels can also be done with a simple matrix transformation, as far as I see it

Yes, but the point is that you have to displace much more voxels than you'd have to displace vertices otherwise. Vertices are only on the boundaries of the object (and quite sparsely at that if you use normal mapping shaders etc wisely) but voxels fill the entire object densely...

Re: Exploring Euclideon's Unlimited Detail Engine

#40
post #13

Interesting article. Judging by Dell's (the CEO) calm attitude towards "haters", I personally believe that he truly has something revolutionary to offer. Only time will tell though.

I think Dell makes money the same way other scammers make money, produce as much hype as possible with half truths, and by the time people figure out what is real, you'll have already cashed in. I guarantee he is optimizing his entire company for fancy demos. He'll sucker some idiot big company into buying his technology, then we'll never ever see it in a product. These things are predictable as clockwork.

Most likely. They already got a $2million innovation grant from the government. Now they're working on better shadows and fancier worlds... mere demo stuff.
Post reply on HN