ideas for TAtmosphere

[laggyluk]

My game setting is voxels in space and I need a way to keep interiors and outside separated to track oxygen levels. World data is a 3d grid of cubes, each block defines a 'substance' at given position (a byte). Since it already uses a lot of memory I'd like to avoid having another 3d array just for oxygen levels.
Oxygene (or other substance like water) should disperse from the sources across the place over time.

Player can build whatever he wishes with given resources so there are no fixed buildings with known interior layout.
I have couple of ideas how to approach this but maybe someone has a better one:

have a number of blocks just to represent oxygen percentage at given block (like btOxygen10, btOxygen20 etc.)
not sure how such low resolution would work when trying to simulate disperse though.
or
have a some sort of list/map of existing oxygen blocks in the space. does it make sense to have a 3d map? like TFPGMap <TVector3f, byte> or nested map. Wouldn't it be too slow?

Simulating disperse across terrain is another problem. There should be some delay when updating neighbouring blocks (especially when simulating water flow, oxygen is not gonna be visible anyways). I write this post partially to sort things in my head but other ideas are welcome ;)

[Ñuño Martínez]

Using an octree (http://en.wikipedia.org/wiki/Octree) may help you to use less memory.

[User137]

Simulation in 3D is going to be difficult. I once made a 2D simulation for water and air-pressure combined, but it didn't work. Idea was to make that pressure could push water... but then the idea itself blurred when i started thinking about vacuum. Assuming pressure in vacuum was 255 and would be point that pulls everything towards it i guess, and then it would mean that water would move from lower to higher pressure, and pressure itself in opposite direction.

About memory use, you can try nxData if you want:
https://code.google.com/p/nxpascal/source/browse/trunk/src/nxData.pas
You can make your game world out of chunks, and keep them in the memory as mix of compressed and decompressed forms. I've done simple 2D game world test based on Terraria (which is why i don't want to show it due to copyrighted material). Moving in the map means realtime multithreaded decompression, and by default every chunk will compress itself back after 15 seconds idle. Idle here means that it wasn't used for even rendering. It is very general purpose class, it only assumes that you can refer to each chunk as integer number - using 1-dimensional array, and that every chunk has same static size. For this class, yes, octree would work with it very well.

[laggyluk]

I was thinking that if i had a bunch of 'blocks' it would be pretty straightforward to fill up closed space by simply turning each empty block into oxygen in several updates. How would that process look with octree? I know that octrees are supposed to be the right structure for voxel stuff but I don't grasp the concept well enough to use it :p

[phibermon]

Incredibly you seem to be working on a very similar setup as I am for your game project. I also have voxel regions (aka minecraft) floating in free space as asteroids. The idea being that you build inside the asteroid, place guns, engines etc. so it's a kind of strategy in space, combined with a minecraft like building system combined with a dungeon keeper style management game.

And just as coincidentally I've also been simulating oxygen levels etc so that when asteroids are attacked, atmosphere will leak out of the holes.

I've modeled my atmosphere by using a simple thermodynamic simulation that gets updated once a second (but spreads calculation out across the update period to prevent frame skipping etc).

Look it up if you want to do the same. You can optimize the update passes by starting at the oxygen generator and working out like a flood fill (or path finding algorithm search) you're transfering 'heat' (or oxygen pressure in this case) by studying the surrounding squares, if a %100 oxygen is next to a %50 oxygen then that's half the tempreture (or relative air pressure) of a block with %100 oxygen next to %0 oxygen. In a thermodynamic simulation the rate of heat exchange (or oxygen spreading around the room...) is directly proportional to the difference in tempreture. This means that if you had %100 oxygen in the middle, %0 on the left and %50 on the right, you'd have half of the %100 oxygen flowing to the %0 side and a quarter flowing to the %50 side. if you get me.

You don't have to be as complex but if you're simulating a dynamic across blocks that has the potential to go anywhere in the world, you've got to have an algorithm that either itterates over the whole world, or preferably, itterates over all blocks in a certain radius around the player (like minecraft) with optimizations that can help you skip large areas of blocks in your octtree (like minecraft does, searching out from a water source block for example)

