Solving the 'sandbox' desire, geniuses needed!
Author
Imagine, a snowlandscape where you are in, the northpole, everything is snow, snow masses. The ''sandbox'' feature: Being able to manipulate these snow masses and shape all kinds of things out of it.
A simple tactic to manipulate that landscape with an avatar would be ''sucking'' and ''spitting''. You can ''suck'' snow into your mouth and spit it out again. Objective: building cities (and having snowbal fights)Question: Is it possible?
A possible solution, or how such a map could be build, a 3d cube divided into very tiny cubes all next to eachother. Those little cubes, almost invisible for the eye, like a pixel, have two possible states, ''on'' or ''off'', eather visible, the mass is visible, the snow is there or ''off'', no snow, empty, air.
Who has more information on this? Is this possible to implement and how would you do it? Anyone seen something before that looks like this? Anyone able to realize this?
From what I heard, it''s extremely difficult to model any kind of fluid behavior. But if someone can come up with a good way, I want to know too
fun... I wouldnt make it be 3d. Do something like worms armegetton (sp?) (2D) except 1) without the weapons (mabye) (except the ninga rope) 2) realtime 3) worms "suck and spit" the dirt..
Yes, it can be done. If it can be done in realtime on consumer level hardware is another question. But, if you optimize it to the extreme, and use some kind of LOD scheme, it might work on a good 3D card.
This is how you do it:
You have a 3D volume of space that is divided with a 3D grid, creating voxels. Now, what makes your snow flakes flow around ? Air. So, you have to model air dynamics. You have to apply a fluid dynamics simulation onto that 3D voxel grid, for example the Navier Stokes equations, that are commonly used for that kind of problem. You can see it as a huge 3D integrator that processes forces applied to the grid cells, computes cell pressure, air velocity and movement.
You now have a dynamic pressure field. Next step is to create flow-lines along the 3D isobares, that are visualized as long splines, flowing through the 3D volume, according to winds and acting forces. Your snowflakes are particles, that have to be programmed to follow those flowlines, with a certain amount of fractal variancy (eg. Perlin noise).
While the result is very impressive, it''s *extremly* hard to code that, esp. a stable 3D NSE solver with implicit integrator (the standard Euler integrator won''t bring you very far here). I have done something similar for a smoke / vapour simulator, it was *very * hard to get it approx. stable. But it works in realtime.
If you''re serious about doing that, I could dig out some interesting papers, with equations, etc. There is a lot of research being done in this domain.
This is how you do it:
You have a 3D volume of space that is divided with a 3D grid, creating voxels. Now, what makes your snow flakes flow around ? Air. So, you have to model air dynamics. You have to apply a fluid dynamics simulation onto that 3D voxel grid, for example the Navier Stokes equations, that are commonly used for that kind of problem. You can see it as a huge 3D integrator that processes forces applied to the grid cells, computes cell pressure, air velocity and movement.
You now have a dynamic pressure field. Next step is to create flow-lines along the 3D isobares, that are visualized as long splines, flowing through the 3D volume, according to winds and acting forces. Your snowflakes are particles, that have to be programmed to follow those flowlines, with a certain amount of fractal variancy (eg. Perlin noise).
While the result is very impressive, it''s *extremly* hard to code that, esp. a stable 3D NSE solver with implicit integrator (the standard Euler integrator won''t bring you very far here). I have done something similar for a smoke / vapour simulator, it was *very * hard to get it approx. stable. But it works in realtime.
If you''re serious about doing that, I could dig out some interesting papers, with equations, etc. There is a lot of research being done in this domain.
Very interesting idea, I''ve never even thought about this. Basically making snow forts and having snowball fights for territories, right?
Now do you assume you can dig down into the terrain or do you just add to it?
If you just add you can ''get'' snow that doesn''t effect the amount on the floor, and then use this snow to build stuff or throw.
The other option is to allow the terrain to be altered. Where getting snow decreases the amount on the ground.
This sounds like a very doable engine if designed correctly. I would think that a polygon terrain engine would be prefered, a voxel engine might be interesting however not many people have designed full voxel engines and it is has not been explored.
The primary issue that would be is the level of complexity. To create realistic scenes of snow you would need a very high density. While you could have a variable lod for rendering just the memory usage would be high.
Say a terrain that is 100ft x 100ft, a moderate size area, to have somewhat realistic terrain you would probably want to model down to inches. So that''s an array of 1200 x 1200, now you would also have to have a good gradient of ''depths'' so I''d think that you would want 16bit so that''s 1200x1200x2 bytes, now each vertex would also have to store a color (it''s snow so just various white),that could be another byte (probably could also have realtime shadows). Now that''s 4.3MB, not too bad. However if you want to have 3d terrain, ie able to go under snow, say making a igloo, you would have to be able to store 3 layers, the top layer, bottom of top layer, top of bottom layer. So that would be about 12.9MB which is alot bigger. Other options would be able to store a static terrain, and dynamic ''stuctures'' above ground.
Another option could be something like the cube 3d engine posted a while back on opengl.org that was a 3d game using a 2d map, that had dyncamic heights, floors and ceilings.
I''d definately suggest looking into this.
Now do you assume you can dig down into the terrain or do you just add to it?
If you just add you can ''get'' snow that doesn''t effect the amount on the floor, and then use this snow to build stuff or throw.
The other option is to allow the terrain to be altered. Where getting snow decreases the amount on the ground.
This sounds like a very doable engine if designed correctly. I would think that a polygon terrain engine would be prefered, a voxel engine might be interesting however not many people have designed full voxel engines and it is has not been explored.
The primary issue that would be is the level of complexity. To create realistic scenes of snow you would need a very high density. While you could have a variable lod for rendering just the memory usage would be high.
Say a terrain that is 100ft x 100ft, a moderate size area, to have somewhat realistic terrain you would probably want to model down to inches. So that''s an array of 1200 x 1200, now you would also have to have a good gradient of ''depths'' so I''d think that you would want 16bit so that''s 1200x1200x2 bytes, now each vertex would also have to store a color (it''s snow so just various white),that could be another byte (probably could also have realtime shadows). Now that''s 4.3MB, not too bad. However if you want to have 3d terrain, ie able to go under snow, say making a igloo, you would have to be able to store 3 layers, the top layer, bottom of top layer, top of bottom layer. So that would be about 12.9MB which is alot bigger. Other options would be able to store a static terrain, and dynamic ''stuctures'' above ground.
Another option could be something like the cube 3d engine posted a while back on opengl.org that was a 3d game using a 2d map, that had dyncamic heights, floors and ceilings.
I''d definately suggest looking into this.
Voxel technology is based on the concept of a 3D pixel (A voxel is a 3D pixel), being essentially what you described, 3D cubes the size of a pixel. This tech is what''s used in Novalogic''s graphics engines to create the smooth scrolling landscapes in their games (though they use standard polygon methods for rending all other objects). One of the problems this technology is plagued with is the lack of hardware acceleration for it. Games like Delta Force need to be run at lower resolutions cause the landscapes are rendered with software, with very little if any hardware acceleration. But that lack is due to it''s lack of usage in the gaming industry. I don''t know if anyone besides NovaLogic uses it today (one of those catch 22 things). It could be a great option for 3D engines if it had more hardware support.
Once you get into the concept of dynamically deformable voxel landscapes... now you''re talking SERIOUS number crunching. We''re talking totally crippling even the fastest of PCs out there today. Trying to do it using tiny 3D polygon rendered cubes isn''t gonna fly either. Each cube will need a minimum of 12 polygons (2 per side). To get decent resolution landscapes you''re going to need a serious number of cubes. Even if we say 1 cube per square inch (using real world measurements just to get a gauge, not going to concern ourselves with scaling it to game dimensions) that''s 144 cubes per square foot. 1,728 cubes per cubic foot (you want some depth to that snow, don''t you? a 10 square yard area 1 foot deep would require 1,555,200 cubes, that''s 18,662,400 untextured, unlit polygons for a 10 yard square. That''s not including the physics engine for those 1.5 million cubes. Ouch.
Once you get into the concept of dynamically deformable voxel landscapes... now you''re talking SERIOUS number crunching. We''re talking totally crippling even the fastest of PCs out there today. Trying to do it using tiny 3D polygon rendered cubes isn''t gonna fly either. Each cube will need a minimum of 12 polygons (2 per side). To get decent resolution landscapes you''re going to need a serious number of cubes. Even if we say 1 cube per square inch (using real world measurements just to get a gauge, not going to concern ourselves with scaling it to game dimensions) that''s 144 cubes per square foot. 1,728 cubes per cubic foot (you want some depth to that snow, don''t you? a 10 square yard area 1 foot deep would require 1,555,200 cubes, that''s 18,662,400 untextured, unlit polygons for a 10 yard square. That''s not including the physics engine for those 1.5 million cubes. Ouch.
You could fake it.
If the snow isn''t a particle until it leaves the ground it should be easier at least. You then need to show the actual snow moving, probably using those fluid dynamics someone mentioned earlier. For the terrain, you need something that can deform and that you can deform easily. I think I remember seeing a tutorial on deformable terrain here on gd.net but I''m not sure. I''m also not a graphics person so I don''t know what would be easiest to deform. I''m also pretty sure the next term is used really for isometric games, but maybe you wanna go isometric, but the important part is what the word sounds like, not actual meaning, height-map!
If the snow isn''t a particle until it leaves the ground it should be easier at least. You then need to show the actual snow moving, probably using those fluid dynamics someone mentioned earlier. For the terrain, you need something that can deform and that you can deform easily. I think I remember seeing a tutorial on deformable terrain here on gd.net but I''m not sure. I''m also not a graphics person so I don''t know what would be easiest to deform. I''m also pretty sure the next term is used really for isometric games, but maybe you wanna go isometric, but the important part is what the word sounds like, not actual meaning, height-map!
AP: heightmaps are actually exactly what he needs.
Avator: Make a heightmap terrain, use fluid dynamics to make snow fly around, and when it settles on the ground, simply update the heightmap. Couldn''t be easier (at least the terrain deformation part). No need for voxel rendering whatsoever.
Avator: Make a heightmap terrain, use fluid dynamics to make snow fly around, and when it settles on the ground, simply update the heightmap. Couldn''t be easier (at least the terrain deformation part). No need for voxel rendering whatsoever.
Oh, and this part is probably pretty obvious but I forgot to mention it. You tie in the deformation according to a function relating it with sucking time.
Don''t forget level-of-detail, lod.
Anyone know if the force is going to lessen linearly or exponentially or geometrically or logarithmically?
Don''t forget level-of-detail, lod.
Anyone know if the force is going to lessen linearly or exponentially or geometrically or logarithmically?
As far as building walls or what not have the player able to spit out different "streams" like you can use different brushes in your paint program. Have a narrow stream for walls and or a tree trunk then change to a bigger fluffier brush for the top of the tree or to cover a large area or whatever.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement