The Star Citizen Thread v5

Status
Thread Closed: Not open for further replies.
All I mean by that is, 8.5km would probably be only moderately more jittery, and 7.5km would be moderately less jittery.

Ya I understand that - but the tolerance must end up being pretty well defined in terms of what can be seen and that's probably down to a number of factors in how it's rendered and the game experienced.

I'm not trying to say anything that really matters here i guess just the difference between i can jump down from an arbitary height and the reality of it's gonna more than hurt after a point.
 
Ya I understand that - but the tolerance must end up being pretty well defined in terms of what can be seen and that's probably down to a number of factors in how it's rendered and the game experienced.

I'm not trying to say anything that really matters here i guess just the difference between i can jump down from an arbitary height and the reality of it's gonna more than hurt after a point.
Fair comment :D
 

dsmart

Banned
This is going to be a mess to quote, so I'm going to block quote and just highlight what I'm referring to

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.

* It's not "meaningless" at all. It's either a big box or a small box. That's why you have either 32-Bit or 64-Bit.

** It wasn't about "relevance". It was specifically about my comment echoed here and again quoted: "That's just the same nonsense that's going on whereby - for some reason - backers who are adept at theory-crafting dreams, can't tell the difference between 64-Bit sized scenes, 64-Bit programs, 64-Bit world positioning.."

So my missive was about pointing out that there ARE differences between those THREE entities. And so I described what EACH means, and WHY they are DIFFERENT.

*** Again, the missive wasn't about what was done vs what wasn't. Read the above again.

Let me touch on this again. You guys claimed (at the time) that it (64-Bit positioning) was done. My claims about what I believe was done, is well documented. And I quote:

Regardless of whether or not they use 32-Bit or 64-Bit world positioning, they can’t exceed the max map size of the engine without super-extensive modifications. And even if they did that, they still have one massive problem: the physics engine

I don’t believe that they’ve done this. It would be absolutely insane and time consuming to do that. Plus, for a space combat game, it would have no benefit. Elite Dangerous did it because right off the bat, they built a game engine from the ground up to do just that.

What I believe they’ve done is what Chris has been hinting at and which most people (if you’re not a tech) keep missing. They’ve zoned it. As in shards it. Because that’s the easiest way to do it in any engine, especially CE3 without hassle. You still need 64-Bit positioning because you still need to calculate that accurately in a game whereby you want to keep everything in sync and accurate.

And as I mentioned above, Sean Tracy (which I even quoted) went on the interview and basically confirmed what I said above. That being i) you guys couldn't possibly have done a full 64-Bit conversion of the engine ii) only parts of the engine were converted, leaving other parts such as physics (which I cited as an example above), AI and other bits and pieces.

**** That's just crazy. Are you telling me that, you a graphics programmer, don't know that "scene" is another word for "map" or "level" - even "world"? And you don't think it's a contextual technical term? Are you trolling me right now?

***** I quoted Sean to highlight his statement which goes toward him also attempting (almost a year after my own missive from Nov 2015) to clarify the differences and the misunderstanding (by backers) that my entire missive is based on. I didn't make any note of the number of zeroes in the statement because it wasn't relevant (regardless of whether or not it was accurate, it's down to what precision they chose)

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 ;)

You're going around in circles again, while saying nothing of any importance.

1st: that Twitlonger of Nov 20th, 2015, was the impetus for the previously cited Nov 22nd 2015 article.

2nd: my missive has nothing to do with what you stated above. My "essay" was quite clear, and without any obfuscation whatsoever. You should probably read it again, then ask me specific questions based on quoted portions. It will make it a lot easier.
 
Last edited:
Many things
Rather than going point by point on that post, I'll simplify: all that stuff you said about breaking stuff into bits isn't being done.
You seem to be utterly fixated on this idea of fixed-size scenes, as if they're a universal constant that has to be built around - basically the only way you can imagine doing it is the sloppiest and least-granular way available.
The stuff you quoted from Sean, shockingly, you misinterpreted - he means the thing I said upthread, that things like the renderer know how much precision they need, and can drop to that precision for efficiency. I've not worked inside the physics, but physics solvers tend to work on "islands" of currently-touching bodies, so I'd assume they just solve each island relative to its centre in 32, and put the results back out at 64. Character animation would be another obvious example of stuff that can do the bulk of its calculations in single precision.
I won't ask any questions because I don't need to - the only thing you got right in there was that we'd need logarithmic Z (assuming you meant the log distribution you get from inverse Z), though given it was already done, you misdiagnosed whatever bugs you were referring to.
 
