Return to “Dev Logs”

Post

Re: Tuesday, January 31, 2017

#31
I thought Josh explained how he was doing the 'skybox' at one point. My forum search-fu is failing me at the moment. Where's Just Ice being our walking LT-O-Pedia when you need him? :lol:
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: Tuesday, January 31, 2017

#33
Ringu wrote:Uhh... does this mean that you're *not* generating the star field as a skybox, just mapping a texture to a (really large) cube/sphere/whatever...?

If you're actually calculating the position of each of those stars and rendering them as objects or points or whatever, instead of just generating what is essentially an image texture, I might have a clue as to how you can massively optimise your engine :-D
No sir, baking stars into the skybox is unacceptable for us aesthetic snobs here at LT ;) From both a visual fidelity and a performance standpoint, it's actually worse! You'll never get skybox stars to look as crisp as the ones you see here, + cubemap distortion will be very evident on such small objects. To even get close to this fidelity you'll need at least a 4096 resolution skybox, and still it will look blurry compared to this. OTOH, rendering a starfield as a single mesh (all star positions are of course baked into a single mesh during generation) is very fast, allows each star to have 'perfect' resolution, and allows you to get by with a much smaller skybox (512 in this case!), which increases performance dramatically. It was a big upgrade for LT's graphics back when I first made this change :D
Cornflakes_91 wrote:Or that theres simply a discrete parameter for star count :P
Which would fit the statement better
Yes for the pax demo there was. In real LT that parameter, like most system parameters, would be computed.
Grumblesaur wrote:"Vary depending on where you are" does not strictly imply "random star count for every system's skybox".
Correct, most system parameters, including star count, vary 'relatively smoothly' over space (in the sense of a 'smooth' noise function), so as to give neighboring systems some sense of coherence.
alpan wrote:This was fantastic. I really appreciate you doing this, Josh.

I should add: With respect to your decision to go ahead with the Mersenne Twister implementation, were you aware of this post by Veedrac?

I am not sufficiently versed in RNG/PRNGs, but if PCG will result in better performance and randomness, why not take it into consideration?
Thanks alpan. I have seen this post, but MT is very fast and very good at randomness, plus I'm used to it so...don't see any reason to change :)

---

Thanks everyone else for the positive comments...here's to a happy 2017! :thumbup:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Tuesday, January 31, 2017

#34
JoshParnell wrote:No sir, baking stars into the skybox is unacceptable for us aesthetic snobs here at LT ;) From both a visual fidelity and a performance standpoint, it's actually worse! You'll never get skybox stars to look as crisp as the ones you see here, + cubemap distortion will be very evident on such small objects. To even get close to this fidelity you'll need at least a 4096 resolution skybox, and still it will look blurry compared to this. OTOH, rendering a starfield as a single mesh (all star positions are of course baked into a single mesh during generation) is very fast, allows each star to have 'perfect' resolution, and allows you to get by with a much smaller skybox (512 in this case!), which increases performance dramatically. It was a big upgrade for LT's graphics back when I first made this change :D
An excellent point - I haven't looked at the images at full size so didn't appreciate the fidelity.
With that level of performance, it obviously makes a big difference.

Nicely done :-D I'm all in favour of bypassing classical techniques in order to gain something!

Can I just say I'm loving Josh 3.0!
--
Mind The Gap
Post

Re: Tuesday, January 31, 2017

#35
Ringu wrote:An excellent point - I haven't looked at the images at full size so didn't appreciate the fidelity.
With that level of performance, it obviously makes a big difference.

Nicely done :-D I'm all in favour of bypassing classical techniques in order to gain something!

Can I just say I'm loving Josh 3.0!
Hahah thanks :) It's good to be alive :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Tuesday, January 31, 2017

#36
Thank you, Josh.

It was great to meet you in person this past weekend, wonderful to see a new devlog, startling to be able to reply to devlogs, and really pleasing to hear that you're feeling energized by the whole experience.

Looking forward to continued progress!

Also, those star systems are clearly located within a globular cluster. (Although a "real" such cluster would have more old, red stars, but artistic license FTW.)
Image
Post

Re: Tuesday, January 31, 2017

#38
JoshParnell wrote:Thanks alpan. I have seen this post, but MT is very fast and very good at randomness, plus I'm used to it so...don't see any reason to change :)
In your case, there is no need to, speed > quality of random. So long as the random is reproducible.

PCG is rather amazing quality random, but you would only want this for cryptographics really.
And LT has zero need for Crypto.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: Tuesday, January 31, 2017

#39
Silverware wrote:In your case, there is no need to, speed > quality of random. So long as the random is reproducible.

PCG is rather amazing quality random, but you would only want this for cryptographics really.
And LT has zero need for Crypto.
The site is an interesting read, as I was not aware of some of the failings of MT. That being said, anyone claiming that MT is slow needs to have a good, hard look at the 'average' case:

Code: Select all

uint x = self->state[self->p++];
  x ^= (x >> 11);
  x ^= (x <<  7) & 0x9D2C5680U;
  x ^= (x << 15) & 0xEFC60000U;
  return x ^ (x >> 18);
It's quite a small number of instructions. As per the 'huge' state...~2KB state...exactly how many RNGs are you instantiating that 2KB is huge?? Seldom do we need more than one RNG...in LT's case we may have a few in existence at any given time.

