next »

[Xion]

Okay, so I'm stupid on this stuff, but it still piques my curiosity -
so voxels are just data represented on a 3d grid or something? Like, a canvas of pixels represented in 3 dimensions as opposed to 2 right? So they don't necessarily have to be displayed as cubes, right? That's just how they're rendered 'cause it's the closest thing to a 3d pixel? So like, can you render smooth surfaces by having only the flat surfaces be cubes and the curvatures can be rendered via a series of pyramids and prisms and tetrahedrons? Can you have, within a game, multiple 3d grids of varying coarseness, so a solid wall will be a few large cubic spaces, but can be subdivided into finer grids as needed? Have I said a single thing so far that wasn't a question?

[Zaphos]

Okay, so I'm stupid on this stuff, but it still piques my curiosity -
so voxels are just data represented on a 3d grid or something? Like, a canvas of pixels represented in 3 dimensions as opposed to 2 right? So they don't necessarily have to be displayed as cubes, right? That's just how they're rendered 'cause it's the closest thing to a 3d pixel? So like, can you render smooth surfaces by having only the flat surfaces be cubes and the curvatures can be rendered via a series of pyramids and prisms and tetrahedrons? Can you have, within a game, multiple 3d grids of varying coarseness, so a solid wall will be a few large cubic spaces, but can be subdivided into finer grids as needed? Have I said a single thing so far that wasn't a question?

Yes, yes but it could be more data than just color values -- storing signed distance fields in voxels is often useful, yes, yes they're rendered as smooth surfaces quite often and are just associated with cubes in the context of games because of the raycast rendering technique that made them fast, sort of but you don't want to do it exactly like that, yes octrees are a version of that, yes if you count the first half of your first sentence.

[Xion]

Oh. Thanks. Cool.

[bateleur]

What possibilities are you talking about?

For example building a character as a wireframe skeleton and then generating all the actual polygon surfaces by having rules for placing polygons according to the positions of the wireframe stuff. So baggy sleeves hang downwards even when the character is upside down etc.

[Zaphos]

For example building a character as a wireframe skeleton and then generating all the actual polygon surfaces by having rules for placing polygons according to the positions of the wireframe stuff. So baggy sleeves hang downwards even when the character is upside down etc.

Sounds interesting, but I don't think I'm really following.  And are you envisioning the sleeves hanging downwards because they've been tagged to be physically simulated, or for some simpler reason?  If it's simpler, how would it avoid interpenetration of cloth polygons?

Also, the way it's typically done is they define both the mesh, and the wireframe, and then the mesh vertex coordinates are represented as weighted averages of offsets from the wireframe.  (Or something more complex, but let's say it's like that for now.)  How much user control over the 'rules for placing polygons' would there be in your system?  Is the user experience different than in the standard pipeline?

[increpare]

Oh to program a retro-looking voxel-based game using lots of fillcuboids and fillspheres 

Ecstatica only used it for the characters

And the floor and walls look all nubbly, because..?

