The Star Citizen Thread v5

Status
Thread Closed: Not open for further replies.

Stormprooter

Stormprooter
Viajero said:
*Mod hat off



You must be able to read the matrix!
Click to expand...

You are not the first to say that :)
But I must burst the bubble, it's all really simple - any problem can be simplified (well almost - there are exceptions, mostly to do with other people), you just need to find the right way to think about it (there is no spoon :D)
 
Last edited:

Tippis

Tippis
Yay!
I'm e-famous!

Also, I'm apparently so angry with SC that I travelled back in time 7 years to register an SA account to be prepared to really start hating on it a year after it didn't come out, but before that, a year later, I bought Elite and became a fanatic by having ignored it for 3 years.

Now, I've actually read Dr. Streetmentioner's handbok on tense formations, but I don't even think there's any verb form in there to describe that kind of sequence of events. Maybe it's in one of the blank pages. :D
 
Last edited:

Zieman

Zieman
dsmart said:
Yeah, check out his feed (assuming I haven't had his account chewed by Twitter support yet)

In other news (this one is equally as hilarious as the first :D

https://www.reddit.com/r/starcitizen/comments/5fe69h/heresy_and_the_fan_boy/

"REACH DEEP AND DONATE UNTIL IT HURTS! PRAISE THE SPACE LORDS!! YOUR PLEDGE WILL BLESS YOU WITH A NEW SPACESHIP"
Click to expand...

Tippis said:
Yay!
I'm e-famous!

Also, I'm apparently so angry with SC that I travelled back in time 7 years to register an SA account to be prepared to really start hating on it a year after it didn't come out, but before that, a year later, I bought Elite and became a fanatic by having ignored it for 3 years.

Now, I've actually read Dr. Streetmentioner's handbok on tense formations, but I don't even think there's any description in there to describe that kind of sequence of events. Maybe it's in one of the blank pages. :D
Click to expand...
Either some CR fans are really in need of medical intervention, or you've just been hit by internet trolls. :eek: :)
 

Ben Parry

Ben Parry
dsmart said:
1) 64-Bit sized scenes: how big you can make a scene which has extents within the −(263) to 263 − 1 range

2) 64-Bit programs: memory address space related; 32-Bit vs 64-Bit integer types, program, OS, CPU math op performance benefits etc

3) 64-Bit world positioning: a position (x,y,z) within a scene (1)

My comment that backers have no clue what the differences are between the three, still stands as it was originally written. It is irrelevant and immaterial if (1) and (3) are the same (by definition, they are not). That isn't, and never was, the argument that I was making.


FYI:

i) Star Citizen backers theory-crafting about 64-Bit world because, as I said, they have no understanding as to what it means. July 2015

ii) Star Citizen backers theory-crafting Star Citizen's 64-Bit engine. Nov 2015

iii) Tweet I made about this same thing. Dec 2015. Bonus: If you type "64-bit world positioning" right now in Google, that Tweet is the 2nd of "About 6,910,000 results".

iv) Interview with Sean Tracy about 64-Bit Engine Tech & Procedural Edge Blending Sept 2016. Bonus: "One of the big, fundamental changes was the support for 64-bit positioning. What a lot of people maybe misunderstand is that it wasn't an entire conversion for the whole engine [to 64-bit]. The engine is split up between very independent and – not as much as they should be, but – isolated modules. They do talk to each other, but things like physics, render, AI – what are the purposes of changing AI to 64-bit? Well, all the positioning that it will use will be 64-bit, but the AI module itself doesn't care. There were a lot of changes to support these large world coordinates. […] The actual maximum is 18 zeroes that we can support, in terms of space."
Click to expand...

