Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring Euclideon's Unlimited Detail Engine

gameinformer.com

Post reply on HN
Print view View original

21–30 of 93 posts

Re: Exploring Euclideon's Unlimited Detail Engine

#21

Post by darklajid »

Is something like "GPUs used to be fighting one another for more power, memory, and so forth, but now they have their languages like _Kuda_" (Page 6) just a random typo or a reason to believe that someone didn't do his homework before typing this down?

I'd love to see this released, but the article was far too positive and the tone read too much like marketing to me. Some careful, not too aggressive words at the introduction and blessing after blessing afterwards, sprinkled with the seemingly unbiased author's impression and description of a very nice and professional guy. Mhhhh...

Edit: Just saw that user 'Causification' already said something similar, albeit with a good amount of more emotion. Still, I'm going to keep this here as a personal impression of someone that has no clue about graphic engines in general, i.e. my layman's reaction after reading the article.

Re: Exploring Euclideon's Unlimited Detail Engine

#22

Post by wladimir »

roel_v wrote: post #17
wladimir wrote: post #10

Earlier quoted context omitted.

I think he means that you cannot rotate an object and keep it aligned to the voxel grid at the same time. It would be a lossy operation, and require interpolation, just like rotating an image on a 2D grid.

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 the object on a 3d grid. Also there are issues with ragged boundaries, which can be prevented by using antialiasing, but which is probably trickier (=more computationally intensive) than in 2D...

Re: Exploring Euclideon's Unlimited Detail Engine

#24

Post by modeless »

gizmo wrote: post #12
tobiasu wrote: 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…

The big downside is that you have no idea ahead of time what parts end up on screen and which parts don't. With a voxel engine you create a giant tree that allows you to do a quick logarithmic lookup to a voxel for every pixel on the screen (more or less). Suppose you're standing on a hill and look down on the valley below. If the terrain and world below is created by artists and contains many unique objects then you…

It's actually the reverse! Voxels make it easy to figure out what's on screen and what's not. That's their main advantage over polygons. The main disadvantage is that they are generally slower to render, but as you add more details, polygon renderers waste time on details that are far away or off screen while voxel renderers can discard those more easily, and eventually there's a tipping point.

You're right that lighting and animation are real problems with voxels. Animation in particular is pretty much impossible, which means you have to fall back to polygons for anything that moves or changes, which in modern games is a lot of stuff.

Re: Exploring Euclideon's Unlimited Detail Engine

#26

Post by gizmo »

modeless wrote: post #24
gizmo wrote: post #12

Earlier quoted context omitted.

The big downside is that you have no idea ahead of time what parts end up on screen and which parts don't. With a voxel engine you create a giant tree that allows you to do a quick logarithmic lookup to a voxel for every pixel on the screen (more or less). Suppose you're standing on a hill and look down on the valley below. If the terrain and world below is created by artists and contains many unique objects then you…

It's actually the reverse! Voxels make it easy to figure out what's on screen and what's not. That's their main advantage over polygons. The main disadvantage is that they are generally slower to render, but as you add more details, polygon renderers waste time on details that are far away or off screen while voxel renderers can discard those more easily, and eventually there's a tipping point. You're right that ligh…

> 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 though 99% of the voxel tree won't be used when rending a frame. So the memory overhead is immense.

Voxel trees don't make it easy to discard things that are far away at all, because there aren't any low-resolution objects that you can use for far-away objects. You have to load many objects in memory even when you use them to render just a pixel or two.

The polygon-based worlds we have today use various low-resolution models for when you view at a distance, and as you get closer the higher resolution models "pop in". This tech advertises that you have infinite detail and that there's no need for objects with different level of detail. This means that the complete point cloud of every object has to be loaded in memory and that's a very real problem and it's in complete contradiction to the claims made by the company that artists can create infinitely detailed worlds without having to worry about vertex counts or whatever. Artists have to compose their world out of re-usable high-detail objects or the sparse voxel octree will be way too large. This means the artists will be much more constrained than they are today, not less.

Re: Exploring Euclideon's Unlimited Detail Engine

#27

Post by robinhouston »

darklajid wrote: post #21

Is something like "GPUs used to be fighting one another for more power, memory, and so forth, but now they have their languages like _Kuda_" (Page 6) just a random typo or a reason to believe that someone didn't do his homework before typing this down? I'd love to see this released, but the article was far too positive and the tone read too much like marketing to me. Some careful, not too aggressive words at the intr…

Those of us who don’t keep showdead turned on can’t see what Causification has said, because he/she is hellbanned. I was quite confused by your comment, till I guessed what had happened and turned on showdead to check.

Re: Exploring Euclideon's Unlimited Detail Engine

#29

Post by Derbasti »

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 color me sceptical even on that idea.

Also, I would like to know how they do lighting. It looks like they might use precomputed highlights and shadows. Needless to say that this would not be of much use for dynamic lighting.

Re: Exploring Euclideon's Unlimited Detail Engine

#30

Post by davedx »

gizmo wrote: post #26
modeless wrote: post #24

Earlier quoted context omitted.

It's actually the reverse! Voxels make it easy to figure out what's on screen and what's not. That's their main advantage over polygons. The main disadvantage is that they are generally slower to render, but as you add more details, polygon renderers waste time on details that are far away or off screen while voxel renderers can discard those more easily, and eventually there's a tipping point. You're right that ligh…

> 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.
Post reply on HN