Last edited:
Rather than going point by point on that "missive" you linked, all that stuff you said about breaking stuff into bits isn't being done.
The stuff you quoted from Sean, shockingly, you misinterpreted - he means the thing I said upthread, that things like the renderer know how much precision they need, and can drop to that precision for efficiency. I've not worked inside the physics, but physics solvers tend to work on "islands" of currently-touching bodies, so I'd assume they just solve each island relative to its centre in 32, and put the results back out at 64. Character animation would be another obvious example of stuff that can do the bulk of its calculations in single precision.
You seem to be utterly fixated on this idea of fixed-size scenes, as if they're a universal constant that has to be built around - basically the only way you can imagine doing it is the sloppiest and least-granular way available.
I won't ask any questions because I don't need to - the only thing you got right in there was that we'd need logarithmic Z (assuming you meant the log distribution you get from inverse Z), though given it was already done, you misdiagnosed whatever bugs it was that you saw.

+1

Seems like a clear case of recurring Gamedevdinossauritis :D
 

dsmart

Banned
Rather than going point by point on that post, I'll simplify: all that stuff you said about breaking stuff into bits isn't being done.

Alrighty then.

You seem to be utterly fixated on this idea of fixed-size scenes, as if they're a universal constant that has to be built around - basically the only way you can imagine doing it is the sloppiest and least-granular way available.

Wrong. Also, I'm glad that you brought up the "the sloppiest and least-granular way available" point, because that's pretty much the gist of what I wrote a year ago. heh.

The stuff you quoted from Sean, shockingly, you misinterpreted - he means the thing I said upthread, that things like the renderer know how much precision they need, and can drop to that precision for efficiency. I've not worked inside the physics, but physics solvers tend to work on "islands" of currently-touching bodies, so I'd assume they just solve each island relative to its centre in 32, and put the results back out at 64. Character animation would be another obvious example of stuff that can do the bulk of its calculations in single precision.

Nope. I didn't "misinterpret" anything. I quoted what he stated verbatim. I think what you meant to say is that I misunderstood what he meant. And you'd still be wrong, because his statements were pretty clear.

I won't ask any questions because I don't need to - the only thing you got right in there was that we'd need logarithmic Z (assuming you meant the log distribution you get from inverse Z), though given it was already done, you misdiagnosed whatever bugs you were referring to.

Wrong. My point was to outline the differences between three things. I did so. And by all accounts it was clear and accurate in all three cases. But if you're still going on about the "fake" 64-Bit positioning thing, you're on your own.
 
Last edited:
So is it 2.6 delayed or it´s coming out on 8 december?

Chuckle.

Of course, RSI (or CIG - which one is making the game?) have played a rather cunning "plausible deniability" card with publication of an excerpt from their internal aspirations. It keeps the credulous/worshipful/true believers hoping for a release this year, while allowing CIG (or RSI) to deny that they made any such commitment. Talk about having your cake and eating it!
 
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).

What I've learned here is that graphics GPUs use floating point maths as well, for all sorts of things, so sticking with floating point seems to simplify things all round. To my understanding it's a balance and trade-off thing often found in all areas of software development.
It is possible that someone could create graphics hardware and a game engine using large fixed-point numbers, which would give both large scale and precision, and no "glitchy-ness" at the boundaires - but I suspect there's not much commercial incentive to do so at the moment (the asset tool-chain - AutoCAD/3D Studio and others probably work on floating point too - but I suspect you could export/transform to fixed point ) - maybe that's something that could appear in the next 5-10 years - unless a cleaner, slicker way of doing things is developed.
 
Last edited:
3.0 is still coming for the end of the year though, right?

I mean, it's not on the schedule but that just means they want to surprise us!

Maybe I need to write a letter to Santa Claus...
 
Last edited:
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

Look but keep walking- they're not worthy...
 
Wrong. My point was to outline the differences between three things. I did so. And by all accounts it was clear and accurate in all three cases. But if you're still going on about the "fake" 64-Bit positioning thing, you're on your own.
This is... a little disingenuous of you, I have to say.
Firstly, because the examples you linked were mostly fans getting the right answer via the wrong means, or getting it wrong and being immediately corrected several fans who were right.
Secondly, we started out, not with your Three Meanings, but with a link to your forum, and you ridiculing a guy for thinking 64-bit would give him the ability to travel around a big seamless world. Then you insisted that the QD tunnels were a necessary way to transition between "scenes", and linked to that big post about drawing Xs in boxes and large ships not fitting into 8km maps.
Now I'll concede that you didn't, recently, say the game isn't using double precision, but you did keep talking about the same imaginary limitations you were talking about when you thought it didn't. Mea culpa.
 
Dis isn't a war. It's a moider.
\​
225px-Ihawk2.png
 
Last edited:
Status
Thread Closed: Not open for further replies.
Back
Top Bottom