1) Ok, you got me there, "64-bit sized scenes" is a meaninglessly vague term in isolation, it doesn't specify units or format, or even that it's a number. I assumed you were of the belief that some specific meaning of (1) was what had been done, because...
2) You clearly didn't think number 2 was relevant, and I agree. My post history here will show how many times I had to tell Elite fans that, no, you don't need a 64-bit exe to get 64-bit numbers.
3) Number three is the thing that actually was done (though I'm cautious of the word "scene", as you sometimes use it as a technical term), and is the thing that you seem to keep saying was not done.

i) Star citizen backer theory-crafting about that, two highly-upvoted responses correcting them.
ii) I scroll down and find someone quoting, uh, me, of all people, to correct them. Tier 1 obfuscation. The thread ends with a knowledgeable fan explaining things in a totally sensible way.
iii) A true post, but since SC has both of those things, it's not exactly a harmful or misleading misunderstanding. A burger isn't spicy rice, but I'm having both for dinner.
iv) Sean is an artist, and he occasionally gets things wrong. That said, he's on the money except for the 18 zeroes (assuming he means metres), when I did the rough numbers it came out more like 10 AU IIRC (it's in this thread somewhere). I'm not sure why you highlighted the other stuff, is it an example of him misleading? Evidence for some other vital point? Admittedly, the article then runs off with stuff about 64-bit architectures and we're back to iii.

Noctrach said:
I guess what I'm trying to say is that I don't see how any of these things falsify the fact that they're using 64-bit floating points for positioning.
Click to expand...
dsmart said:
I never made those claims. Do try to keep up. Or at least, cite sources like I tend to do, so we can debate them based on merits.
Click to expand...
I imagine when one writes as many missives as you, it gets hard to keep track of what you did or didn't claim. I'm here to help: "As I tweeted this morning, this is done by going the (32-bit * 2) route, whereby you use a 32-Bit positional reference for that fixed object, then treat the player position as a 32-Bit value by using that fixed object as a reference." You obviously disagree with it too - "It's messy. It's rudimentary. OMG! And it can/will break everything."
You wrote basically a whole essay about how the large-world conversion isn't really 64-bit, and I'm sure I remember something from some other point about this resulting in large ships not fitting inside an 8km map?
Added bonus further down, you refer to the position conversion as "64-bit addressing", which is exactly the kind of muddy phrasing that keeps the 64-bit exe vs 64-bit float misunderstanding alive ;)

Adept said:
Isn't the maximum map size an effect from the 32-bit float meaning that precision gets lower and lower as you go futher out to the edges of the map? Hence the size of the box is the mapsize you can define with acceptable positional precision?
Click to expand...
Stormprooter said:
As I understand the floating point data type, that would make sense. It's a case of scale vs precision (or mantissa and exponent). I'm not an expert on game engine stuff though, and it seems there are further complications/restrictions/benefits which are graphics hardware based - which is beyond my current knowledge. I'm a database guy, I understand data and how to model it. To me, it's all 1's and 0's :D
Click to expand...
Absolutely correct. Default CryEngine's 8km is an arbitrary map size limit, you'd be just as functional just outside the boundary, but ~4km from the origin is definitely the place where things start to go weird and I expect that's why they picked the cutoff.
 
Last edited:

Cmdr Eagleboy

Cmdr Eagleboy
Last edited:

Zieman

Zieman
Ben Parry said:
Absolutely correct. Default CryEngine's 8km is an arbitrary map size limit, you'd be just as functional just outside the boundary, but ~4km from the origin is definitely the place where things start to go weird and I expect that's why they picked the cutoff.
Click to expand...
Why is that?
Shouldn't the coordinates be just as precice, no matter where you are on the map?
Or are object positions & movement handled as quaternions or some other vector maths that use distance from origin and angle(s) from plane(s) as the basic components, instead of raw coordinates, so the precision deteoriates with increasing distance from origin?
 

VidarSnipes

V
Zieman said:
Why is that?
Shouldn't the coordinates be just as precice, no matter where you are on the map?
Or are object positions & movement handled as quaternions or some other vector maths that use distance from origin and angle(s) from plane(s) as the basic components, instead of raw coordinates, so the precision deteoriates with increasing distance from origin?
Click to expand...

Aren't coordinates usually represented in floating point? As far as I know those lose their precision the higher their value.
 
Last edited:

Ben Parry

