The Star Citizen Thread v5

Status
Thread Closed: Not open for further replies.

Ben Parry

Ben Parry
SkUnimatrix said:
I'll quote a friend of mine who works around big data said to me during lunch one day this past summer:

"This whole 64-bit precision thing doesn't make sense to me unless they need it because they are dealing with really small numbers. Large numbers aren't a problem, it's small numbers where you get into floating point calculation errors become a factor. And that would only be a problem if they've scaled down the objects in order to make the "universe" seem to look big."
Click to expand...
Your friend may need to brush up on his basics then. The key thing about floating point is, well, the way its point floats. What this means is that you always have the same range of relative precision, but as the numbers get larger the precision at the small end goes down. Float32 has about 7.22 decimal digits of precision, so when a coordinate is around 1km, the most precise number it can represent is quantising in the millimetre range. 10km, it's in the centimetre range, etc. Point is: it's not float64 to allow the big numbers to get big enough, it's float64 to let you still do small precise things when you're a long way from the centre of the system.
Float64 has nearly 16 decimal digits, so you lose mm precision somewhere between the orbits of Jupiter and Saturn. It's actually possible to do even better for the same bitrate if you're willing to put a hard cap on the system boundary instead of a slowly-goes-to-hell zone, see http://eelpi.gotdns.org/blog.wiki.html and select "A matter of precision" from the sidebar:
I think the easiest way to encapsulate this (if you're an OOP fan) is to make a "position" class that holds your chosen representation, and the only operations you can perform on that class (aside from copies and the usual) are subtracting one from another to give a standard float32 vec3, and adding a float32 vec3 to a position to get another position. So it means you can't accidentally use a position without doing calculations relative to another position. The same goes for time - internally you might use a 32.32 number, but all the outside world needs to know is what TimeA-TimeB is, and that can be a float32 quite happily. Similarly, the only operation you need to do on a time is adjust it forwards or backwards by a timestep, and it's fine to have the timestep as a float32. You should find that those operations are all you actually need. If not, then it's probably time to refactor some code, because you're likely to have problems when doing things at different distances from the origin, or at different times.
Click to expand...
He's pretty negative about just using float64 instead of float32, and he's probably right for cases where you're starting an engine from scratch, but I imagine it would have taken a hell of a lot more work to thread it into CryEngine.
frostypaw said:
Oh and yeah the 64bit thing to give bigger maps means everything got small yes. Rather than using double-precision they've used the scaling as if 32bit across a full 64bits so compared to actual double precision modelling it's exactly the same precision because everything is tiny were it mapped to the normal max scale of a cryengine map.

Nothing wrong with doing that really, but it's either double precision or it's X times larger not both. Oh and still peanuts compared to space
Click to expand...
See above - floating point just doesn't work like that. The only gain you'd get from shrinking the scale of stuff would be if there were some hardcoded scene size limits that for some reason you couldn't change. Besides that, halve the size of the scene and you halve the size of the precision errors, but you also halve the size of the things that have the errors, so you end up (from a player's perspective) with no change. Better to just find where the scene size was hardcoded and change it.
 

lysan

lysan
Ben Parry said:
Your friend may need to brush up on his basics then. The key thing about floating point is, well, the way its point floats. What this means is that you always have the same range of relative precision, but as the numbers get larger the precision at the small end goes down. Float32 has about 7.22 decimal digits of precision, so when a coordinate is around 1km, the most precise number it can represent is quantising in the millimetre range. 10km, it's in the centimetre range, etc. Point is: it's not float64 to allow the big numbers to get big enough, it's float64 to let you still do small precise things when you're a long way from the centre of the system.
Float64 has nearly 16 decimal digits, so you lose mm precision somewhere between the orbits of Jupiter and Saturn. It's actually possible to do even better for the same bitrate if you're willing to put a hard cap on the system boundary instead of a slowly-goes-to-hell zone, see http://eelpi.gotdns.org/blog.wiki.html and select "A matter of precision" from the sidebar:

He's pretty negative about just using float64 instead of float32, and he's probably right for cases where you're starting an engine from scratch, but I imagine it would have taken a hell of a lot more work to thread it into CryEngine.

