Better Night Skies

[rich_is_bored]

I had a thought on the way home from work today and figured it was simple enough to test. What if the stars in a skybox were represented not just as pixels in textures but also as pure white quads in a particle effect? If they're sufficiently tiny and move slowly enough it should yield a much more realistic effect.

 

Well I tried it. It works, it's cheap, and here's the declaration...

particle starfield {
	{
		count				1000
		material			_white
		time				1000000.000
		cycles				0.000
		bunching			0.000
		distribution		sphere 64.000 64.000 64.000 
		direction			cone "90.000" 
		orientation			view 
		customPath flies 0.005 0.005 64.000 
		speed				 "0.000" 
		size				 "0.050"  to "0.100"
		aspect				 "1.000" 
		randomDistribution				1
		boundsExpansion				0.000
		fadeIn				0.000
		fadeOut				0.000
		fadeIndex				0.000
		color 				1.000 1.000 1.000 1.000
		fadeColor 			0.000 0.000 0.000 0.000
		offset 				0.000 0.000 0.000
		gravity 			0.000
	}
}

To see it for yourself save it as starfield.prt and place it in your darkmod/models folder. Then you can use noclip and testmodel to place it in an existing mission's skybox or use DR. I'd post a video or screenshot but the effect is too subtle to view in any other medium.

Edited September 2, 2015 by rich_is_bored

[Bikerdude]

To see it for yourself save it as starfield.prt and place it in your darkmod/models folder. Then you can use noclip and testmodel to place it in an existing mission's skybox or use DR. I'd post a video or screenshot but the effect is too subtle to view in any other medium.

If the declaration is a particle effect why would I/we place it in the models folder..?

 

With it placed in the particles folder and a func_emitter placed inside the skybox the game won't map, it just sits there after typing the map command.

[rich_is_bored]

Yeah, I was able to create the effect using editParticles but I haven't been able to load it since. I'm assuming it goes in the particles folder then but I haven't done anything with this engine for a good while and I'm rusty.

[Bikerdude]

If you could knock up a test map for me to have a play with that would be greatly appreciated.

[Sotha]

Hm.. so if you apply an occasional gravity enabled star particle, you could have an occasional shooting star. Little something interesting to look at in the sky...

[Bikerdude]

Hm.. so if you apply an occasional gravity enabled star particle, you could have an occasional shooting star. Little something interesting to look at in the sky...

Have you managed to get it working? if so got a test map..?

[rich_is_bored]

I've tried making a test map but it refuses to load with with the particle effect present. If I delete the entity it loads fine. Bug perhaps?

 

Until I have more time to troubleshoot the issue, it looks like the only way to view it is to recreate it with editParticles.

[SteveL]

This is timely. I've been looking at night skies too: messing with noise functions on shadertoy to make a procedural cloud shader.

 

I'll have a look why your particle isn't loading...

[SteveL]

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.

[grayman]

Why aren't the absolute effect boundaries defined in the particle? It seems silly to calculate something at map load time that could be determined by adding the size of the largest particle to the distribution boundaries ahead of time.

[SteveL]

Why aren't the absolute effect boundaries defined in the particle? It seems silly to calculate something at map load time that could be determined by adding the size of the largest particle to the distribution boundaries ahead of time.

 

Agreed completely, but I can't think of a way to implement it without a heap of work. There are quite a few particle distributions, and they each have their own code. So deriving the max size of distributions could mean writing and testing a lot of new code, and we'd have to either remove the editParticle code from the engine, or make all changes in two places (DR and the engine), plus we'd have to update all existing particle decls.

 

We do have some options that don't involve changing the output of the particle editors in DR and the engine:

1. Stick with the Monte Carlo method during map load, but limit the number of samples. Spread a fixed number of samples across the particle lifetime instead of calculating the bounds at every (60fps) frame during the lifetime.
2. Stick with the existing method and calculations but do it during dmap instead of at map load time, and store the results in the proc file.

(1) strikes me as attractive. Not the way we'd design it if we were starting from scratch, but it needs very little new code. What do you think?

