One person on Reddit said about SC planets (paraphrase) "And these are full size planets that we've not seen in any other game".
Ugh. *barfs.
sorry for the double post. [wacko]
Last edited:
One person on Reddit said about SC planets (paraphrase) "And these are full size planets that we've not seen in any other game".
Oh for crying out loud!!!!
I don't know how people don't get seriously angry with how often this goes around.
It was NOT rendered in real time - the live play footage DOES NOT look the same to anything other than the most casual glance.
If you're going to try and argue please actually bring something to the table - not the exact embarrassment that proved my point. I can't even be bothered to find the attempted live play video, we've gone over this many times
One person on Reddit said about SC planets (paraphrase) "And these are full size planets that we've not seen in any other game".
DB's ted talk really does a pretty good job of explaining what PG is https://www.youtube.com/watch?v=GEVutbSqBI0
It really comes down to having seemingly complex "seeded" rules that create variations of interesting features. For landscapes and planets having good PG means complex rules that create interesting features. Not just mountains. The PG in Space Engine has had many iterations over the years and seems to do a pretty good job of creating complex features. If it's creating something procedural that stands out as a land-mark (not a hand-crafted asset) then that's pretty good PG something like a complex crater structure, diverse surface textures, cliffs or interesting realistic ravines. If it's creating something diverse like a building, city or forest or river network then it's even better.
I think some fans get confused between the high-fidelity visuals and textures handled by cryengine and the real nuts and bolts of procedural generation.
Yes..it was. It's stated right in the video. And you can even see the LOD state changes right at 18 seconds that's indicative of that.
Unless you have proof otherwise, then it's just a baseless accusation.
Yeah, because it was stated in the video that means it is true. LOD state changes also happen in non-real time renders. That proves nothing too.
That's a complete non-sequitur. The game engine uses LoD pretty much as standard - the video was rendered using the engine but not at real time probably more like 1fps with everything cranked into "pretend you're a movie CGI system" modeYes..it was. It's stated right in the video. And you can even see the LOD state changes right at 18 seconds that's indicative of that.
Got it. It must be a conspiracy then!
Got it. It must be a conspiracy then!
Got it. It must be a conspiracy then!
Caves are a two headed beast. PG caves is nothing new, so the issues is probably something else.
Monk is correct here though, while PG caves are nothing new, almost all of the cave generation systems are incredibly expensive on the hardware.
The problem with PG caves, and a big reason why you don't see them that often, is that surface geometry is usually based on height-maps, i.e. a 2-dimensional grid containing elevation data. (This is by far the most efficient method)
This means that you are only defining the top/outer layer of the terrain and have no information at all on sub-surface geometry.
There's a couple options you have for generating caves into this landscape, but all of them are pretty costly:
- Pre-built cave geometry: Easiest method and used in most games with a procedurally generated world (present in most MMOs, WoW as particularly good example). Punch a hole in your procedural surface and stick some pre-existing 3D cave meshes in there. Making this look natural around the stitches is a pretty difficult task in a fully PG environment, considering the relatively random surface materials and geometries you're working with. Star Citizen uses this approach for its landing zones.
- Stacking heightmaps: you can add two additional heightmap layers to define the top and bottom "halves" of the cave surfaces. Generating these is difficult and usually pretty costly, and the cave sides will need to be stitched together, which is no small feat. On top of that, this approach is relatively wasteful memory-wise.
- Voxel-based algorithms: The Space Engineers approach. While these algorithms are well-defined and tend to be rather cheap, voxel geometry very much isn't, as exemplified by the performance issues these types of games generally have (Minecraft used massive voxels on low-res grids without any smoothing, and even that ran terribly on most systems in the early months, voxels small and smooth enough to make caves look good would make a game world the size of Elite's planets unplayable.)
So unless there's a significant amount of gameplay to be gained, caves are generally avoided in fully procedurally generated systems, or manually placed in a procedurally generated 3D mesh.
It is worth noting that DB's TED talk was an overview of the concept of procedural generation, rather than a direct description of how any specific game actually does things.DB's ted talk really does a pretty good job of explaining what PG is https://www.youtube.com/watch?v=GEVutbSqBI0
It really comes down to having seemingly complex "seeded" rules that create variations of interesting features. For landscapes and planets having good PG means complex rules that create interesting features. Not just mountains. The PG in Space Engine has had many iterations over the years and seems to do a pretty good job of creating complex features. If it's creating something procedural that stands out as a land-mark (not a hand-crafted asset) then that's pretty good PG something like a complex crater structure, diverse surface textures, cliffs or interesting realistic ravines. If it's creating something diverse like a building, city or forest or river network then it's even better.
I think some fans get confused between the high-fidelity visuals and textures handled by cryengine and the real nuts and bolts of procedural generation.
This is from 2014 and from what I can dig up of information caves is really not that difficult to managed.
https://www.youtube.com/watch?v=CrhJq2uAY-E
Here some nice hand crafted caves done in Unity
https://www.youtube.com/watch?v=gwtC5KKtdbE
It is worth noting that DB's TED talk was an overview of the concept of procedural generation, rather than a direct description of how any specific game actually does things.
First one is a voxel-based world, which as I said can easily and cheaply generate caves, but due to the costs inherent with large voxel-based terrains this wouldn't work nearly as well with Elite, on top of being generally blocky and very ugly in appearance (mostly hidden in this case with foliage and trees, though you can clearly see it inside the caves).
Second one is a top-down game and doesn't actually bear any resemblance whatsoever as it has walls nor ceilings. It's like comparing SC/Elite's stations to Diablo 3's cities.
As I said, caves aren't impossible, but hard to get right in a fully procedural non-voxel world and generally not worth it for a game as Elite in its current state.
If you design a cave, lets say in any 3D program (pick you favorite) and use it as an asset just like the settlements, how would that work?
clearly that could be done, I know that would not be procedural generated but it could be PG generated outside the game and then incorporated as an asset?
That would atleast get it started, in Skyrim they have a lot of caves and to my knowledge they are not PG generated on the fly so to speak.
If you design a cave, lets say in any 3D program (pick you favorite) and use it as an asset just like the settlements, how would that work?
clearly that could be done, I know that would not be procedural generated but it could be PG generated outside the game and then incorporated as an asset?
That would atleast get it started, in Skyrim they have a lot of caves and to my knowledge they are not PG generated on the fly so to speak.
If I understand heightmaps correctly they can be interpreted as a 2D projection where each position corresponds to some z value (x and y become mathematically resolved into one since we have single points of reference). Add caves and overhangs into that mix and that projection (which is a simplification that is easier to generate) is no longer valid. The heightmap then has to become fully 3 dimensional where each reference point must be represented by x, y and z (x and y can still be resolved as one point but now you have to account for multiple z values at one reference point).
My, my...I think I'm rambling.
Simplify
height maps --> imagine a flat sheet a paper with points defined all over it. At each point is a value indicating height, instructions. Feed this to a machine and it transforms that paper into a 3d landscape
Including caves --> The simple flat sheet of paper is no longer sufficient and the instructions need a further dimension to allow for multiple variables at each point on the paper. it is an order of magnitude more complicated.
Monk said:In a full PG scene, the CPU is doing a lot of heavy lifting in iterating the seeded algorithm to build the geometry. This is then textured (probably according to yet another layer of PG calculation) which is all finally loaded to memory and rendered by the GPU for display.