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

61–70 of 93 posts

Re: Exploring Euclideon's Unlimited Detail Engine

#61

Post by skymt »

Shabaz wrote: post #60
kranner wrote: post #43

Earlier quoted context omitted.

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

Someone correct me if I'm wrong, but I'm not sure that either Voxatron or 3D Dot Game Heroes actually use voxel based rendering. They may or may not store their models as voxels but I'm pretty sure that at some point it's converted into a polygonal model and shoved into a traditional polygon based rasterizing pipeline. As opposed to doing some raycasting into a datastructure containing voxels (e.g. an octree), which…

Voxatron absolutely uses "true" voxel rendering.

> Voxatron is based on a virtual 128x128x64 display. It's a buffer of 3d video memory that is rendered out to the screen at the end of each frame, much as an old-school 2d display is. You can POKE bytes into the virtual memory, and they come out as voxels. I don't compromise on this -- even the menus are drawn into the voxel display. Hopefully one day I can get hold of a real physical 128x128x64 display and play Voxatron on it with almost no modification.

> The renderer is written in software (C + SDL). Each frame, scan through the virtual video memory back to front and look for voxels that have empty neighbours. If they are exposed, I transform the corners of a cube intro screen space and scan-render the polygon. Shadows are done with a traditional shadow-map but sampled with a filter to get the soft shadows.

http://www.lexaloffle.com/bbs/?tid=260

Re: Exploring Euclideon's Unlimited Detail Engine

#62

Post by wladimir »

VMG wrote: post #58
wladimir wrote: post #39

Earlier quoted context omitted.

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...

> but voxels fill the entire object densely I was under the impression that they fill the object's hull

I guess you could do that, make the objects hollow. But that will obliterate the "low hanging" advantages of voxels such as destructable terrains, being able to cut things in pieces, realistic physics simulation etc...

Re: Exploring Euclideon's Unlimited Detail Engine

#63

Post by Shabaz »

skymt wrote: post #61
Shabaz wrote: post #60

Earlier quoted context omitted.

Someone correct me if I'm wrong, but I'm not sure that either Voxatron or 3D Dot Game Heroes actually use voxel based rendering. They may or may not store their models as voxels but I'm pretty sure that at some point it's converted into a polygonal model and shoved into a traditional polygon based rasterizing pipeline. As opposed to doing some raycasting into a datastructure containing voxels (e.g. an octree), which…

Voxatron absolutely uses "true" voxel rendering. > Voxatron is based on a virtual 128x128x64 display. It's a buffer of 3d video memory that is rendered out to the screen at the end of each frame, much as an old-school 2d display is. You can POKE bytes into the virtual memory, and they come out as voxels. I don't compromise on this -- even the menus are drawn into the voxel display. Hopefully one day I can get hold of…

I didn't realize they use their own renderer. Pretty neat.

I guess I was thinking that the raycasting approach I've seen used in some of the sparse voxel octree stuff I read wouldn't make sense when you want the blockiness of voxels to actually show up very clearly, plus that it looked like you could achieve the same look using polygon based cubes. Guess I should've done a bit more research.

Re: Exploring Euclideon's Unlimited Detail Engine

#64

Post by jawngee »

ctdonath wrote: post #44
jawngee wrote: post #6

Earlier quoted context omitted.

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.

Well, see above, it actually wasn't true voxels in this sense.

Re: Exploring Euclideon's Unlimited Detail Engine

#65

Post by lloeki »

Terretta wrote: post #51
dmbaggett wrote: post #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…

In the Comanche series, "voxels" were a selling point on the box. http://www.youtube.com/watch?v=Ku-ICQvQJGI&sns=em http://en.wikipedia.org/wiki/Comanche_series No story I've seen on this engine seems to mention that series.

The problem with NovaLogic's VoxelSpace engine (used in Delta Force, Comanche and Armored Fist series) is that it's using a height map, and to speed up rendering, "locks" the Z axis to simplify a bunch of formulas to render voxels comprising the terrain much faster. Comanche 1 and 2 used sprites so that wasn't as noticeable, but Comanche 3 introduced polygon-based models, where the third axis speedup produces uneven deformation when looking up or down (you can see it in the video). You can see the same problem in OutCast. The choice of an engine with such limitations for a tank an helicopter and a ground soldier game is interesting, and you can notice how most of the gameplay in those games involves long range action along the horizontal plane. Notice how NovaLogic jet fighters games do not use VoxelSpace but a polygon-based terrain engine.

