Game Discussions Star Citizen Discussion Thread v12

Viajero

Volunteer Moderator
"Actually, the worst case is if all the players decide to spread themselves out between all the locations assigned to a single server node. That way, the poor server will be trying to deal not only with all of the players but it will also need to have streamed in all of its locations"
Whoa. The more CIG talks about its crappy planetary generation system the worst it sounds and the more I appreciate FDEV´s or HG´s elegant proc gen client based solutions to be honest...
 
Last edited:
Whoa. The more CIG talks about its crappy planetary generation system the worst it sounds and the more I appreciate FDEV´s or HG´s elegant proc gen client based solutions to be honest...
"CIG's Crappy Planetary Generation" "FDEV´s or HG´s elegant proc gen"

 
Whoa. The more CIG talks about its crappy planetary generation system the worst it sounds and the more I appreciate FDEV´s or HG´s elegant proc gen client based solution to be honest...

I’m not clear whether the planet tech is a specific issue here. (Like I’d be intrigued to know if it’s come with downstream issues for the intended scale / networking etc, which classic proc gen wouldn’t have etc. But there’s no smoking gun there AFAIK)

It seems to be more an issue of hosting that much real estate on a single server. (Even if you’re only dealing with a single planet, if it’s maxed out with players the server still has a lot of work on its plate).

I’m not sure how a classic proc gen planet would be different on that front though. You’d still have to generate a collision mesh etc I suspect.
 
I’m not clear whether the planet tech is a specific issue here. (Like I’d be intrigued to know if it’s come with downstream issues for the intended scale / networking etc, which classic proc gen wouldn’t have etc. But there’s no smoking gun there AFAIK)

It seems to be more an issue of hosting that much real estate on a single server. (Even if you’re only dealing with a single planet, if it’s maxed out with players the server still has a lot of work on its plate).

I’m not sure how a classic proc gen planet would be different on that front though. You’d still have to generate a collision mesh etc I suspect.
ED generates a world full of stars. 1000 players converging on a single planet is a different matter and more how they make matches with their networking solution which is quite nifty too.
 

Viajero

Volunteer Moderator
I’m not clear whether the planet tech is a specific issue here. (Like I’d be intrigued to know if it’s come with downstream issues for the intended scale / networking etc, which classic proc gen wouldn’t have etc. But there’s no smoking gun there AFAIK)

It seems to be more an issue of hosting that much real estate on a single server. (Even if you’re only dealing with a single planet, if it’s maxed out with players the server still has a lot of work on its plate).

I’m not sure how a classic proc gen planet would be different on that front though. You’d still have to generate a collision mesh etc I suspect.
Well, indeed, the comment was addressing one of the main issues acknowledged by CIG there in that quote, namely the server streaming limitation when all players in that server are spread out. Of course in the case of SC the issue is with all assets in general, planets, biomes and all content and textures etc in them being a subset therein. But that is precisely one of the issues that FDEV´s and HG´s solution manages to very elegantly solve with client based proc gen, as opposed to planetary content based on actual memory loaded assets managed by a server for all players in it.

HG´s or FDEV´s client based proc gen system is limited mainly by player data network bandwidth, not so much by asset streaming. CIG´s solution is constrained by both.
 
Last edited:
I’m not clear whether the planet tech is a specific issue here. (Like I’d be intrigued to know if it’s come with downstream issues for the intended scale / networking etc, which classic proc gen wouldn’t have etc. But there’s no smoking gun there AFAIK)

It seems to be more an issue of hosting that much real estate on a single server. (Even if you’re only dealing with a single planet, if it’s maxed out with players the server still has a lot of work on its plate).

I’m not sure how a classic proc gen planet would be different on that front though. You’d still have to generate a collision mesh etc I suspect.

As far as i understand it, its generated on the fly by the client based off the terrain algorithm. No need for any server to do any lifting.
 
and more how they make matches with their networking solution which is quite nifty too.

Yep that’d be the thing. Groupings driven primarily by proximity etc, I believe. (And therefore none of the same issues with having to handle all planet-wide activity etc)

But, y’know, instancing. So… * spitting noise *

Of course in the case of SC the issue is with all assets in general, planets, biomes and all content and textures etc in them being a subset therein. But that is precisely one of the issues that FDEV´s and HG´s solution manages to very elegantly solve with client based proc gen, as opposed to planetary content based on actual memory loaded assets managed by a server for all players in it.

I dunno, I think it’s still an open question. Would like to see a pro breakdown of how the techniques differ in terms of performance load, and how both might perform under SC’s proposed networking, for sure. (There seem to be some comparable issues that mean they might not differ hugely. Both need to handle texture at scale, scatter generation, flora to varying degrees, for example. Both will need to generate nav & collision meshes for large areas etc.)

It does seem strange to me that CIG have to network the collision mesh itself. (You’d think that could be client side, with just player behaviours networked etc). Would certainly make a difference if a proc gen system definitely could be purely done on the client. Would be good to hear all this from the horse’s mouth though.

