Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Farmerbob]

  The star patterns still seem striated and more regular than they should.

  I have absolutely no idea how you are building your star field, but I'm guessing that you are using both area and point data instead of just point data.

  Maybe use the same algorithm you use for the cloud shaping to generate several overlays of star density?


  Basically create a field of random position & random brightness stars within a shape defined by the gas cloud creation algorithm. Then do it again.  And again.  keep track of how many "stars" total are created.  Once you get to an overall number of stars that you want, stop generating more, and go to gas cloud creation?

  This should create random starfields with random pockets of dense and sparse stars.

[Draco18s]

Basically create a field of random position & random brightness stars within a shape defined by the gas cloud creation algorithm. Then do it again.  And again.  keep track of how many "stars" total are created.  Once you get to an overall number of stars that you want, stop generating more, and go to gas cloud creation?

Do you mean creating the fields shape/size the way I do the cloud's overall shape?  I don't think that will work, as it's very unpredictable.

It works like this:

Draw perlin noise (at a scale of 1).  Threshhold it (so that 50% gray and up is one color, and everything else is another).  Then pick a random pixel and use it as the target of a bucket fill (floodfill).

Inside that bucket filled region is where the cloud goes.  The size of this region is unpredictable, due to the way the perlin noise works when you threshold it.  Here's an example:



There are 3 possible regions that could be filled in.  #1 is very large, taking up half the space, and borders 3 edges (requiring that the same perlin noise be used for neighboring regions).  #2 is middle-sized and touches 2 edges, also requiring the same seed to be used for neighboring regions.  #3 is the smallest, and touches 1 side, also requiring the same seed for neighboring regions.

It's possible for areas to be disconnected from the edges, but they're rather rare.  It's also possible for them to be really tiny.  And denser noise isn't any better.

[Farmerbob]

Basically create a field of random position & random brightness stars within a shape defined by the gas cloud creation algorithm. Then do it again.  And again.  keep track of how many "stars" total are created.  Once you get to an overall number of stars that you want, stop generating more, and go to gas cloud creation?

Do you mean creating the fields shape/size the way I do the cloud's overall shape?  I don't think that will work, as it's very unpredictable.

It works like this:

Draw perlin noise (at a scale of 1).  Threshhold it (so that 50% gray and up is one color, and everything else is another).  Then pick a random pixel and use it as the target of a bucket fill (floodfill).

Inside that bucket filled region is where the cloud goes.  The size of this region is unpredictable, due to the way the perlin noise works when you threshold it.  Here's an example:

There are 3 possible regions that could be filled in.  #1 is very large, taking up half the space, and borders 3 edges (requiring that the same perlin noise be used for neighboring regions).  #2 is middle-sized and touches 2 edges, also requiring the same seed to be used for neighboring regions.  #3 is the smallest, and touches 1 side, also requiring the same seed for neighboring regions.

It's possible for areas to be disconnected from the edges, but they're rather rare.  It's also possible for them to be really tiny.  And denser noise isn't any better.

Ah, I thought that you had devised an algorithm to make your gas clouds random across the screen.  Any mechanism that can be used to define a significant volume of screenspace randomly would be what I would use for defining starfield layers.

Since you will be building the layers into a tapestry, it might be possible to monitor fill levels in regions of space and limit the fill rate in dense areas of starfield?

[Draco18s]

Ah, I thought that you had devised an algorithm to make your gas clouds random across the screen.

Technically, I did.  It just doesn't work well for other applications.

[Virex]

Hmm, you could use a "hailstorm" algorithm to get roughly the same effect. You'd generate perlin noise (possibly raise the values to a power to bias the generator a bit towards or away from clumping) which we'll call the density function for the stars, and start with x = the amount of stars. Then you loop up from 0 to x and each iteration you pick a random location and a random number between 0 and 1. If the number is lower then the local value of the density function, you put a star there and go on to the next star. If the value is higher than or equal to the density function you chose another random location. That way you distribute the stars according to the perlin noise function, but do note that if you have a very "lean" density function with a lot of low values, this may take a while to complete.


Another option is to again use a perlin-noise based density function, but instead of shooting randomly, you loop across all possible star locations (could use a grid with grid spacing of 10 pixels for example. Would need to tweak this) and generate a random number for each location. If that number is lower then the density value you place a star there and if it's equal or higher you don't place a star there. This method doesn't suffer from the halting problem, but if you want significantly less stars then there are raster sites it'll be less efficient then the first and it may be more difficult to balance the density function. Also you don't have control over the amount of stars. You may also want to add a random offset to each star generated to avoid getting noticeable grid patterns.

