Butting lights up against each other

[SneaksieDave]

Someone mentioned butting ambient lights up against each other recently, and it reminded me to try it out from long ago. Here are the results:

 

From lining ambientlightnfo (that's supposed to be no falloff) entities side by side:

Looks great in DR. In TDM, there's a pretty bad gap.

 

Bump the grid size down to 1 and try overlapping them:

Now there's an overlap in TDM.

 

Bump grid down to 0.5 and there's a smaller but still present issue. So you get the point.

 

I'm wondering if there's a way to address this better than settling for a thin line no matter what grid size you try? Maybe a keyword (or one that's missing) in the material causes this apparent rounding of the edges even in a NFO texture?

[Baddcog]

What size are your lights? They don't grid snap, so if you have 2 10.2 unit wide lights you're gonna have to go REAL small on the grid to get them aligned.

 

I'd guess that's the issue as there is no falloff or anything else weird.

[SneaksieDave]

They seem to be grid snapping here... both the origins and the dimensions.

 

I'm guessing that even though it's called NFO, there is some smoothing that's done to it causing it not to reach the full bounds.

[Komag]

I remember dealing with that issue long ago, and I just avoided it by only making ambients abut in places you don't notice

[rebb]

What does the material definition look like for the NFO Light ?

If it has a "zeroclamp" in there, comment that out and see what you get then.

 

ZeroClamp causes the texture to not repeat outside of the 0-1 UV Range, and fills the area with black.

This can cause a small fuzzy border because of texture-filtering.

 

It's possible that you will get "sparklies" where the lights meet tho, because of rounding errors.

[SneaksieDave]

Here's the def:

 

lights/ambientlightnfo
{
ambientLight

lightFalloffImage makeintensity( textures/lights/ambientlightnfo)

{
	forceHighQuality
	map textures/lights/ambientlightnfo_amb
	colored
	zeroClamp
}
}

 

Unfortunately it seems zeroclamp is essential. Without it, it gives that view aligned clip-into-everything rotating sprite effect:

 

 

(Which oddly I had to use printscreen to capture because the screenshot command made this out of it:

 

A path of gold! Err, silver! I wonder if that's ambient or HDR adversely affecting all screenshots.)

[rebb]

Unfortunately it seems zeroclamp is essential. Without it, it gives that view aligned clip-into-everything rotating sprite effect:

 

Oops, yeah looks like it is.

 

Try putting the "nearest" keyword into the projection map stage of the NFO material.

 

That will disable bilinear filtering on the texture and use nearest filtering instead ( not recommended for most textures, but the NFO should have a fully white texture in this stage where there won't be any stepping visible ).

 

I tried it locally and it does produce a sharp edge on the light.

[SneaksieDave]

While I can see a difference in the edge (looks like no antialiasing with nearest) there remains the gap. Rats.

[rebb]

I managed to align 2 lights of 256x256x256 size on the 1x1 grid with no visible gap this way.

 

But yeah, it's probably too fiddly in the end - and even has the potential risk of showing a gap if some graphics-card vendor decided that they should have some fancy new "nearest" filtering implemented which does things slightly differently - but thats just a guess.

[Tels]

While I can see a difference in the edge (looks like no antialiasing with nearest) there remains the gap. Rats.

 

Just curious what you are trying to do here. What's the usage of this, maybe we can emulate it otherwise? Also, is the gap visible if the light-color is very dim?

[SneaksieDave]

No real specific use in mind atm, just wanted to get lights to butt up against each other without a gap or special measures, if possible.

[nbohr1more]

I think I have a solution for this issue but my Gimp skills are holding back my progress so I thought I would share my thoughts:

 

Cross-fade edges.

 

Essentially have one side of the projection texture fade to black then fade back to white. Then another projection texture has the inverse fading on it's edge. Overlap the two patterns and it should be a close to seamless merge.

Obviously I don't have 1.03 to see if any artifacts pop-up

 

 

(If I can workout the correct balance, I will post a pk4)

Edited September 14, 2010 by nbohr1more

[nbohr1more]

I think I see my own issue. The inverse images combine to become gray rather than white so the base color would need to be changed to gray... or one of the inverses would need to be a fractional (half?) intensity of the other so that the two would combine to as close to white as possible...

 

(I know that some optics website is out there with a perfect example and they are laughing at me for re-inventing the wheel )

 

 

Hmmm.. maybe cross-fade to (grey) 888888 instead of (black) 000000 ...?

Edited September 14, 2010 by nbohr1more

[nbohr1more]

 

Edit:

 

2nd attempt.

 

The attached file should work now (unless there are additional 1.03 caveats?)

 

 

Edit: 4th attempt

 

Another straight-edge version

zzz_crossfader_light.pk4.txt

zzz_better_straightcross.pk4.txt

Edited September 16, 2010 by nbohr1more

[nbohr1more]

It works! (in principal at least... I need to make more accurate cross-fade patterns...)

 

[nbohr1more]

Maybe a sloppy zig-zag pattern will obscure a little imprecise positioning...

[SneaksieDave]

Why the complexity of the groove though? I would think that'd just make it more tricky to line up. Unless that's intended to disguise a seam?

 

Ultimately I'd probably end up trying to hide the fade between two soft edged ambients.

[nbohr1more]

I originally had a true cross-fade but realized that the hard-edge at the end of the ramp-up would still have the same alignment problems so I went for another ramp at the end. But a complex cross-fade might obscure the transition more by hiding the obvious line... Yeah, aligning would get crazy if it were too complex. At the very least it would have to be low contrast as possible so that you could fudge a bit.

[nbohr1more]

Does this still sparkle in 1.03?

 

(oh... it only affects screen-shots... ...)

Edited September 15, 2010 by nbohr1more

[plasticman]

Just curious what you are trying to do here. What's the usage of this, maybe we can emulate it otherwise? Also, is the gap visible if the light-color is very dim?

 

Possible usage: see near the middle in Rich's Post over in the slightly derailed "Light Baking" thread.

[nbohr1more]

Yes, that is probably the main area of concern. I just cooked up the other "mundane" usage scenario (excuse) a couple of days ago.

 

Mundane usage scenario:

 

Since the Brush optimizer goes for triangle optimization rather than light optimization, rather than fiddling with Brush cohesion you could break lights that are "too big" into smaller ones that are seamlessly connected.

 

Yeah, it's pretty dull but it's another valid performance optimization option.

 

I think the Strombine usage is pretty exciting though...

 

 

Edit:

 

Here is my zaggy version. Will test soon...

zzz_cross_zaggy.pk4.txt

Edited September 15, 2010 by nbohr1more

[nbohr1more]

It worked! (At least on the wood floor)... I will have to test on a cleaner surface...

 

I will go back and try one last stab at the straight cross-fade but I think the "W" \ "M" zigg-zagg pattern is the optimal pattern to obscure the seam...

 

Now I just have to shrink the edge pattern a bit as it is currently over a quarter of the texture...