Obviously when your simulation detects a 'filled' block (a wall) you just don't transfer any oxygen. In a minecraft style game this would be optimized as you'd already assume that generated underground caverns etc are %100 filled with oxygen and you store a flag in your oct tree if there's no potential processing to take place for all child nodes. This means that vast parts of the world that you see won't require the oxygen simulation until you perform an action that requires that to happen. You could further optimize it by flagging blocks / oct-tree nodes that are exposed to space, this would prevent the simulation from itterating across them and you could simply destroy any oxygen that would of otherwise been transfered to them as a leak. This is preferable to that oxygen spreading out across the sky above the planet as your framerate struggles to hit 1 per minute.

I would reccomend if at all possible having a maximum 'range' for oxygen generators if you can work it into your gameplay, you really want to restrict such simulation as much as possible and this would be a major help.
----

As I have relativley small voxel regions (asteroids) I have much less data to store than if my entire world was voxels, so memory usage isn't an issue for me however I do (and you should too) pack my nibble ready values into bytes etc so I can store multiple properties per block. For oxygen I use the lower four bits of the same byte as I use for storing temperature, this gives a maximum of 16 separate values for each which is more than sufficient for game simulation purposes.

You should break up your storage like this, for any situation you're storing a value, decide if you really need the entire range of that byte/word etc and if you don't, see what else you can bundle along with it.

it's only a case of using bit-wise operations and masks to pack and unpack your numbers :



var

A,B,C : byte;

begin

{you can store a maximum of 16 values in 4-bits (a nibble) if your values exceed this, this code will obviously not work}
A := 13; {0..15}
B := 5; {0..15}

//pack A and B together into C
C := (A shl 4) or B; {shift A left by 4 bits and OR with B}

//unpack C into A and B (or wherever)
A := C shr 4; {shift C right 4 bits, original B gets shifted into oblivion, gives you original A}
B := C and $F; {bitmask using 15 ($F hex) to blank out original A to get original B}

end.


Obviously you can do this with 16/32bit values too if you like. You could even take a 16bit integer and store a 12bit and 4bit number for example. It's worth concidering this for values that won't work inside a byte but a 16bit word would be overkill for, you now have the option of a 12bit integer with the bonus of storing a seperate nibble for another var.

[laggyluk]

nice , looks like a lot of people is working on that sort of games recently.. fortunately most of them are based in medieval/rpg setting ;)
main problem I see is when to stop the simulation. If oxygen fills the room starting from a generator block and there's a breach in the wall then there's no need to simulate it spreading over the ground outside the building. But how to determine that it's actually outside? could be a connection to another closed space..
Maybe by running a pathfinding algorithm from the generator to some point in space that is outside of the building..
But then how to determine that it's actually outside without setting it off the map? maps can be quite big (62M blocks) so my A* wouldn't even work without crashing :P

it's more like a dwarf fortress than minecraft and there will be a lot of units so simulating stuff around player doesn't really help

[phibermon]

That's why you need an Oct-Tree, they fit perfectly with what we're talking about.

To get around the infinite recursion issue of spreading oxygen you should implement things like I discussed. Generate the world and store a flag with every level in the oct-tree. the flag states if the containing region has been altered or not.

Now decide where has oxygen. are there natural pockets of oxygen in caves etc? they get generated by your terrain-gen etc. You have to ensure in your generator that any cave that would have oxygen, is not exposed to the outside world (do this during generation).

If you can do that, that means if you walk around that natural cave, you don't have to simulate oxygen *at all* unless you dig a hole etc. if you do, then you only have to simulate the oxygen in a certain radius around the player, or around the change (Whatever you decide to do)

You could use another flag to determine if a block or indeed whole level of the oct tree is in contact with space. Your simulation would stop there, it would treat access to 'space' as if it were a solid wall, with the exception that you can physically pass thru it, but oxygen won't spread, only get 'eaten' by it.

It's even easier if the only source of oxygen in the whole world is what the player adds as then you only need to store data about oxygen, space etc in the areas the player is in / has visited.

You'd see a very clear way to optimize this if you understood and implemented oct-trees.

What you're thinking is correct, you are going to have to simulate a hell of a lot, your A* will be very busy. What you have to do is restrain it as much as possible with every trick you can implement. You will also need to slow down the oxygen simuation, spread it out across a number of frames, update it once a second for example.

By using oct-trees, optimizing the oct-nodes with 'chunk' flags that can help you skip over calculations, by only updating the world that's actually around the player etc you can make this work in a game.

