The Star Citizen Thread v5

Status
Thread Closed: Not open for further replies.
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.
 
Last edited:
Well of course they haven't seen them anywhere else. Because the rabid fans dismiss any other game which is not Star Citizen, so they have no comparison.

Just like they say Elite has no content, but they are elated to push three buttons in a SC "mission".
 
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

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.
 
One person on Reddit said about SC planets (paraphrase) "And these are full size planets that we've not seen in any other game".

Yes, they are full of it, lies lies lies all day long, how can they even expect us to take anything thing they say serious?

- - - - - Additional Content Posted / Auto Merge - - - - -

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.

Actually it was CR using a hologram of DB while he was explaining how they did it in SC /s
 
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.
 
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.
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" mode

The point is anyone can make something look insanely good if it's ok for it to run very very slowly, the real-time version turned out to be rather juddery and using far lower surface height-map resolution, totally different fog effects and much lower detail base models - and that in what appears to have been a physics free version from the floating ship so even slower in the real game...... and all that in a public demo machine that is no doubt fairly top-end to make things look as good as possible

Just because the snake oil says it'll cure all your ills doesn't mean it will sadly
 
Last edited:
Got it. It must be a conspiracy then!


Well aren't you special.

No, more like a company well known for misinformation, half-truths, in some cases outright lies, obfuscation, and misdirection well they aren't exactly on the up and up.

Or, just take a page from RSI/CIG and the rabid fan base - IT'S ALL DEREK SMART'S FAULT!
 
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.

For people interested in procedural generation of planetary surfaces, I'd highly recommend going through this blog by John Whigham. :)
He talks about a lot of stuff people are discussing here, such as the application of terrain textures (like snow) through tri-planar mapping.
It also contains links to similar projects.
 
Last edited:
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.

Well, I don't think its a huge issue today.

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
 
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.
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.
 
Last edited:
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

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. :p

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.
 
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.

Hello Ben, you've probably been asked before but do you play elite? Any other games you play/ take inspiration from at the moment?

Also any exciting fish tank developments?
 
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. :p

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.

You'd have to define rules on where these caves can be placed (like settlements, which still float awkwardly off of hillsides from time to time) and how their placement deforms the surrounding terrain.
As I mentioned before, you'd have to punch a hole into the PG surface (can be done relatively easily by discarding/not rendering all intersecting polys) to neatly fit the cave entry.
The cave would probably stand out quite a bit rather than be smoothly blended with the surrounding terrain, but I see no reason why this would not be possible in Elite.
They'd stand out pretty hideously as the surrounding terrain LOD-ed, but that's the same for crash sites and POIs.

Only reason I'd see this being a problem would be that you'd have to disable surface collision on the polys you're discarding, which might be very tricky depending on how the surface collision is implemented.

Skyrim and WoW both generated their terrain offline using a mix of procedural methods (for the basic shape) and editing tools (to tweak them for gameplay). Therefore their situations are a bit different, as the cave meshes can be placed by hand to make them look good. Skyrim goes even further by having caves as a separate level (having the entrance visible/interactable in the overworld and passing through a loading screen for the internals).
 
Last edited:
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.

Skyrim has very few caves that are rendered in the overworld. Actually, most are overhangs, very shallow caves or are entrances to a cave room that is loaded seperately. Skyrim can simply load these assets into memory which isn't intensive on the CPU, though can be feat for the GPU as it needs to render the visuals. 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. 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.
 
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.

You understand them correctly, except for the fact that just as with a piece of paper, you can technically cut a hole in it and glue some other paper object on it :p

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.

Also if you parallelise it properly, you can let the GPU do the heavy lifting for the algorithm as well. :D (Praise compute shaders)
 
Last edited:
Status
Thread Closed: Not open for further replies.
Back
Top Bottom