Nav Rendering

Hey Folks! Still looking into an alternate nav console rendering technique, and it's starting to come together. What's more, it also seems easier to manipulate. So far, anyway.

Today's screenshot shows a few scenes from the new nav renderer, which uses sprites to render planet/moon blips, and vector lines to draw their orbits. The main reason for this investigation is because the old plotter was both a bit of a performance hog, and also a bit hard to work with. And if we're going to be throwing a lot more on-screen items at it, such as in a debris field, junkyard, or asteroid field, that seems like it'll just get worse.

So far, so good. It's accurately rendering planet and satellite positions, and their orbital tracks. It can color-code them (currently based on mass). They can use custom materials, for effects like additive rendering. Sprites can be whatever makes the most sense for celestial bodies, stations, ships, etc. And I can mix and match canvas vs. game objects, with occlusion, as seen in the right side of the screenshot.

Most importantly, it's fast. 70fps so far, regardless of zoom. And easy to use. I just feed it the real-world positions of things in AU, and it spits them out on the canvas or world space coordinates as needed.

A stress test might be the next order of business, to see just how many objects I can throw at the system without slowdown. I have a feeling the simulation will tank before the renderer, as it tracks more and more physical positions updating constantly. And I might need to reduce sampling rates.

Similarly, I still need to work on jitter at close range. I can get pretty close using this method, but I'll likely want to swap out the sprite pip for actual-size scaled vector circles once we're close enough to see diameter.

Worst case scenario, I can maybe use this for just the local space nav renderer, and swap between the old course plotter and this as needed.

Tags: Ostranauts