Another thing you can do is for areas with spreading oxygen? if a player was just in a %100 oxygen block and hasn't passed a 'leads to space' block, then there's %100 oxygen. Don't simulate and just assume whenever possible. You only really need to simulate oxygen around generators and holes to space. There's nothing wrong at all with keeping a record with every node in the oct-tree of all the 'holes to space' inside it. There won't be that many compared to the actual number of voxels.

Now the really tricky thing is how to 'suck' objects, players etc towards holes to space when there's an explosion etc I have many solutions to that as well but I don't know if that's what you're aiming for.

[laggyluk]

You don't have to be as complex but if you're simulating a dynamic across blocks that has the potential to go anywhere in the world, you've got to have an algorithm that either itterates over the whole world, or preferably, itterates over all blocks in a certain radius around the player (like minecraft)
I was thinking that maybe generator could be a root of a tree or sth and update children, adding nodes as it spreads. could work for smaller spaces but a big hole in base hull could be troublesome to calculate

btw is your thermodynamic simulation based on 'cellular automata'? just read that both minecraft and dwarf fortress use them to simulate fluids

as for my game setting it starts with a landing on a planet with 0% oxygen. only sources of oxygen will be 'generators' (greenhouse, pipes) placed by player

[phibermon]

btw is your thermodynamic simulation based on 'cellular automata'? just read that both minecraft and dwarf fortress use them to simulate fluids

The field of cellular automata was almost certainly inspired by the very concept of a thermodynamic simulation being as the latter preceded the former by a century or two. They're thinking 'game of life' (probably the first and best known example of 'cellular automata' but the man who wrote game of life was thinking 'thermodynamics with more complex rules'.

But it's how to optimize that simulation, restrain it to work with only the world.

It's easy, start with a blank world, all blocks are of the type 'outer-space'. when you generate the landscape, that will leave you with outer-space blocks and filled blocks.

The real question is about how you generate caves, how that interacts with terrain generation, really you want it as a seperate step so you can control this oxygen problem.

you want both dynamic and fixed oxygen block types.

what about caves that meet outer space?

For every time a 'cave growing' algorithm turns a rock into empty-space, and finds it meets outer-space, you then 'grow' out from all of these blocks (with some more A* walking) for a set radius (say 30 blocks) that provides a smooth transition from no oxygen to 100% oxygen as you walk into the cave. The oxygen simulation *would not run* for these blocks, they would have a special property of 'fixed' oxygen level, so are not governed by the oxygen sim but can still be 'felt' by the player.

Why not empty the whole cave, cave system of oxygen? That would be far too much simulation, A* could walk down miles of caves etc the game would crawl to a stop.

--

Now for dynamic oxygen.

If a block being processed with oxygen comes across an outer-space block, the simulation doesn't move past it (like a filled rock block). the oxygen is 'lost to outer space'.

If the oxygen simulation meets a 100% oxygen block, again, the simulation stops. this prevents the simulation calculating anything for situation where you dig from one cave to another that are both pressurised.

The simulation must run but it will stop at 'outer-space' blocks and leak oxygen, it will stop at 100% oxygen blocks (either simulated or 'fixed') because there's no change and it'll stop at any 100% oxygen blocks (fixed or dynamic)

If you do all of this it leaves you with one last problem.

For dynamic rooms that the player has dug, how do you override the 'fixed' oxygen levels at things like cave/outside transitions, WITHOUT then causing the problem of A* walking thru the cave system and breaking the simulation. you'd want a more realistic oxygen sim rather than the fixed, smooth transition put in place by the generator.

Well it's already partly solved, as you dug into the exposed cave section with your dynamic oxygen supply at your back, the A* will flood out into the cave. it'll flood into outer space and decrease the levels, it'll turn all of the 'fixed' <0 oxygen, smooth transition blocks it meets into dynamic blocks, and as soon as it meets the 100% oxygen, *fixed* blocks layed down during generation, it stops.

This means that outerspace will still suck from your Oxygen supply in the room you came from (via the dynamic thermodynamic simulation) and that the old fixed blocks will be made dynamic in the process, but won't walk all the way into the cave system, due to the fixed, 100% oxygen blocks.

Sorry about being confusing, hope you understand what I mean.

[phibermon]