Ben Parry
Zieman said:
Why is that?
Shouldn't the coordinates be just as precice, no matter where you are on the map?
Or are object positions & movement handled as quaternions or some other vector maths that use distance from origin and angle(s) from plane(s) as the basic components, instead of raw coordinates, so the precision deteoriates with increasing distance from origin?
Click to expand...
Fixed-point coordinates would have the same precision everywhere. Float has more precision the closer you get to zero which, as Stormprooter mentioned earler, isn't as good. You have to design for your worst case, which means you're effectively only using 25-bit precision (24-bit mantissa and the sign bit). Similarly, double precision only gives you 54 bits that you can really safely use. 8km * 229 (254 divided by 225) is just under 29 AU, so that's roughly what I'd expect the safe diameter of a Star Citizen solar system to be.

Edit: sniped, by Snipes
 
Last edited:

Tippis

Tippis
Zieman said:
Why is that?
Shouldn't the coordinates be just as precice, no matter where you are on the map?
Or are object positions & movement handled as quaternions or some other vector maths that use distance from origin and angle(s) from plane(s) as the basic components, instead of raw coordinates, so the precision deteoriates with increasing distance from origin?
Click to expand...

It's a direct result of how floats work.

Floats are constructed by having a set of significant digits (the ‘significand’) that are scaled using an exponent. The significand has a fixed amount of precision that it can offer, and the exponent just moves it up and down various orders of magnitude.

To use a simple, non-binary example:

You have a four-digit significand (eg. 1234) and a one-digit exponent (eg. -1) that uses the base 10. If you combine these examples, you get the number 1234×10⁻¹=123.4. If we increase the significand by 1, we increase the final number by 0.1: 1235×10⁻¹= 123.5. We can use this simple set-up to signify pretty large numbers and pretty small ones — anything from 0001 × 10⁻⁹ (0.000 000 001) to 9999×10⁹ (9,999,000,000,000), but note that we only ever have those four significant digits — that is the limit of our precision. Consequently, the smallest amount of change we can introduce or measure at any time depends on the exponent.

At one extreme ±1 on the significand means a change of ±0.000000001; at the other extreme, the exact same ±1 on the significand equates to a change of ±1,000,000,000(!). In other words, the higher the (absolute) value of a number gets, the less precise it gets; the closer it is to zero, the more precise it gets.

32 and 64 bit (single and double precision) floats work the same, only they don't use base 10. The main difference between them is how many bits are dedicated to that significand, i.e. how many significant digits it can have. Single-precision offers the equivalent of ~7 significant digits when translated to a decimal number; double-precision offers almost 16.

Now imagine that you'll want millimetre precision in your game to reduce most of the jitter you'd see. This means that of your 7 significant digits, you can never let more than 4 of them represent full metres — the remaining three are your decimals that measure something at a millimetre precision level. (Eg. you have the significand 1234567, and you want to measure millimetres, the highest you can scale that number to is 1,234m + 567mm.) So you won't get more than a couple of km at most out of that float before you have to abandon your minimum precision. With a 64 bit number, you suddenly get 9 more significant digits — a billion times higher — and you can now maintain that precision out to terameters).
 
Last edited:

Zieman

Zieman
Thanks for the clarifications, +rep to each of you. :)

So, the 32bit / 64bit precision problem is unavoidable, because of the way our computers do maths (skimmed through the Wikipedia article about floating point numbers too).
 

frostypaw

frostypaw
Ben Parry said:
Absolutely correct. Default CryEngine's 8km is an arbitrary map size limit, you'd be just as functional just outside the boundary, but ~4km from the origin is definitely the place where things start to go weird and I expect that's why they picked the cutoff.
Click to expand...

Gotta be arguable that's far from arbitary - unless perhaps it's the new Psychnaut's dream sequences you're going for and weird's where you start.

There were stories from NMS of people trying to fly to the sun and hitting the accuracy limits - some very very strange videos and posts from confused people
 

Ben Parry

Ben Parry
frostypaw said:
Gotta be arguable that's far from arbitary - unless perhaps it's the new Psychnaut's dream sequences you're going for and weird's where you start.

There were stories from NMS of people trying to fly to the sun and hitting the accuracy limits - some very very strange videos and posts from confused people
Click to expand...
All I mean by that is, 8.5km would probably be only moderately more jittery, and 7.5km would be moderately less jittery.
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom