Answer: “It’s going quite well. In fact, when everyone gets 1.1, they’ll be playing in the engine that is mostly in 64 bit. While players won’t really appreciate because it’ll still be old maps, and the final element that has not been moved across is the rendering side of stuff (which has to go to camera relative).
So the rendering and the 3d pipeline is still gonna be in 32 bit, mainly because the GPUs all run 32 bit, and there’s no real point to running 32 bit with rendering, because when you’re figuring what’s around you that you can see, that’s perfectly fine with the 32 bit range. What’s not fine is with a huge solar system that you’re gonna travel millions of miles across.
So we’ve essentially moved everything aside from the sound module in CryEngine and the rendering pipeline to 64 bit. Now, it will actually be in 1.1, so it’s part of our regressive testing.
So we’re in the middle now of doing the camera relative change, which is where you take the camera and its positions in 64 bit and any of the elements you’re rendering in their global 64 bit positions, and then you figure out the relative distance between them, and that turns into a 32 bit number and that goes through the rendering pipeline.
So that’s where we are in the process, and we’re almost done with it – so when you guys play 1.1, you’ll have most of the code running in 64 bit, for all the positions and matrices and such. But it’ll just be dealing with areas and ranges inside our current map range, which are designed to work well with the positions of 32 bit, even though you’ll be playing in 64 bit.
It is a required change for multicrew ships, mainly because we have large world plus the local grid physics stuff that demoed a little bit when we did Gamescom last year.
And we have the Zone System that we’re working on, which allows us to do a much better job of efficiently organizing and including and updating entities, objects, render elements, and such in a sparse area structure.
Typically, in most FPSes, they use something like an octree, which works really well for something like an FPS level, where there is a pretty constant density of objects which are all pretty high density. Because in an FPS level, you’re running around but not actually moving that fast, so there are objects everywhere – objects every single meter, so there are thousands or tens of thousands of objects.
But in Star Citizen, we have objects of high density, like a spaceship, which can have a lot of moving parts and people on board it, but then have a whole area of space with nothing in it (since space is mostly empty). And then you can get into a spaceship battle where ships are firing laser bolts at each other, and so that battle area will be really dense.
So an octree is really inefficient for that difference between a very sparse amount of data and a very dense amount of data. So we’ve been working on the Zone System, which is being led out of our German office, which is being staffed by a lot of engineers who built CryEngine. So we’ll have more to announce down the road, but we’ve got some legendary people – some of the best you can hire – working on this.
So one of the things we’re working on is finishing not only the large world, but the Zone System, which is what will allow us to be a lot more efficient about updating stuff. So it’ll make our rendering more efficient, it will allow us to occlude – ‘okay, here’s a big spaceship, I’m outside it, so I don’t need to render the interior zone, I don’t need to update the interior zone.’
So in terms of dealing with bigger space combats with big ships, like an Idris or a Bengal, and then smaller ships like fighters, and then people running around inside the ship and outside, the Zone System is really good at breaking those down into different areas of data density.
So that’s what we’re working on – again, with the Zone System, so in terms of flying between areas, you can have Earth and an orbit around Earth, and an orbit around the Moon. And then between them, there’s nothing. And as you enter a zone, the System might say, ‘Okay, let’s stream in the moon, and lets stream in the space station that’s around the moon, and let’s stream in the asteroids that are hanging out here, and lets stream in the spaceships that are hanging out here.’ And also, the space station around the moon could be another Zone inside. And so you’d stream that in, and it comes attached with more Zones inside. So it’s really good for updating and rendering and occlusion, and all that stuff.
So the Zone System and 64 bit and local grid are all things we really need to have the large ships work efficiently in a place where people can come and go and we can have lots of stuff happen. Because there’s a lot of people who are wondering, ‘How are you gonna manage to have these big spaceship battles.’ And it just requires a different approach on how we’re going to update and render and even communicate on the network.
Because the Zone System also would be used for figuring out how what level of network updates we’d use, what level of updates we’d use, what you see and don’t see. So all these things together, that’s all gonna be in multicrew ship combat, and that’s the foundational stuff for big space flying around over huge distances, going from planet to planet, and other stuff like that.
So that’s all in progress, and I think it’s gonna be pretty good. We’re seeing some really great performance gains in the Zone System way compared to the traditional octree system way. So there you go – probably more of a technical dump than you guys were expecting, but that’s it!”
flight model, you will be at a disadvantage. For example, I frequently use roll and pitch instead of yaw (although it isn't natural), and I also keep the throttle in the "blue zone" so that my strafe and orientational thrusters become more powerful (which doesn't make any sense from a physical standpoint).