Sorry, I missed the bit about your planet starting with 0% O2. You A* walk out from your oxygen-sources with a maximum fixed radius. You can stop walking at 'outer-space' blocks and stop walking at other 100% blocks.

But you'd also have to process all 'leak' blocks and get them to decrease the O2 levels of blocks they touch.

remember you want a given block to have a given level of oxygen, but you're not simulating oxygen levels, only storing them.

You're simulating air pressure and you want leaks to empty whole volumes, a simulation of how heat spreads across a surface is ideal.

Colder regions (low air pressure) will cause adjacent regions to loose heat more quickly (loose more O2) than regions with more air pressure. So if your O2 gen in a room can't pump out O2 faster than it's leaking, then there will eventually be no oxygen in the room except for very low levels near the O2 generator (basically nothing, as the pressure is rapidly dispersing due to the 'cold' (low air pressure) surroundings)

if in a room, your O2 gen pumps out oxygen at a faster rate than it leaks, then the whole room will be at near %100 oxygen levels, and near the leak things will be much less.

outer-space blocks simply 'delete' this 'heat' rather than accumulate it, thereby providing a bounds to the simulation.

--

This provides a very realistic simulation of air pressure, levels can raise and fall etc you just have to keep the whole system pressurized, so inputing more 'heat energy' than is being lost to leaks. No matter where in your rooms you do this, it'll propagate and work across the whole accessible space but obviously it'll take more time for O2 to travel long distances etc

You will need fixed radi of effect for O2 Generators if you're planning to pump O2 into a big interconnected cave system but then you can just tell the player that the metals in the rock are oxidizing having been exposed to O2 for the very first time, or the rock is pourus or something.

[SilverWarior]

Incredibly you seem to be working on a very similar setup as I am for your game project.

No kiding! I have also been thinking of adding similar capability into one of my games ;)

First thing I would have done on your place is replace default A* pathfinding alhgorithm with Huristics pathfinding algorithm. With this you can reduce the necessary scope that pathfinding algorithm needs to traverse.
You would define your game world something like this:
1. Lowest heuristic level contains information about each cell (voxel). Each cell also contains information to which room it belongs. Why a bit later.
2. Second heuristic level joins several cells into roms
3. On third level you join several rooms into buildings
4. Forth heuristic level joins several buildings into bases
....
The bigest problem would be writing the algorithm for determining rooms. This is something I haven't figured out yet.
Anywhay when you have information that one cell belongs to a room and another neighbouring cell belongs to space (another room) you can easily stop the simulation from traversing into space blocks by simply removing air when it travels from room cell to space cell.

As you also see from above it would be great if you would have all that information saved in a tree like form. And if you add Changed flag to every tree node you can easily make sure that simulatiuon only runs on areas (rooms) where atmospheric presure needs to be updated.


I suggest that you guys check StarMade (http://star-made.org/) as it uses similar concept. Currently its atmospheric simulation still isn't working as intended so it is disabled.
I gues they are probably facing same problems as we do :D


Anywhay I have idea for making fluid simulation which could be used for simulating both liquids and gases (atmosphere).
I intent to first make 2D based simulation and later expand it into 3D based so I can track initial bugs and lags more easily.
Unfortunately I don't have much time lately as I have started working on new workplace which has compleetly different job (still at same employer). This means I'm spending lots of time studying new literature that I need for my work.

[phibermon]

StarMade looks like it's pretty much what I had in mind, so I probably won't bother now. Looks awesome :)

Voxel engines will become the only thing in 3D one day, possibly even in the next Tech Engine from John Carmack will be a voxel one (if not then the one after that) obviously not in a minecraft style, we're talking super high res voxel engines where the voxels are as small as pixels.

I'm not really sure what I wanted to do as a game, I won't really be able to devote proper time to it until my engine hit's v1.0. I guess like everybody I just want to make a really cool game and I guess I feel that nobody is going to think it's cool if there's a dozen other games like it.

I'll keep on searching for the holy grail of Indie game development - The cool thing that nobody has yet done, or done well.

[laggyluk]

I guess like everybody I just want to make a really cool game and I guess I feel that nobody is going to think it's cool if there's a dozen other games like it.

I chose blocky voxel style because I can make a game like this single handed, without a graphics guy :p similiar to retro 2d its easier to produce graphic content without serious skills when resolution is low. Plus it let's player to modify the world in a way that traditional 3d would make very difficult if not possible to implement. i think that at some point when there is a lot of games looking 'blocky' people will stop thinking about them in terms of minecraft clones but as an alternative to polygons

[laggyluk]

hm maybe I'll start with simplest solution for starters and see how it performs. global water simulation using existing 3d world data and a thread dedicated to traversing chunk columns marked as 'wet'

[Carver413]

I chose blocky voxel style because I can make a game like this single handed, without a graphics guy :p similiar to retro 2d its easier to produce graphic content without serious skills when resolution is low. Plus it let's player to modify the world in a way that traditional 3d would make very difficult if not possible to implement. i think that at some point when there is a lot of games looking 'blocky' people will stop thinking about them in terms of minecraft clones but as an alternative to polygons
it makes since to stick with what you can do yourself, artists can be hard to find and usually want money. I think the voxel style could be greatly improved by adding more then blocks to the mix more of a lego approach could make it much more attractive while maintaining its anyone can do it style. with the Explorer project I will be experimenting with these Ideas along with the tools needed to build a library of parts to use in the game. By throwing out what is exceptable in the game we are free to mix simple with complicated and really showcase those parts while not feeling obligated to put such work into all areas of the game

[User137]

I suggest that you guys check StarMade (http://star-made.org/) as it uses similar concept.
Thanks, i will look into this game very carefully ;) Minecraft in space.

[SilverWarior]

Voxel engines will become the only thing in 3D one day, possibly even in the next Tech Engine from John Carmack will be a voxel one (if not then the one after that) obviously not in a minecraft style, we're talking super high res voxel engines where the voxels are as small as pixels.

Main advantage of voxel engines are:
1. easy implementation of destructable objects since voxels actualy represents some kinda particles from which objects are build.
2. easy colistion detection as you are simply doung Point to Square colision detection especially if all of your voxels have unform size.
3. easy content creation since at some point in our lives most of us have been playing with some blockbuilding toys (Legos and such) so such approach seems more natural to us in comparison to traditional 3D modeling. And since the maximal level of detail (number of rendered voxels at any time) that can be used in voxel engines is proportional to computer processing capability it is raising quite fast as does the computers processing capabilities.
4. voxel based objects are usually being stored in 3 dimensional arrays as a series of BlockID's and while each block definition (which texture to use for which face and such) you have great data reusability which generally results in lower memory requirements.



StarMade looks like it's pretty much what I had in mind, so I probably won't bother now. Looks awesome :)

Don't quit out just yet as there is still lots of posible inprovments for a game such as StarMade.



I'll keep on searching for the holy grail of Indie game development - The cool thing that nobody has yet done, or done well.

Good luck with that!
I have been doing the same for about 5 years now and haven't got much sucsess. Whenever it seems that I found it I realize that somebody else is already making it >:(

I do still have many ideas but most of them would require lots of work to finish which is not good for making a first game as the development might take too long due to my limited game development expirience and I might lose interest in the process.

[User137]

4. voxel based objects are usually being stored in 3 dimensional arrays as a series of BlockID's and while each block definition (which texture to use for which face and such) you have great data reusability which generally results in lower memory requirements.
Actually voxels (cubes) make very low quality models, so visually they should be compared to low-poly models. In most cases voxel approaches result in much higher memory and performance cost, especially when it comes to heightmapped poly-terrain VS voxel terrain. But as you say, voxels are very good at entertaining us ;)

[SilverWarior]

Actually voxels (cubes) make very low quality models, so visually they should be compared to low-poly models.

It all depends on the size and number of voxels being used.



In most cases voxel approaches result in much higher memory and performance cost, especially when it comes to heightmapped poly-terrain VS voxel terrain.

It is true that heightmapped poly-terrain has lower memory consumption but it is much harder of creating underground caves and such with it.
Also it is even harder creating of fully dynamically destructable terrain with heightmapped poly-terrain. Simply changing terrain height is easy but creating underground caverns, clifs, overhangs, and such is much harder.


It is true that voxel based models or terrain looks more like low poly models due to its cubigness but with some postprocessing you can improve that by replacing some of the cubes with other shapes which then alows you to get smoth edges.
One example of this is game Terraformer: http://www.vtss-llc.com/ It is true that the implementation of such postprocessing isn't best and that game itself has lots of other bugs, but you can see the idea of it.