Still, to see that it fails some of the newer statistical tests is not promising. If indeed anything based on a linear congruential generator can provide better randomness than MT, then I have fundamentally misunderstood a great deal when it comes to randomness :ghost: Course, that's probably because the default C library LCG is so bad that everyone has been burnt by it at one point or another. I can remember actually noticing the 'better randomness' when I switched from rand() to MT in LT. It's bad when you can notice something so subtle like that (distributions of colors in nebulae, procedural names, etc.)

So, perhaps this 'PCG' warrants a read. But seriously, did they have to use an abbreviation that is already quite heavily-reserved in my brain for procedural content generation? Come on guys, there can only be one PCG :ghost:
Flatfingers wrote:Thank you, Josh.

It was great to meet you in person this past weekend, wonderful to see a new devlog, startling to be able to reply to devlogs, and really pleasing to hear that you're feeling energized by the whole experience.

Looking forward to continued progress!

Also, those star systems are clearly located within a globular cluster. (Although a "real" such cluster would have more old, red stars, but artistic license FTW.)
Likewise, Flat!

You know I actually did a tiny bit of research to try to find out a bit more about the distribution of star temperatures in galaxies, but wasn't able to find anything 'simple' (the general answer seemed to be "it's complicated"; though obviously older -> more red in general). When I tried a red-heavy distribution I ended up not liking the look as much. So yeah, artistic license :P At least the star colors are actually based on temperature now and not just random RGB!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Tuesday, January 31, 2017

#40
Yeah, the standard random libraries in basically everything are horrible.
For instance, the Math.random() in JS shipped with all browsers is heavily slanted towards the 0.0-0.5 range, to the point that you typically double the maximum when using it.

However, for artsy stuff, bad RNGs might actually be useful, producing specific distributions can be really good for getting things to look the way you want them to.
Although, relying on a bug is never a smart idea. :P
See: xkcd, workflow
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: Tuesday, January 31, 2017

#41
Yeahhh I prefer to produce my distributions by starting with something I know to be random and applying transformations :?

This 'PCG' paper, despite needing a new name, is actually turning out to be one of the best reads in recent memory. Very brilliant stuff. I'm not finished with the (rather lengthy) paper yet, but I imagine by the end I'll be itching to replace Mersenne. This monkey can accept when he's wrong :monkey:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Tuesday, January 31, 2017

#42
JoshParnell wrote:Yeahhh I prefer to produce my distributions by starting with something I know to be random and applying transformations :?

This 'PCG' paper, despite needing a new name, is actually turning out to be one of the best reads in recent memory. Very brilliant stuff. I'm not finished with the (rather lengthy) paper yet, but I imagine by the end I'll be itching to replace Mersenne. This monkey can accept when he's wrong :monkey:
Hehe. There are premade C implementations from memory, do it properly and write a 'Random' wrapper that pokes into any/all of your RNG systems you want to use. :V
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: Tuesday, January 31, 2017

#43
JoshParnell wrote:At least the star colors are actually based on temperature now and not just random RGB!
You really don't know the joy I felt in my geeky Simulationist heart when you mentioned that last Friday. :)

Now the question is whether you used a "realistic" (not a fan of that for games, but let's roll on) H-R diagram-like distribution of stellar temperatures....

If you wanted a distribution by temperature, that's actually pretty well known for the Milky Way Galaxy: https://en.wikipedia.org/wiki/Stellar_c ... sification .

If what you really want is a distribution by luminosity -- which I did, for one of my games -- life is more complicated. I actually had to ask this question on StackOverflow; there have been a couple of answers, both of which take some parsing: http://astronomy.stackexchange.com/ques ... 8560#18560 .

Orrrrrrrr... you could just wing it and apply an exponential function where the hotter stars are less likely, except that this will be biased toward red (cooler) stars and thus not as pretty.

And so we're back to an "artistic" generation function. Which works for me! ;)
Post

Re: Tuesday, January 31, 2017

#44
The big thing, is that it doesnt matter how many stars you have, only the brightest should be visible.
So the fat reds, medium/big yellows, and all the whites/blues.

The distribution should actually end up somewhat linear for star color.
Simply because the majority of stars are small and not luminous enough to be typically visible.

And the star(s) in the system should end up being reasonably linearly distributed because wormholes and jumpgates allow you to connect any system to any system based on a developers whim without breaking any laws. :D
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);
Post

Re: Tuesday, January 31, 2017

#45
JoshParnell wrote:
Ringu wrote:Uhh... does this mean that you're *not* generating the star field as a skybox, just mapping a texture to a (really large) cube/sphere/whatever...?

If you're actually calculating the position of each of those stars and rendering them as objects or points or whatever, instead of just generating what is essentially an image texture, I might have a clue as to how you can massively optimise your engine :-D
No sir, baking stars into the skybox is unacceptable for us aesthetic snobs here at LT ;) From both a visual fidelity and a performance standpoint, it's actually worse! You'll never get skybox stars to look as crisp as the ones you see here, + cubemap distortion will be very evident on such small objects. To even get close to this fidelity you'll need at least a 4096 resolution skybox, and still it will look blurry compared to this. OTOH, rendering a starfield as a single mesh (all star positions are of course baked into a single mesh during generation) is very fast, allows each star to have 'perfect' resolution, and allows you to get by with a much smaller skybox (512 in this case!), which increases performance dramatically. It was a big upgrade for LT's graphics back when I first made this change :D

I also always had the impression that you generate more nebulae around where there are more stars. I don't if that's the case or if it's just easier to note the stars against variation of colors.

Online Now

Users browsing this forum: No registered users and 15 guests

cron