Today voxel-based renderers must allow correctly projected 6-DOF orientation of the viewport, and not just render terrain but arbitrary objects, and integrate together with various lightning and shader effects to stand any chance outside the neo-retro or abstract category.

Re: Exploring Euclideon's Unlimited Detail Engine

#66

Post by ldar15 »

"... he was forced to solve the riddles himself, rather than plucking the accepted solution from a textbook ..."

The thing is, the textbooks also have all the things that didn't work or don't work well. Even some educated graphics programmers often fail to understand that representing 3D objects is just a data representation and transformation problem. Sure, a hard one, but there's nothing magic about it. Representing the data as a bag of "atoms" instead of polygons just isn't a breakthrough. The problem is still spacial search. The problem is still a simulation of optical physics. Graphics is just an optimization problem now. Attend an IEEE conference and maybe 5% of papers will be new theory, the rest will be about effective optimization techniques.

When someone comes to you and says "I have this awesome idea because I didn't read anybody else's ideas", just walk away.

Re: Exploring Euclideon's Unlimited Detail Engine

#67

Post by modeless »

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…

You're wrong. You don't need to know what's visible ahead of time because you can load the tree lazily on demand. Voxels lend themselves naturally to perfect LOD scaling in a way exactly analogous to how mipmaps and megatextures work for 2D textures. There is no analogous algorithm for polygons; polygon mesh LOD is a very hard problem that is solved only imperfectly today and with a huge labor overhead for both artists and programmers. John Carmack himself has proposed voxels as a solution to this problem: http://www.pcper.com/reviews/Graphics-Cards/John-Carmack-id-...

Re: Exploring Euclideon's Unlimited Detail Engine

#68

Post by extension »

Shabaz wrote: post #63
skymt wrote: post #61

Earlier quoted context omitted.

Voxatron absolutely uses "true" voxel rendering. > Voxatron is based on a virtual 128x128x64 display. It's a buffer of 3d video memory that is rendered out to the screen at the end of each frame, much as an old-school 2d display is. You can POKE bytes into the virtual memory, and they come out as voxels. I don't compromise on this -- even the menus are drawn into the voxel display. Hopefully one day I can get hold of…

I didn't realize they use their own renderer. Pretty neat. I guess I was thinking that the raycasting approach I've seen used in some of the sparse voxel octree stuff I read wouldn't make sense when you want the blockiness of voxels to actually show up very clearly, plus that it looked like you could achieve the same look using polygon based cubes. Guess I should've done a bit more research.

You can do something like Voxatron with raycasting and it will look the same. It would just be inefficient with such big voxels. It becomes efficient when the voxels approach the size of 2D screen pixels.

Re: Exploring Euclideon's Unlimited Detail Engine

#69

Post by tripzilch »

Terretta wrote: post #51
dmbaggett wrote: post #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…

In the Comanche series, "voxels" were a selling point on the box. http://www.youtube.com/watch?v=Ku-ICQvQJGI&sns=em http://en.wikipedia.org/wiki/Comanche_series No story I've seen on this engine seems to mention that series.

"voxels" are also a demoscene term for a method of rendering height-mapped landscapes in 3D, using a kind of raycasting technique. Technically they are "voxels", but the algorithm and their use is quite different from the sort of thing talked about here.

one thing is that only the landscape is rendered as "voxels" and it's mostly a textured height map, so it can't contain multi-level structures such as bridges, etc. it's best suited for mountain ranges and beaches and things like that.

just the term "voxels" is quite generic already, and doesn't really describe one algorithm over another, except that you're not using polygons.

Re: Exploring Euclideon's Unlimited Detail Engine

#70

Post by tripzilch »

wladimir wrote: post #57
dmbaggett wrote: post #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…

I think the crossover point I mentioned earlier will come when GPUs become general-purpose enough to allow massively parallel voxel rendering implementations Indeed. This is certainly possible with modern GPUs, and has been for a while. Voxels are pretty well-suited to GPU rendering. See the research I linked to in another reply in this thread. I didn't get around to reading their entire article, but if they call it…

Well on the other hand, if they can already do this with just CPU, it can only get better as they unleash the power of a GPU as well, right? Especially as you say, voxels are pretty well-suited to parallel rendering like that.
Post reply on HN