EDIT: Another advantage of voxel based graphical engine is easy implementation of LOD (level of detail) as you can always join 4 voxels into one. And for doing this it is best to store data in octa-tree.

[phibermon]

I haven't got the links to hand but there exists voxel engines that put most poly rasterizing engines to shame. As Silverwarrior said, it's only a matter of decreasing the voxel resolution etc

Voxel models are volumetric by definition. So a voxel model doesn't need textures applied as the voxels themselves make up the 'pixels' of the texture. Whenever you've seen a CT scan of a brain, a 3D volumetric volume, that's rendered using voxels (or is ideally rendered as voxels) For example, a game that used voxels would let you cut an orange in half, see the segments seeds etc

(note this is totally different from destructable walls and things inside modern PhysX games, the texture data isn't volumetric, it's all a uniform 'wall' texture wrapped around the bits of wall)

With A poly engine, the inside of all geometry is empty space.

--

The main reason we're not seeing lots of voxel engines is we're still one generation away from cards that are powerful enough for a voxel engine to match the quality of a current generation engine.

Another reason is Skinnning (you may know it as Skeletal animation, bones etc) as with a poly model you only have to skin the vertices in the model, a small amount of data. A Voxel model can't be skinned easily. You'd have to apply the result of the current pose to every single voxel. A vast amount of processing in comparison.

Until cards are powerful enough to skin per voxel or until some clever workaround is found, we will not see mainstream voxel engines do EVERYTHING with voxels. But we will defintely see static scenes, maps etc rendered using voxels in PC games, perhaps as soon as 2 years from now.

For rendering in 3D, radiosity and all manner of high end 3D techniques, voxels are vastly preferable to polygons. In the hypothetical situation where a voxel and poly map could be rendered using the same amount of work, more advanced things such as raytracing, radiosity could be applied far quicker and more simply in the voxel engine. When a ray hits a poly and you want to know the colour, you have to calculate the texture coordinates from the face you hit then sample the colour. A ray hits a voxel, you've already got that information (although I see an issue here, the poly face will give you the surface normal, so unless every surface voxel stores it's normal, you'd have to sample surrounding voxels to determine the angles... but John Carmack said it's better and he's a lot, lot better than me)

And another big advantage is Level of Detail. in a Poly engine, you control the textures LOD (and with more recent tesselation hardware) the poly LOD seperatley.

A voxel engine has no textures as such (the colour values of the voxels in the model equating textures) and the LOD calculations are oct-tree based, so you instantly have a really simple way to handle LOD that works for everything in the same pass.

Voxel engines are a far more 'realistic' simulation of reality than poly engines. It's a poor example but a voxel engine would let you for example heat something up with a blowtorch until it was white hot, then you could watch the heat dissapate thru the model in a natural way. Or destructable terrain or blowing holes in enemies etc are ridicuously simple in a voxel engine but require some complex maths to perform boolean operations in a poly engine (Red faction anybody?)

Voxel engines are the future, don't take my word for it, take John Carmacks.

[Darkhog]

In case of voxels and animation of them, I think we need to stop thinking in terms of skeletal animation. We should treat them as... 3d sprites. In 2d sprites, you can't move thing by 0.5 pixel, so why we are trying to move voxels/rotate them by fraction of voxel size? We shouldn't.

//edit: And I'm still waiting for Euclideon's technology to go public. If it is as awesome as they say it is, it should revolutionize graphics. Just imagine Crysis, even first one, running on nothing more than i7 and intel's gpu.

[phibermon]

Euclideon is a total scam :) It's just an oct-tree voxel engine that's searched from the leaf nodes instead of the root from what I've heard them say about it. It has all the same downfalls I've already described. All that has been seen is a voxel engine demo with no *proof* of what hardware it's running on (would it of killed them to go into the device manager and show us?).

Trust, total scam. There are professors of mathematics, graphic algorithm experts, that have dedicated years of research into voxel engine rendering techniques, it's from these kind of people that the concept came from in the first place, first demonstrated at Siggraph.

You can't just skip over the mathematics, they're lying, we're talking hardcore computational theory, it can be shown that you need to do the calculations without even doing the calculations.

