dgavedissian
commented
5 months ago @HaronK All of those are for calculating the initial placement of planets and things, where losing precision doesn't matter that much. I do plan to adjust those slightly in the next PR, for example:
planet:setPos(rng:getDir3():scale(Config.gen.scaleSystem * (1.0 + rng:getExp())):toPosition())will become
planet:setPos(rng:getDir3():toPosition():scale(Config.gen.scaleSystem * (1.0 + rng:getExp())))Eventually, we probably want to rewrite these to be positioned at an orbital distance from the host star.
TLDR is that all spatial positions in the engine use the new
Positiontype (which is a double vector). Then, the renderer, audio and physics modules are adapted to use the new Position types.Note that this is only part 1, this doesn't actually solve large world support YET. This simply introduces the new Position type and wired it up in all the places I could think of.
Renderer will render everything relative to the camera. That means that when we compute the model-view-projection matrix, the model matrix uses the f32 offset as its translation component, and the view matrix has (0,0,0) as its translation component. Any positions passed to shaders as uniforms also need to be translated in a similar fashion. For now, we just treat "(0,0,0)" as the camera position before we wire things up.
Physics already is based on f64 positions, so we just need to convert them.
Audio uses a "floating origin" setup, where we recompute the position of all emitters and listeners when the camera moves far enough away from the last updated origin.