Sony's Kin - the next big ego shooter?
- Thread starter Phil
- Start date
Ok... but if an entire terrain is generated by a seed number, how do you determine that you're only rendering/generating what you're seeing if you're not saving anything but the seed number?
Unless of course you only save what you're seeing into a buffer and load more dynamically as they come into view. One problem though with this would be probably memory once you step up to a point where draw distance will kill memory. Other problems would be LOD-algorithms I suppose...?
Admittedly, I haven't fiddled around with procedurally generated terrains - if it's something I'm missing, I'd be greatful if you could explain it.
Phil said:Ok... but if an entire terrain is generated by a seed number, how do you determine that you're only rendering/generating what you're seeing if you're not saving anything but the seed number?
Unless of course you only save what you're seeing into a buffer and load more dynamically as they come into view. One problem though with this would be probably memory once you step up to a point where draw distance will kill memory. Other problems would be LOD-algorithms I suppose...?
Admittedly, I haven't fiddled around with procedurally generated terrains - if it's something I'm missing, I'd be greatful if you could explain it.
I didn't mean that you would only use the seed number to generate the terrain. Then you would have no control over the type of terrain you want to make. But to make a terrain you need random numbers, and you make those from the seed number.
I'm not sure I quite understood some of your questions. I'll just outline one way to make a fractal tilebased "on demand" terrain. It's not the best way to do it because the terrain generation part wouldn't make too nice terrain tiles, but it's easy to explain.
Start out with a 256x256 heightmap. This is a low resolution version of the terrain we want. To make a terrain tile you take four neighbour points from the low resolution heightmap and fill in the details between.
Code:
step 1 step 2 step 3 step 4 step 5
X X | X-.-X | X x X | X.X.X | XxXxX
| | | | | | . . . | x.x.x
| . . | x-.-x | X.x.X | XxXxX
| | | | | | . . . | x.x.x
X X | X-.-X | X x X | X.X.X | XxXxX2. Make four new points (.) by averaging together the two closest control point and adding a random number.
3. Average together the new points(x) plus a random number to make a new middle point
4. Repeat step 2, but scale down the random number (we want to make finer and finer details)
5. Repeat step 3, and so on...
You can choose how many times you want to repeat these steps to get the LOD level you want. You might get cracks between the tiles but you can hide that by adding extra polygons around the edge that point down into the terrain. (I'm thinking a triangle based terrain, but this same algorithm would also work for voxels)
Now as the player moves around in this world make new tiles when he moves towards new control points, and discard old tiles as he moves away from them.
jvd said:
yeah wasn't it the first Outcast? no i don't think so....
i never saw the game in action, how good did it look compared to *normal* games? and in what way did it look good?
also, since voxels require loads of CPU power, wouldn't that be great for PS2? i mean, we always talk about how good the EE is and all...
london-boy said:
The game looked okay. the water was amazing though. It also required more system ram than other games out at the time . so i dunno . Does the gs support voxels ? If it doesn't then its basicly the ee doing al lthe voxel stuff in software. Not very fast and may cut down power for polygons for other parts of the engine .
i really loved the water effects in Virtua Fighter 4, (stage where the fighters fight in that pool thing, i think it's called the Palace or something)
the water there moved much more realistically than most games out there
the water there moved much more realistically than most games out there
Outcast was a wicked engine. The problem with it was the fact that it couldn't be accelerated by a graphics card.
<speculation>
As for using Voxels in new games, especially those for consoles, such as the PS2, you'd have to leverage the CPU power.
I figure the terrain is stored as a height map in a quad tree. All the major features of the terrain are stored as such. The problem is these trees would be insanely large if you wanted to store them in system RAM. You'd probably end up sectioning off the terrain.
Even then I figure it's too large. So, they'll start using some procedural techniques, possibly embedding a description of the surface via a function from the current point to it's neighbours. The question is whether this will actually yield enough compression and not be super CPU intensive such that you will lose too much CPU power doing this.
Also, I wonder if they're pulling some tricks with the IPU such as the one shown by faf.
</speculation>
Well that's it for my random thoughts.
<speculation>
As for using Voxels in new games, especially those for consoles, such as the PS2, you'd have to leverage the CPU power.
I figure the terrain is stored as a height map in a quad tree. All the major features of the terrain are stored as such. The problem is these trees would be insanely large if you wanted to store them in system RAM. You'd probably end up sectioning off the terrain.
Even then I figure it's too large. So, they'll start using some procedural techniques, possibly embedding a description of the surface via a function from the current point to it's neighbours. The question is whether this will actually yield enough compression and not be super CPU intensive such that you will lose too much CPU power doing this.
Also, I wonder if they're pulling some tricks with the IPU such as the one shown by faf.
</speculation>
Well that's it for my random thoughts.
The octree tagged with hermite data described at last Siggraph is closely related to voxels, and a good way of storing destructable geometry.
I doubt it will use voxel rendering in the sense of raycasting or splatting, it is probably just a convenient intermediate representation which allows for easy updating ... and converted to poly's before rendering. Just like simple heightmaps, which are also often called voxel terrain. Voxel rendering in the sense of raycasting terrain across pixel columns like it was used in games of yesteryear does not allow 6 degrees of freedom easily.
I doubt it will use voxel rendering in the sense of raycasting or splatting, it is probably just a convenient intermediate representation which allows for easy updating ... and converted to poly's before rendering. Just like simple heightmaps, which are also often called voxel terrain. Voxel rendering in the sense of raycasting terrain across pixel columns like it was used in games of yesteryear does not allow 6 degrees of freedom easily.