See above - floating point just doesn't work like that. The only gain you'd get from shrinking the scale of stuff would be if there were some hardcoded scene size limits that for some reason you couldn't change. Besides that, halve the size of the scene and you halve the size of the precision errors, but you also halve the size of the things that have the errors, so you end up (from a player's perspective) with no change. Better to just find where the scene size was hardcoded and change it.
Click to expand...

Good explanation, thanks Ben.
 

SuperG

S
Rolan said:
Reverse the Verse: Episode 2.09
TLDR
  • Today’s RTV was in the UK featuring Technical Designers Johnny Ducavious and Andrew Nicholson in part one, and part two featured Lead Technical Designer John Crewe, and Technical Designer, Will Maiden.
  • First part discussed the flight model changes which they clarified does not affect the actual physics of the flight model itself, but rather the numbers that go into the algorithm itself.
    • In testing, they’re slowing down the SCM speed of ships, while not changing the Blackout and Redout levels to promote less jousting gameplay and a more playable experience.
    • They’re also working towards making the Afterburner having a bigger impact in combat by giving it more fuel and tweaking it in other attributes.
    • Weapon ranges are being lowered in some cases to see whether or not that impacts gameplay in a positive way, slower missile speeds are being tested as well.
    • Every weapon is being tweaked in order to better define their intended role, feedback from the Evocati and eventually backers will solidify the stats.
    • As per usual, anything regarding the balance changes is subject to change and is not final and should not be assumed until it has been declared as such.
  • Second part featured Radar and Scanning and how it will pan out down the road.
    • They stressed this heavily before the discussion that the Radar and Scanning is only a first iterative pass. I will paraphrase briefly their explanations on a lot of what they discussed, but if this is an area you’re interested in or had concerns about the “Golf swing” please read the full summary where applicable or watch the Youtube video(When it’s up)
    • The “Golf Swing” as some have toted is designed as a short range mechanic using Radar, it can be used to seek out targets within visual range that are hidden on radar. The more you charge the “Pulse” the more ground you’re going to cover, this in turn allows the hidden to be found. The catch is that if you charge your system too much, you might overload your radar and be “Blind” for a period of time with the hunter now becoming the hunted.
    • Radar before this was only you either see them, or you don’t, no inbetween. Item system 2.0 allows them to do much more in terms of what can be seen and how. You’ll be able to cross scan via physical signature and EM/Infrared scan based off those parameters.
    • It is possible to fake the size of your ship by producing a larger EM/Infrared signature, but via cross scan it’s not.
    • Scanners will be like how powerplants, coolers, and other modules are tiered and how some are better than others. An example being a Freelancer will look at an asteroid and see, hey that’s a rock. A Carrack will go, I can see that Asteroid is composed of X, Y, Z, of this amount. A Prospector will go, that’s where X is on the asteroid.
    • They have lots more planned for Radar and scanning so what you saw from ATV is only a first pass of the system in general.

Sean Tracy on 64-bit Engine Tech & Procedural Edge Blending
https://www.youtube.com/watch?v=OB_AI9ukSp8
Click to expand...
Very interresting and also my opinion that a Full licenced game engine has benifit of very well and advance content pipeline. So where team can be productive very fast. As it result of decade or more work flesging out the content pupeline and ed tools . So that branch off is so heavely modified that it time for it own branch name.
Also Procedural is old method it can be done lightweight but also very complex. In the old day with the demo scene they made content like coridor scene very detailed and worn out that it look very real.
For lot of thing there is no high complexity need. But full planet is something that is complex to generate such huge thing in fine detail.
Also 90% rule is more PG to assist artist and the artist refines it to deliverable state.
 

Cmdr Eagleboy

Cmdr Eagleboy
All these games are very different than anything SC or ED - Hellios promises MP but doesn't mention how it will do it. If servers...what kind of MP it is. It seems it is not persistent world. Detached is VR experience....and so on and so forth.

But yeah they seem to have more clarity what they want to do.
 

Toumal

Toumal
Ben Parry said:
. Besides that, halve the size of the scene and you halve the size of the precision errors, but you also halve the size of the things that have the errors, so you end up (from a player's perspective) with no change. Better to just find where the scene size was hardcoded and change it.
Click to expand...

That is not so. Reduce the scene scale by half and you run into all sorts of problems. Collision detection will get more and more wonky because of the reduced precision.

The reason is that if you reduce the scale of objects in your scene, you do lose precision.

If you want to halve the precision errors you have to double the scale of the scene.
(By that i mean making everything in the scene twice as big, which means the total room the scene portraits is halved)
 
Last edited:

ianw

I
Well CIG/RSI seem to have shown how they will handle the golfswingmeter radargate.

The thread has been nuked - not moved to concerns apparently - just nuked.

:D
 

ianw

I
Last edited:

Stigbob

Stigbob
ianw said:
Well CIG/RSI seem to have shown how they will handle the golfswingmeter radargate.

The thread has been nuked - not moved to concerns apparently - just nuked.

:D
Click to expand...

Can anyone remember who the OP for the purged thread was I want to check how many decades they've been banned for.

Press <<USE>> to eradicate doubters.
 

FuriousMeow

F
They whine about the scanners but don't care about the fact you can be in space in undies because the "golf swing" dar is arcade but not modelling atmosphere is super sim!
 
Last edited:

Cmdr Eagleboy

Cmdr Eagleboy
FuriousMeow said:
They whine about the scanners but don't care about the fact you can be in space in undies because the "golf swing" dar is arcade but not modelling atmosphere is super sim!
Click to expand...

You don't understand ;) - it is about *meaning*. Problem exists that more automated/involving gameplay process is, less happy some gamers are. I think this is more about positivity to fail something. QTE like mechanisms are mostly hard to make fail proof. People who game to achieve imagined top of skill scope find gameplay which is hard to fail shallow. Sometimes they don't see context though where collective gameplay cascades into actual fail state (ED penalty for shipping illict cargo is fine these days...which can convert to shoot on sight bounty if ignored. Same with dormant bounties).

Issue here is that SC is designed without sense of flow. What this scanning implies? What are failure states? What happens next? Reading that thread there's certain obsession with mechanisms despite having no overall idea how game should work together. Huge irony is that CR most likely share same sentiment, but won't be able to pull 'scrap this and rework' stunt anymore because it has turned fruitless.

And yeah, SC backers, welcome to reality.
 
Last edited:

frostypaw

frostypaw
Ben Parry said:
See above - floating point just doesn't work like that. The only gain you'd get from shrinking the scale of stuff would be if there were some hardcoded scene size limits that for some reason you couldn't change. Besides that, halve the size of the scene and you halve the size of the precision errors, but you also halve the size of the things that have the errors, so you end up (from a player's perspective) with no change. Better to just find where the scene size was hardcoded and change it.
Click to expand...
I think you're pretty much saying the same thing but as viewed from a programmer's side rather than the user/player's side, and I think you meant halve the size of scene and double the errors.

Going to use rubbish numbers/powers of ten for ease but e.g. if at a certain internal scale in 32bit you can achieve 1cm accuracy and when you go to 64 bit and get 1mm accuracy for the same size play area then changing the scales so 1mm=1cm in 64bit the user experiences the same level of precision as 32bit but gets a vasty larger play area working out just as you describe - acceptable accuracy over a much larger distance from origin.

Internally you're exactly right about what's going on, but to the layman it could be described as shrinking all the objects and not be entirely wrong - but still not a bad thing and a stupid thing to kick up a fuss about in many ways. I guess the big detractors are saying so because it's not really solving the problem just changing it's scale, but while space is THAT big and even 64bit won't cover a real solar system it almost certainly will cover any actual space battles/events that really require it to all be in one segment(? what's the right term) so it's probably plenty to work with.
 
Last edited:

Stigbob

Stigbob
If they get this upset about the radar being under par, how will they react the theoretically possible MVP in all it's woefully shoddy glory.
 

Cmdr Eagleboy

Cmdr Eagleboy
Btw that radar thing isn't THAT bad. I think dev made mistake describing it in QTE way. Too late as crowd is really on him and he won't be allowed to finish design properly.
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom