Best way to draw 300.000 stars?

[Sheepolution]

I'm making a space game, and I have a lot of stars.



Now of course I don't need to draw all 300.000 of them all at once, thought that's currently what I'm doing.
I was amazed by how my game still ran smoothly, but when testing it on my laptop it was really slow.

What I'm currently doing is creating a mesh with love.graphics.newMesh(t, "points", "static"), and simply drawing it.
For a better performance my idea was to separate the stars in boxes and only draw the stars in the boxes near you. But I'd like to know if you guys have better ideas?

[bobbyjones]

If you just draw what is on screen it might help speed things up. But I think meshes are already pretty fast. Are you sure that is the slowest portion of your code? I've actually tested drawing about 300,000 1 pixel images with spritebatches once (basically meshes) and was able to maintain 60fps without a dedicated gpu.

I'm not saying you should just draw all 300,000 but if you are having performance issues maybe it's something else. I think limiting it to only drawing stars near player might slow things down if done wrong. Like for example if you iterate over all 300,000 to see what is close to the player it may take longer to check than it is to just render them, unless you use quadtrees or another structure that allows you to get close stars relatively quickly.

So if you broke up all the stars into a grid(not a quadtree but a quad tree might be better). Now that you have the stars broken into a grid you can just render the stars in the grids on screen. So if you have a 10 by 10 grid of stars and only 2 x 4 is on screen then just render those stars. When you go to render the stars initialize an empty mesh with the correct number of vertices and add each table of stars to the mesh by using mesh:setVertices setting the index to that last index of the previous set of stars added. This would keep everything with 1 draw call with out having to iterate through a couple thousand stars. Which should speed things up.

I would like to see your results if this does improve performance but I would also like to say I have not done this before and that I know nothing of what I talk about lol

[MadByte]

I would try to create three parallax layers (big stars, medium stars, small stars) and then use three seperate canvases to draw them to the screen.

Example:

Stars Background.love

(its written in 10 min so no parallax scrolling yet :/)

The example has three canvases each with 10.000 points and a layer size of 4096x4096.
Performance isn't affected at all - at least for me.

[bobbyjones]

I think a canvas of 4096x4096 won't work everywhere

[MadByte]

I think a canvas of 4096x4096 won't work everywhere

That may be true.

[slime]

Instead of using a Canvas, you could still use a Mesh (or a SpriteBatch if you make your stars images), and update it every frame to only contain the stars that are actually on-screen at the positions they're supposed to be.

If the stars are mostly just for visual effect, you could have them repeat endlessly by just moving the spritebatch/mesh (and drawing the same batch again at a different offset as the stars scroll in) – zooming out would still be possible that way, you'd just draw the batch enough times that it fills the screen (you'll probably need a different batch for each layer though).

[MachineCode]

A skybox would be the way to do it in a 3D engine - and I am pretty sure that all modern graphics cards support the quadcube texture.

Is it possible using a LÖVE shader to effectively impliment a skybox? I have not yet explored the shader possibilites yet, but I am sure someone knows if this is possible.

I started writing a 2D type of skybox that uses a mesh of 4x4 divisions of the sides of a quadcube and a simple z buffer to cull out the non drawables, but its a big job and I started to think it would be better to work out what can be done with shader code.

[bobbyjones]

love3d can do 3d stuff. I'm assuming a skybox is just 5 textured planes or meshes or whatever. Use love3d if you need depth testing, z-ordering and stuff.