[nbohr1more]

Option 1 sounds good to me, but I think we should add a way (new feature) to define the bounds manually for future definitions if there's a practical way to do so.

[VanishedOne]

Option 1 sounds good to me, but I think we should add a way (new feature) to define the bounds manually for future definitions if there's a practical way to do so.

That could be useful for the problem discussed in some of the posts on http://forums.thedarkmod.com/topic/9082-newbie-darkradiant-questions/page-231regarding unwanted clipping through walls and roofs. Edit: maybe not for what Goldwell originally asked about, but for cases where a lamp glare clips through walls or something.

Edited September 2, 2015 by VanishedOne

[Bikerdude]

I also vote for option 1, seems the least amount of work to get the desired effect.

[rich_is_bored]

Thanks for the direction Steve. I wanted a particle that didn't have a lifetime so I opted to use a ridiculously high value. I've paired it down a bit and it works fine.

 

I've got a crude test map with everything setup. It can be found here...

 

https://onedrive.live.com/redir?resid=D6625ED3877C9FB4!1150&authkey=!AJiXvvAkc6DWFps&ithint=file%2cpk4

 

This is the first file I've shared out in this manner. Just say the word if I need to find another host. Simply drop this file in the root of your darkmod folder, fire up the game, and enter 'map stars' at the console.

 

You may not notice anything at first unless you move around. That's intentional. I'm also curious to see how this works at resolutions other than 1920x1080. The effect is a product of aliasing, which means resolution may be a factor.

Edited September 3, 2015 by rich_is_bored

[Bikerdude]

You may not notice anything at first unless you move around. That's intentional. I'm also curious to see how this works at resolutions other than 1920x1080. The effect is a product of aliasing, which means resolution may be a factor.

It works, but I am seeing repeating patterns, I was running TDM in a window @ 1024*768 -

 

[grayman]

I'm at 1280x720.

 

The stars twinkle, but only when I move. Is that the expected effect?

 

I also see the patterns in Biker's pics.

[SteveL]

I tried the stars at 1280x720 and at a few 16:9 screen sizes. They always twinkled nicely when the player view was changing: a big improvement over textured stars.

 

I also tried adding a rotation to the decl, to see if it would make them twinkle when the player view is still. It didn't.

 

I see the regular pattern too... maybe a consequence of the flies distribution.

[rich_is_bored]

I'm aware of the concerns raised but haven't yet worked out the best solution. It all has to do with the line...

customPath flies 0.000 0.000 64.000

I need a different way of distributing particles along the surface of a sphere to eliminate the pattern. I can make it less apparent by pairing down the number of particles or rotating the func_emitter 90 degrees so the poles are at the horizon instead of up/down but neither solution is ideal.

 

The movement contingent twinkle is a side effect of the particles having no motion. Impart a small amount of motion and they'll twinkle all the time but path they follow is not east to west. You have stars flying towards or away from other stars which looks really odd.

 

I recall there being a way to create materials that act as particle emitters. That might be the solution here but I'll need to experiment.

[rich_is_bored]

 

I've updated the test map. There is no visible pattern and the twinkle is persistent. Same link as above.

[grayman]

The patterns are gone.

 

Much more twinkling when moving than standing.

 

Do the stars really twinkle like that? Maybe it depends on where you live. Maybe it won't be so noticeable with buildings around.

[VanishedOne]

If I stand still or move in a straight line I get a twinkling effect, but when I turn my head it feels like static interference. At risk of sounding like Whistler I wonder whether it would work better with fewer stars.

[Arcturus]

In the demo new stars are mixed with old texture, right? That could be confusing. The twinkling is too stepped, it's not smooth enough. Maybe it could be faster.

[VanishedOne]

I just ran into the problem of long-lived particles making map load take ages while working with foliage particles. Those things don't even move! (In fact, having a randomised yet unchanging distribution was the point of giving them long lifespans.)

[rich_is_bored]

Glad to hear this experiment was useful in some way.