TLDR: I wouldn’t be surprised if CIG had done another number on themselves in the pursuit of fidelity ;). But don’t feel like we’ve got conclusive info at this point.
 

Viajero

Volunteer Moderator
Yep that’d be the thing. Groupings driven primarily by proximity etc, I believe. (And therefore none of the same issues with having to handle all planet-wide activity etc)

But, y’know, instancing. So… * spitting noise *



I dunno, I think it’s still an open question. Would like to see a pro breakdown of how the techniques differ in terms of performance load, and how both might perform under SC’s proposed networking, for sure. (There seem to be some comparable issues that mean they might not differ hugely. Both need to handle texture at scale, scatter generation, flora to varying degrees, for example. Both will need to generate nav & collision meshes for large areas etc.)

It does seem strange to me that CIG have to network the collision mesh itself. (You’d think that could be client side, with just player behaviours networked etc). Would certainly make a difference if a proc gen system definitely could be purely done on the client. Would be good to hear all this from the horse’s mouth though.

TLDR: I wouldn’t be surprised if CIG had done another number on themselves in the pursuit of fidelity ;). But don’t feel like we’ve got conclusive info at this point.
Yeah, in terms of asset handling, memory loading required and limits thereof I think it is quite clear cut, no? That is precisely the main value proposition of proc gen and the main reason Delamar had to go and the reason behind the CIG comment that started this discussion. That was the case in 1984, and it is still today. If the client can handle the planet asset generation thanks to proc gen streaming, that is a ton of things less in memory for the server or clients themselves to handle and likely allowing for higher tick rates.
 
Last edited:
Investors are mostly not disclosed publicly. I knew of at least two (one has made a nice YT series, the other personally). So
Im gonna have to agree with obsidianant on this one, that the experience of getting into your ship, flying in atmosphere, flying in space, landing on planets, etc is unrivaled.
Agreed. I just wish atmo flight and re-entry was more visceral and realistic, requiring at least some amount of piloting skills, not asking for full orbital mechanics like KSP but maybe aero effects such as lift, mach compression, the effect of center of gravity vs center of lift, etc. and justify the "aero optimized" ships, vs those which are clearly flying bricks. That would bring more personality to each ship, also it would help put people in different roles than just flight jock with full control of all the weapons and promote a bit more team play, since SC is a lot less annoying when playing with a group.
 
Yeah, in terms of asset handling, memory loading required and limits thereof I think it is quite clear cut, no? That is precisely the main value proposition of proc gen and the main reason Delamar had to go and the reason behind the CIG comment that started this discussion. That was the case in 1984, and it is still today. If the client can handle the planet asset generation thanks to proc gen streaming, that is a ton of things less in memory for the server or clients themselves to handle and likely allowing for higher tick rates.

It sounds possible sure, but there are various elements I’ve never seen nailed down, so it’s still in the assumption zone for me.

Like in CIG’s specific case, are they locations limited in Staunton due to planetary assets, regarding the server load, or is it more the landing zones say, due to NPC activity, culling operations etc? Or on surfaces, stuff like the collision mesh generation, rather than assets per se. (I’d assume assets would be a client side issue in most cases).

It’d be interesting to see some case studies on both client side performance and server load for both approaches essentially. (The 300mb ceiling for textures is an interesting start on the former, and the networked collision mesh on the latter. But needs more ;))

There are just a lot of details I could do with being cleared up ¯\(ツ)/¯
 
Agreed. I just wish atmo flight and re-entry was more visceral and realistic, requiring at least some amount of piloting skills, not asking for full orbital mechanics like KSP but maybe aero effects such as lift, mach compression, the effect of center of gravity vs center of lift, etc. and justify the "aero optimized" ships, vs those which are clearly flying bricks. That would bring more personality to each ship, also it would help put people in different roles than just flight jock with full control of all the weapons and promote a bit more team play, since SC is a lot less annoying when playing with a group.

There is a pretty big difference between a fighter that is good in atmo and a fighter that is not. Thats all that matters really.
 
There is a pretty big difference between a fighter that is good in atmo and a fighter that is not. Thats all that matters really.

Have to agree. If they went for realism most SC ships would break apart or flip over flying through atmosphere anyway. Realism shouldn't and can't be the goal here. It should highlight the differences in capabilities and of course, fun.

It is a shame though that a lot of ships in atmosphere look like they are flying in no-clip mode though, its especially jarring with the bigger ships.
 
No worries, also 2016 sometimes actually mean 2017, 2020 or even "done when it’s done". Or "Weeks, not months" actually meaning years. Many things meant for 2014 are not even in the « alpha » yet.

So I fully agree with you that it’s been a while we are used to CIG´s word being, by and large, worthless.
I think, by this point, the key failure of those of us who are skeptical of CI-G is that we have never actually been able to nail down what timescale the estimates for delivery are on.

Have they missed delivery estimates by a standard human timescale? Yes, but perhaps they are on a geological timescale...
 
Back
Top Bottom