Better Night Skies

[SteveL]

I'll be coming back to it when I get my new skybox working! I'm sure the issues can be resolved to make it look as good as it did in attempt #1 while getting rid of the regular patterns. I spotted a bug in the flies distribution code while looking at your original -- it only uses one of its random number sequences in error instead of 2, although fixing that alone doesn't cure the patterns.

 

I've tracked the load time issue.

[rich_is_bored]

I solved the distribution problem in my own way. I used a no draw material as a particle emitter, slapped it on a patch and threw it in the skybox. The patterns are gone.

 

About a week ago I was trying to find scientific data about the color of the night sky to produce a cube map without any other features. This is where I left off with that although it's still not quite right...

 

 

I stopped shortly there after because the color banding was ridiculous, unavoidable because it's so dark, and I got sidetracked looking for ways to dither it. You can't see it here because this is one of the six sides of the cubemap but in game it's awful.

 

At any rate, I look forward to seeing what you've got cooking.

[Obsttorte]

It's not crashing. What's happening is the estimation of the particle effect's bounds is taking almost forever. The engine runs a Monte Carlo simulation during map load, trying 1000 random configurations for each particle and calculating the bounds of the particle effect at every frame. These particles have a life of a million seconds, so multiplying that out, it's a lot of calculations.

 

I've been meaning to look for a way to short-circuit that calculation anyway. I've clocked this process taking up 10% of map load time in particle-rich maps. There must be a more efficient way to estimate max bounds. You'd think it'd be trivial to calculate the maximum from max size and speed and time... but maybe that would produce frequent and vast overestimates, which'd cause a performance hit through particles being drawn unnecessarily. The reason why the engine wants to know the bounds is so it can work out in which visleafs a particle could possibly be seen.

 

Any ideas? If we stick with simulation as the only method, I guess we could limit the number of samples to a sensible amount, which'd fix this example. We could also provide a manual override in the particle decl.

Can you post the code here or point me to the file/method it is defined in? Monte Carlo is a bad choice here, as it calculates every single timestep. But for the boundaries we only need the last one.

[SteveL]

Can you post the code here or point me to the file/method it is defined in? Monte Carlo is a bad choice here, as it calculates every single timestep. But for the boundaries we only need the last one.

 

Sure. It's idDeclParticle::GetStageBounds. Feel free to claim the tracker off me if you want to fix it.

 

It runs 1000 tests, each one testing the position of a random particle quad for each frame of the particle stage's life. Equivalent to testing 1k random quads at each frame. Like you say, it's the "each frame" bit that's causing the problem for long-lived particles. And it's done once for every particle stage, not once for the whole emitter.

 

We can't just use the last frame. There are probably particles that shrink over time instead of growing. My thought was to use a set number of samples spread over the particle lifetime.