koobas.hobune.stream
"Minimum size on screen" for primitives
Hi all,
I'm rendering some basic spheres as stars, but particularly far away stars are too small to show up very well.
I want them to never appear smaller than a few pixels across, and instead just to fade out as they get further away.
I'm wondering if anyone can think of any clever tricks to avoid looping over every star each frame, because I currently have many thousands of stars.
I've considered using a single-particle particle system for each star when they're far enough away, a billboarded sprite, and just changing the scale of the mesh. None of these seem able to avoid looping over every star each frame.
By partitioning space and pre-calculating angular sizes, I've been able to determine which stars ought to be rendered at a "fixed screen size" without doing a loop over every star. But that still leaves me almost every star to loop over, to rescale so as to achieve a fixed screen size.
Can anyone think of any clever tricks to avoid doing this?
Thanks,
Winston
If once they are reach a distance, the star is forever small, then you could detect when they reach this threshold, replace them with a Quad (or not), and make the Quad a child of the ship. This doesn't fade them...just gives them a $$anonymous$$imum size.
Unfortunately as the ship moves around, the direction to a star needs to change, so simply adding as child of the ship won't work for that on its own. I was excited for a moment there! Thanks, though.
Again, assu$$anonymous$$g once a star is too far it never needs to transition back to it's active state, make the Quad a child of an empty game object that tracks the position but not the rotation of the ship.
I have to wonder if you are borrowing trouble. Are you sure a brute force approach of just sizing all the 'too far' objects has that much impact on your game? What is the target platform?
Depending on your needs, there are a number of ways to optimize what you are doing here. Some would involve significant code. The easiest is to recognize that object at that distance change size slowly, so you don't need to do the calculation every frame for these 'too far' objects. A couple times a second might be good enough, and you don't have to do the calculation for all the 'too far' objects at the same time.
The ship flies around in among these stars, so the angle between any given pair of stars will change as you move. As such, I don't think I pinning the quads to a sphere surrounding the ship will work without very regular updating.
Batching the star updates, and adjusting their re-calculation depending on distance (& lu$$anonymous$$osity) sounds like it'll probably be my best tactic.
For each volume of space, I've already pre-computed what stars could be close enough & large enough to be visible as more than just a point. It'd involve more memory use, but I could possibly even pre-compute what "nearby" stars might require more regular updates.
I get the feeling I'm diving into far too much premature optimisation at this point. I'll set up some performance monitoring to see how the different options stack up.
Thanks for the help, Winston