I think they were prerendered (still with ellipsoids, though I'm not sure).

Ellipsoids are not a good general solution.  You can't express negative or zero curvature except by packing the ellipsoids closer than triangles, and you can't get the expected benefits of positive curvature unless the surface has enough room under it to hide the portion of the ellipsoid you're not going to use. 

How about having a 3d engine based on some primitive negative-curvature surfaces then:





 :D

[bateleur]

And are you envisioning the sleeves hanging downwards because they've been tagged to be physically simulated, or for some simpler reason?

Yes, physics. Although in a sense I see that as "simple". Increasingly I expect to see physics models (not necessarily realistic) becoming standard in games. Defining a few physical properties for an object should be about as easy as things get. (Obviously writing the physics engine is far less so, but that's a one-time-only job. Apart from minor game-specific tweaks.)

If it's simpler, how would it avoid interpenetration of cloth polygons?

Actually even with physics this would likely be a messy problem. I hadn't thought of it. I'm like that when I code stuff too. I implement 9/10 of something and then notice a huge problem I failed to anticipate.

Also, the way it's typically done is they define both the mesh, and the wireframe, and then the mesh vertex coordinates are represented as weighted averages of offsets from the wireframe. (Or something more complex, but let's say it's like that for now.)

That's pretty good in terms of efficiency vs quality tradeoff, but for all but the simplest cases it doesn't look all that good.

How much user control over the 'rules for placing polygons' would there be in your system?  Is the user experience different than in the standard pipeline?

Depends what you consider standard. Geometry-based modellers and 3D sculpting tools are already radically different.

For the most part I'd expect user control to be geometric/algorithmic in nature but without involving actual polygons at any point. So in the case of the sleeve example there would be some control points defined for the cuff relative to the bone, some curve rule for joining the control points smoothly and then some rule for building the cuff-to-sleeve surface from the curves at each end.

Actually one problem (which I've only just thought of) is that this would be a nightmare for texturing since the deformation of any given surface region at runtime would actually be undefined. Ho hum, it's not like I have the free time to actually try to implement this anyway!

[Annabelle Kennedy]

Voxel raycasting is pretty fast as long as your grid is coarse enough, though, and 2001 wasn't that long ago ...

yeah, i guess 2001 wasn't that log ago.. in fact i actually forgot it came out that recently.. i thought it was older.

I'm not a genius of like.. performance though, just for whatever reason that all voxel type engines seem to run rather slow, in my experience i just assumed it was slow..

but i didn't really think about it that much.

[Eclipse]

Voxel raycasting is pretty fast as long as your grid is coarse enough, though, and 2001 wasn't that long ago ...

yeah, i guess 2001 wasn't that log ago.. in fact i actually forgot it came out that recently.. i thought it was older.

I'm not a genius of like.. performance though, just for whatever reason that all voxel type engines seem to run rather slow, in my experience i just assumed it was slow..

but i didn't really think about it that much.

Comanche: Maximum Overkill is from 1992 (a year before DooM)and it used voxel raycasting :)oh, and i played it on a 33mhz 486 machine.

http://www.mobygames.com/game/comanche-maximum-overkill



it had also self-shadows and water with reflections (in the expansion pack, here's a video

[Annabelle Kennedy]

well ill be.

i just assumed it was impractical.

[Zaphos]

{lots of stuff}

Well, seems like the idea needs to be thought through a bit more 

I guess the main idea is defining models by their relationship to the skeleton, rather than filling in that relationship after the model is already created.  It seems appealing mainly because the current process for defining that relationship after the fact is pretty horrible; I find that even just painting weights for linear blend skinning is a super painful process.  But I'm not sure that defining things in terms of a skeleton is the best approach -- I think something like harmonic coordinates for character articulation seems more natural and more expressive.

That's pretty good in terms of efficiency vs quality tradeoff, but for all but the simplest cases it doesn't look all that good.

Yep.  I think there are more complex methods that can look good and still be relatively efficient though.

[XICO2KX]

If someone is still interested in this topic, here are the currently most promising voxel engines available!

• Unlimited Detail: http://www.unlimiteddetailtechnology.com/
• Atomontage: http://www.atomontage.com/

[Rob Lach]

Unlimited Detail

 

[XICO2KX]

And here are some very nice example images from each engine!
Unlimited Detail


Atomontage


With this kind of quality, 3D Voxel Engines are the future!

[moi]

This tech has been making the rounds since 2005 or sthg, why aren't we playing with that already?
And don't tell me it's because of a publisher maffia conspiracy, I don't buy it.

[XICO2KX]

This tech has been making the rounds since 2005 or sthg, why aren't we playing with that already?
And don't tell me it's because of a publisher maffia conspiracy, I don't buy it.

Well, Atomontage is still currently being developed, as you can see in their Dev blog and in their Youtube channel!
And Unlimited Detail is also under heavy development as you can confirm in the recent interviews from Wired, New Scientist, This Is My Joystick! and 3D-Test, and in the unofficial Facebook page!

[slembcke]

Well, people are: http://voxelstein3d.sourceforge.net/

The problem with voxels are that they consume a ridiculous amount of memory and don't work well for scenes with moving objects.

[Sam]

There is an open source voxel engine: Voxlap

It seems to have seen very little activity since around 2005 (although there was a small update in 2008).  In the test scene found on that link the voxels are displayed pretty large and chunky, but I'll bet they could be made much finer and still have the engine run acceptably on a modern machine.

I think there's been a thread before about Unlimited Detail - the jist of it was that it relies heavily on preprocessing the scene so animation or even movement of objects in the scene would be very difficult.  I recall a link to some other programming forum where this was explained to the author of Ulimited Detail and hijinks ensued.  There's also a more fundamental issue of how one generates the data for an infinitely detailed model which is actually infinitely detailed and not just a point cloud representation of a polygon model.

I hadn't seen Atomontage before and it looks much more like it's heading for becoming an actually usable engine.

I believe the general problem with voxel engines is they don't do much that can't already be done with polygons.  Most people are already set up for dealing with polygons, and so see no reason to change.  It's very neat that Atomontage can have a truck leave real tracks in the sand which really change the shape of the sand, but the end result is almost indistinguishable from applying a decal to the bump/normal/texture/whatever map of the sand in a polygon engine.

There's some significant overheads involved in switching to a voxel engine:
If you're no longer storing polygon data on objects in the game, you can't use Havok or whatever other polygon based middleware. (If you are storing polygon information alongside voxel representations then why not just render from the polygons)
Artists need to learn to produce voxel models instead of polygons, textures and normal maps.  All those tricks they've learnt over the last 10 years in the industry are gone.

In the old days of everything being rendered in software, polygon and voxel solutions were quite evenly matched with each having their own advantages.  But now that virtually every PC has a powerful extra processing unit dedicated to polygon graphics the competition is much more biased.  I could see Commanche-like graphics cropping up in mobile games (if they haven't already) where you're limited to software rendering again.


I type too much.  Voxel engines are fun, but the only thing they can do better than polygon-based engines seems to be 'total' destructible environments.  But that tends to boil down to punching rather unrealistic holes in scenery, like the destructible environment in the Worms games but pushed into 3D.

[Zaknafein]

We've already "debunked" Unlimited Detail on these forums, see this thread.
http://forums.tigsource.com/index.php?topic=11624.30

It keeps popping up in blogs and social networks every once in a while, but there certainly isn't any active developments. Everything on the web dates from 2008 or earlier. And just the exchanges between the creator of that tech on Beyond3D's forums are ridiculous...

The developer admitted that he has been working in a vacuum for the last 10+ years - so he knows very little about how current renderer's work.
(Which was very apparent during a Q&A) It appeared that the demos used DX8 to do blitting to the screen. It was also stated that the demos were single core and written in plain non-optimized C, so someone who knew what they were doing could make it run much, much faster. (was a bit distressing to learn he did not know what a memory cache was however)

http://forum.beyond3d.com/showthread.php?t=47405

[moi]

I think everything is not to be thrown out, I'm sure something like UD could be adapted to work in amodern engine just for static geometry, I don't care if every thing else remains in polygons.
I remember people talking about that tech in 2005 and I searched and I found many engines some freeware, most of them seem to have disappeared or sold out to big companies.
I'm sure there is something in there.
I'm sure ultimately someone will find a way to mix polygons inside point clouds and we'll be living in vitrual reality.
(that or the editor maffia will plant a fake terror attack to erase everything)