Best practices for a skydome with 92k unique stars with different sizes and colors

Hello! First of all, thank you for this engine. I have no background in computer graphics, I’ve only been using Babylon for approx 4 days and i’m already making some progress.

My question is, is it possible to have a consistent 60 fps while rendering 92k unique stars and objects, that also appear “round” (billboard)? So far me and my friend have been using a SpriteManager to accomplish this but it eats FPS when rendering all 92k stars.

Here’s what it looks like right now. nice and round, with a bit of bloom. Sprites are really good but once you get that 92k sprite mark, it starts to lag out. So is there an alternative with the same results, that is also efficient? We also want picking of individual stars to get info about them. Here’s what we want:

  1. Changeable colors
  2. Changeable size
  3. Possibly changeable material in the future (This is debatable and can be removed)
  4. Picking

To help with this issue even further, i’ve decided that we can hide stars that are not in the view frustum… but i don’t know how to do that with sprites :frowning:

TL;DR: How to optimize sprites so it doesn’t lag out at 92k sprites, or rather, is there an alternative?

Thanks again for such a great engine!


As you mentioned picking, I will totally recommend SPS:

I think that rotating 92K objects (billboard) each frame can be a lot for the SPS. Maybe if they are only quads … to be tested

Thanks for the replies! I’ll try to use SPS and will follow up here. And yeah, we need it to be a billboard… Maybe a 3D Object like an icosphere instead of a billboard is enough?

@nemesisalt I know this probably doesn’t match your use-case but here’s the approach I took to creating a celestial sphere of high-res twinkling stars using accurate star data:

There’s no performance issue because it’s one mesh and 2 small textures (one for star shape and another noise texture for twinkle effect).

This approach works if you’re at the centre of the sphere i.e. can never get close to a star. But if you need to travel to or zoom into a star you’d need a hybrid approach - maybe switch to a sphere as you’re approaching a star, then recalculate the celestial sphere mesh for the new position in space. This way you’d still only have one mesh for the stars and could easily handle 100k stars and wouldn’t require any billboarding.

I actually checked out your project while researching this project and i absolutely loved it. Question is, does it support picking? as we need to select stars based on it’s position and get info about them such as RA, Dec, Magnitude, spectral class, all that jazz.

It’s just a mesh so yes it supports picking. You’d just need to somehow lookup which triangle (star) was picked. I’d imagine it should be simple as the star data is indexed and triangle (star) creation follows the star data index…

My code is a bit messy. I’ve been meaning to clean it up and make an npm module of it.

That actually sounds like a really good idea! I’ll implement it, and if all fails i’ll just look into your code once it’s released. Thank you.

And thanks to everyone who participated in the question!

Looks like PickingInfo.faceId would provide star index :slight_smile: I should try to add that.

My messy code is already on github here :innocent:

Neat project!

I’ve been experimenting with a similar project (not on github yet). I got the full Hyg 119k star database loaded fine in real-time flythrough 3D using the SpriteManager, with good picking, without having to drop into setting up vertex data directly.

I used the Gaia galaxy image, rather than ESO, since it doesn’t show the brightest stars as points (so I didn’t have to blur the galaxy image) - ESA Science & Technology - Gaia's sky in colour – equirectangular projection.

Currently researching whether there is a way to update all those sprites quickly in a scene.registerBeforeRender(). You can do that for a Point Cloud, and the reason for access is to adjust the drawing of very distant sprites so they fade out and blur - instead of just going to 1 pixel at current brightness. If you move in 3D, the cloud of very distant stars twinkles in a way you don’t want as they crawl across the device pixels, flickering on and off.

Anything but quads and SPS is reduced in performance, relative to sprites, at 90k.