Live data from Hacker News

Exploring Euclideon's Unlimited Detail Engine

gameinformer.com

41–50 of 93 posts

Re: Exploring Euclideon's Unlimited Detail Engine

#41

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…

This may not be as big an issue as you think. We had the same issue in in the Crash Bandicoot games: the background was rendered a completely different way than the foreground (animating) elements. We made it work by approximating where the foreground elements should "sort in" to the background polygon layers. Where the heuristics were wrong, we tuned it manually, by pushing a foreground element forward or backward in the scene until it looked right.

Remember: you can hack stuff in games until it looks right. It doesn't actually have to work perfectly from a theoretical standpoint; it just has to work practically without too much additional tuning labor.

Re: Exploring Euclideon's Unlimited Detail Engine

#42

What I don't like with "Unlimited Details" is that Dell refuses to say what the engine can't do yet. We know it's a work in progress. We (the internet) are excited about it because it's an experiment that's on scale with what we could expect from that branch of 3D graphics technology. Trillions of atoms, whatever. Show us what's still in progress because the internet is skeptical about this, this and this. Hacking re…

> Dell refuses to say what the engine can't do yet.

I'll go out on a limb here, and suggest it can't do real-time animation, texturing, lighting, shadows, collisions, etc. All the maps / screenshots shown seem to be static, procedurally generated and not artist-created.

Dell keeps throwing around this 'Unlimited Detail' marketing phrase which is very offputting. Until it's seen in action in an actual game it can be nothing but snake oil.

Re: Exploring Euclideon's Unlimited Detail Engine

#43

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…

In the context of voxel-based games, a vote for Voxatron: http://www.lexaloffle.com/voxatron.php

Re: Exploring Euclideon's Unlimited Detail Engine

#44
post #6
post #2

Hmm, what's so amazing about it? It's a voxel graphic engine, of course it's going to have great detail and no polygons (duh). That's not new. Commanche had this in 1992... I'm not at all an expert in this area, can someone who is explain what the downsides of voxel graphics are? There must be some serious problems with it, because the technology is well known. Is there something new that makes this particular engine…

Comanche had shitty detail, as did all the games that came after (Delta Force, etc.) that used the same engine. With this you can zoom down to the pebble. Supposing this is legit, I'm cautiously optimistic, homie has probably uncovered some very novel techniques that allow the granular level of detail you couldn't do before with voxels, with optimizations that don't require GPU .. this is pretty amazing.

Comanche had shitty detail because it was running on 19 year old hardware. Scale that up 10,000x and refine the algorithms over a couple decades and Dell's demo is the logical result.

Re: Exploring Euclideon's Unlimited Detail Engine

#45

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…

This may not be as big an issue as you think. We had the same issue in in the Crash Bandicoot games: the background was rendered a completely different way than the foreground (animating) elements. We made it work by approximating where the foreground elements should "sort in" to the background polygon layers. Where the heuristics were wrong, we tuned it manually, by pushing a foreground element forward or backward i…

That still does not solve the issue that current games have a lot of moving assets and really not that much static geometry. Trees, shrubs and grass move in the wind, water flows, walls crumble when hit by bullets, that kind of thing. Everything is animated.

Re: Exploring Euclideon's Unlimited Detail Engine

#46

Earlier quoted context omitted.

This may not be as big an issue as you think. We had the same issue in in the Crash Bandicoot games: the background was rendered a completely different way than the foreground (animating) elements. We made it work by approximating where the foreground elements should "sort in" to the background polygon layers. Where the heuristics were wrong, we tuned it manually, by pushing a foreground element forward or backward i…

That still does not solve the issue that current games have a lot of moving assets and really not that much static geometry. Trees, shrubs and grass move in the wind, water flows, walls crumble when hit by bullets, that kind of thing. Everything is animated.

It seems to me that voxel worlds could make this problem easier, not harder: you can deform the world algorithmically, voxel by voxel, rather than using polygonal approximations. Imagine an acid blob eating an outdoor environment in a fantasy game: in a voxel world, this is like a fancy seed fill. In a polygonal world, this is much harder to simulate.

I'm not saying voxel worlds solve every such problem; just that there are likely to be as many things that are easier w.r.t. animating elements as there are things that will be harder.

[Edit: maybe I'm not explaining this well, but I guess what I'm saying is that I don't see any reason why any voxels in a voxel world have to be static. The data structures don't force that; in contrast, in a voxel world with a clever data spatial structure, every single voxel can be a dynamic, particulate object, subject to computing power. As I argue above, though, this is not practical until computing power improves enough. Perhaps this is your fundamental point, in which case we're in violent agreement.]

Re: Exploring Euclideon's Unlimited Detail Engine

#47

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…

Dammit, we spent years working toward a unified lighting model, and now we want to split it apart again?!

Re: Exploring Euclideon's Unlimited Detail Engine

#48
post #42

What I don't like with "Unlimited Details" is that Dell refuses to say what the engine can't do yet. We know it's a work in progress. We (the internet) are excited about it because it's an experiment that's on scale with what we could expect from that branch of 3D graphics technology. Trillions of atoms, whatever. Show us what's still in progress because the internet is skeptical about this, this and this. Hacking re…

> Dell refuses to say what the engine can't do yet. I'll go out on a limb here, and suggest it can't do real-time animation, texturing, lighting, shadows, collisions, etc. All the maps / screenshots shown seem to be static, procedurally generated and not artist-created. Dell keeps throwing around this 'Unlimited Detail' marketing phrase which is very offputting. Until it's seen in action in an actual game it can be n…

I agree with you 100% - my comment was mostly wishful thinking, a description of how Dell could make me change my mind.

This kind of marketing is one I can't quite understand. I mean, what is he after? Buzz? Funding? What's his endgame? Why & how is he paying people to work on it? Is his marketing strategy to troll the profession & the audience, and he really has something big up his sleeve?

Why is he using the Vaporware approach?

Re: Exploring Euclideon's Unlimited Detail Engine

#49
The fact they are financially backed by the Australian Government (which has an approximately 0% track record as a VC) seals their doom. If they were in the US they'd have to figure out a way to produce something commercial or at least potentially commercial, now they can burn through $2M while fading into irrelevance (if not there already).

Re: Exploring Euclideon's Unlimited Detail Engine

#50
post #18
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…

Rotatin (in general - transforming) voxels in real time is difficult compared to polygons, because with polygons you only transform vertices, and in voxels you have to transform every voxel. EDIT: If you are spekaing about preprocessing data - yes - you can rotate as much as you want, the only problem will be that object instanced 1000 times with different orientation/scale will take 1000 times more memory than objec…

Sorry, by 'preprocessing' I meant things still done on each frame, but anything that is not raw pushing-vertices-into-the-gpu-pipeline, i.e. all polygon culling, LoD simplification etc.

But yeah, the amount of data you'd have to work on would be much greater, but the way I interpret all of this is that he's found algos to do that very fast, regardless of whether it's a lot of data.

Post reply on HN