I’m trying to draw a parallax starfield in the background. I want it to be able to scroll in any direction though, so I figure using sprites is the best approach. I’ve seen some clever implementations in 2d where you break the world into a grid of chunks, hash the chunks, and use a few bits from the resulting hash to determine the position of stars in those chunks, then do the same thing at different scales to create parallax. In order for this to work in 3d, though, you’d need a way to figure out which grid chunks are visible (ie when sprites need to appear/disappear) - would determining if an arbitrary square out in space is in the view of the camera be easy or hard, I wonder? Another issue is sprite pooling - would that make it much more efficient?
This just seems like a solved problem in so many games (are there ever a lot of space games with starfields!) I figured I’d see if anyone had any insight.
Depending on you target (desktop, mobile,…) you can try making a 2D shader. There are some good examples on shadertoy.com.
Like this one : Shader - Shadertoy BETA
The implementation starting line 128 is simple and can be tweaked to your needs. It might not run well on mobile as in that example, the iteration count per pixel corresponds to the total number of visible stars. The more stars, the slower.
The good part is you only need 1 quad on the screen with almost no JS.
Also, sort of a general question about shaders, but can you, like, pass data to them? The example seems to scroll around randomly, but would it be possible to parameterize it so that other stuff in-game can control where it scrolls to?
And the way I did the nebula and galaxy and starfield …
was to take some CC0 images from Hubble, and spark.png, give them transparency in GIMP, stack em 10 deep on the z-index (billboard) looking at camera and then alpha blend with ONEONE. It gave a nice parallax effect.
Although, if you were able to mix all three… maybe you get something even nicer.
Regarding the particle system approach, wouldn’t that be inefficient for a moving background because you’d leave a trail of off-camera particles behind you as you moved around the scene?
Thanks for the help all! I’ve got a sweet shader off of shadertoy being drawn on a plane attached to the camera. Next thing to figure out is how to communicate the position to the shader (I thought cameraPosition would do it, but it seems to stay at 0,0,0 all of the time) so that I can make the stars scroll around. Also, I wonder if there is a way to communicate data from JS to the shader to, for example, stretch out the stars for a warp drive effect (ie pass in the “stretch amount” or some such.)
After determining that learning the discipline of shader authoring would be a whole thing, I wrote a naive implementation with sprites. It was easy to implement a little FTL effect too.
Problem now is, as you can see, when I dispose the sprites and sprite managers and instantiate new ones, they don’t show up. Seeing a similar problem with particle effects. Still need to track that one down (I might make a different thread for that though.)
: )