[Farmerbob]

Ah, I thought that you had devised an algorithm to make your gas clouds random across the screen.

Technically, I did.  It just doesn't work well for other applications.

I'm somewhat confused - but I'm also not a programmer.  I've done some programming waay back in the days of Pascal and Fortran and Basic, and was pretty good at it.  How are you defining the volumes for activity of one sort, that can't be used for other uses?

Multiple overlays of sparse random volume starfields will yield some fairly dense starfields and some sparse fields.  Also some completely dark spaces.  Any overlapping pixels could make stars brighter.  Pixels touching each other would enhance the brightness of stars and the newer layer's star would be absorbed into the pixel it touches.  Star count would be tracked and additional layers might be created if a lot of overlap occurs.

[Draco18s]

I'm somewhat confused - but I'm also not a programmer.  I've done some programming waay back in the days of Pascal and Fortran and Basic, and was pretty good at it.  How are you defining the volumes for activity of one sort, that can't be used for other uses?

The volume I'm defining for the clouds doesn't extend in the right way to other kinds of volumes.  For clusters of stars I want clustering not a single blob.

[Farmerbob]

I'm somewhat confused - but I'm also not a programmer.  I've done some programming waay back in the days of Pascal and Fortran and Basic, and was pretty good at it.  How are you defining the volumes for activity of one sort, that can't be used for other uses?

The volume I'm defining for the clouds doesn't extend in the right way to other kinds of volumes.  For clusters of stars I want clustering not a single blob.

Ah - I was imagining that you would use the volumes defined in your black-and-white images above, and generate sparse star fields based on those volumes - not using the full procedure.  Just the part to define the field you are allowed to generate stars in.

Trying to generate stars from gas layering would be rough - unless of course you enabled a physics mask to mimic star formation *grin* but I think that might be a bit more painful than scattering dots in layers then stacking the layers on top of each other and processing them into a randomized single layer.

[Draco18s]

Ah - I was imagining that you would use the volumes defined in your black-and-white images above, and generate sparse star fields based on those volumes - not using the full procedure.  Just the part to define the field you are allowed to generate stars in.

I'm kind of doing that right now, but it's not "webby" enough

Trying to generate stars from gas layering would be rough - unless of course you enabled a physics mask to mimic star formation *grin* but I think that might be a bit more painful than scattering dots in layers then stacking the layers on top of each other and processing them into a randomized single layer.

Oh god, no.  That would be way too complex.  I'm already floating at around 1 minute to generate an image the size of the playing field.

[Draco18s]

What's this?  An update?
Indeed so!  I wish I had more to say, but I don't really.  I was on vacation last week (had a blast) and have been generally slow in progressing.

I have, however, made some significant changes in drawing the background.  It's slower, by a small amount--each 150x150 pixel region takes about 1 second to draw gas clouds--but it looks much better.  Had to do with an increase in Perlin calls.  There's about three different ways I can get similar results (all about the same speed, due to equivalent numbers of perlin calls¹)

I've also got a wider diversity in star sizes.  I draw the larger stars like I was before, but on a half-size bitmap, which is then scaled up and blurred a bit



¹Increasing the number of octaves by 1 means that each 1 pixel call runs the math one additional time.  My options are to either do a 4 octaves call three times, or increase the number of octaves to 6 and do two calls.

[breadbocks]

Ooooh... Pretty...

[Draco18s]

For comparison:

Above image is three w/ four octaves.
Two w/ Six octaves
Two w/ Four octaves

[breadbocks]

I can't actually tell the difference between 2/4 and 3/4.

[Armok]

ok, that's basically perfect.

the only complaint I have is that the big stars look a bit to blurry. have them be more flarey and less blurry.

[Draco18s]

I can't actually tell the difference between 2/4 and 3/4.

If you look at the bottom center of 3/4 it's more turbulent than anywhere in 2/4.  But yes, it may not be worth the extra ~350 ms (per 22,500 pixels).

the only complaint I have is that the big stars look a bit to blurry. have them be more flarey and less blurry.

Agreed.

Someone wrote up a particular lense-flare thing for me, I haven't used it yet, but I think I will now.