Plus any form of interaction with that voxel world can only happen in the classical oct-tree way, so essential things needed to make it a game engine will force it to work in the classical sence anyway.

It's no good rendering anything for a game if you can't calculate it's position, you don't want to walk thru walls and you'd like your bullets to hit your target.


And even if a bunch of coders really have some amazing new way of culling visible data that the worlds finest minds couldn't think of, the amount of data storage required to store a voxel world? say the biggest quake3 level, at a voxel resolution so you could walk right up to a wall and voxels were one pixel in size, you're talking many terabytes of data.

And to top it off go and read any technical info they've released, it's how they say it and what they don't say, total frauds just looking to get a government grant, which they did.

nearly 3 years ago this was all said, where is that tech? where's the updates? where's the latest videos? Their aren't any.

Even if they really genuinly thought they were onto something, then they have no doubt hit the inevitable conclusion that their solution is not viable when all required functionality is concidered.

[SilverWarior]

In case of voxels and animation of them, I think we need to stop thinking in terms of skeletal animation. We should treat them as... 3d sprites. In 2d sprites, you can't move thing by 0.5 pixel, so why we are trying to move voxels/rotate them by fraction of voxel size? We shouldn't.

Since most voxels have size greater than 1x1x1 pixels it is nothing wrong when you are moving them for a raction of their size.
As for skeletal animation of voxel based models you can always replace a series of voxels with a proceduraly generated 3D model to save processing time.
For instance you have a character made from voxels. Each character part is made from searies of voxels which you then join into a 3D model. You then atach this 3D model to skeletal bone for your character animation. After that everything is almost the same as with 3D character models.

If you want to see some nice voxel based character animations I would recomend taking a look at game Timber and Stone: http://www.timberandstonegame.com/
In Timber and Stone evrything except for fire particles is made with voxels.

[phibermon]

And I've just watched all the latest stuff from them, they guy makes several large terminology errors, describes absolutely nothing new, claims that a textured poly mesh can be converted to unlimited detail, when it's limited to begin with. Then he gives a measurement in cubic mm for the accuracy. It's total crap, models or any kind of poly data has no inheirant scale, it could be 1 meter or a million, it totally depends on what scale factor was chosen for units. there's no standard, to suddenly claim a resolution in mm in this context screams somebody that doesn't know what they're talking about, certainly not the developer of the worlds most advanced graphics engine.

[phibermon]

Since most voxels have size greater than 1x1x1 pixels it is nothing wrong when you are moving them for a raction of their size.
As for skeletal animation of voxel based models you can always replace a series of voxels with a proceduraly generated 3D model to save processing time.
For instance you have a character made from voxels. Each character part is made from searies of voxels which you then join into a 3D model. You then atach this 3D model to skeletal bone for your character animation. After that everything is almost the same as with 3D character models.

If you want to see some nice voxel based character animations I would recomend taking a look at game Timber and Stone: http://www.timberandstonegame.com/
In Timber and Stone evrything except for fire particles is made with voxels.

It's no good I'm afraid, yes you can attach voxel oct-tree structures to a skeletal node and produce animation like this.

But when you're talking call of duty level of quality, where the join between arm and body is smoothly interpolated between the bone states, you can't do that with voxels.

You can store the animation like a sprite, frame by frame but this adds a whole new set of problems, first the storage required for a detailed character with the amount of animations we see in a game like GTA, would be totally beyond anything we'll have even in the next 2 years. Next the animation might be dynamic (like GTA) so fixed animations are again useless.

You can animate with polys then convert the polys to voxels, but in realtime? and why not just use the polys?

[SilverWarior]

But when you're talking call of duty level of quality, where the join between arm and body is smoothly interpolated between the bone states, you can't do that with voxels.

That I agree becouse for such level of detail you would need to dynamically change the size of some voxels and this would result in much more processing required than when using polys.

[laggyluk]

main problem in voxel engine would be animating objects as phibermon pointed. here's pretty good explanation why http://www.youtube.com/watch?v=gNZtx3ijjpo (maybe in other part, my connection is slow so couldn't check)
btw anyone played ID Software's Rage? terrain there was rendered using voxels if I recall correctly. Maybe future is mixing both polygons and voxels as they shine in different domains.
Still for our 'indie' purposes high detail voxel engine is no better than traditional one. both take a mountain of money to shape decent content