Day Night and Lighting Pack

#1 Hi Simon,

I've considered it, but right now it's at the end of a long list of potential features.

The Lighting Pack should work with the day/night resource, but I believe the resource is very out of date, so it might take a lot of effort to implement.

Hope this helps!

-John

#2 OK thanks John

Guess I will still go ahead and get the pack and try it out.

#3 I've been taking a look at the Day/Night resource for integration with the Lighting Pack, and it doesn't seem that there are any major conflicts per se, but my lack of experience working with the Lighting Pack makes integrating the two currently a trial and error process.

From the modeller docs provided with the LP, two things are apparent:

1) We need to reduce all of the basic color settings to 1/2 their value.
2) It's possible that the clamps to 1.0f in the Day/Night resource (as well as clamping the emissiveScale to 1.0f) may be an issue.

Has anyone successfully modified the Day/Night resource with the LP requirements to get things back to "normal" (before adding in custom stuff from the LP).

The root issue I'm working on fixing right now is a washing out of one of our terrain types (provided from the RTS-SK IIRC).

Terrain image prior to adding in LP:

Terrain image after adding in LP:

Both these images are taken at/near the same time of day. As you can see, the general ambient light is roughly double in the second image (as expected), but the rocky terrain area is much more highly over-exposed then the grass (at least in appearance).

The only lighting objects in either scene is the sun itself (with two sunFlares, stock from the fxLighting resource), and of course the modifications from the Day/Night resource.

Anyone have any suggestions as to where to start when normalizing the mission so we can move on to LP customizations?

#4 Quick update: Halving the color values for each band in Celestial.cc, as well as changing the clamps to 2.0f from 1.0f in Celestials::enableLighting() is looking good, and for most should do the trick with good results.

However, with this specific terrain texture, I'm still getting highly over-exposed rendering. The other terrain textures appear very nicely, so I'm guessing that my specific issue is related to the texture itself.

So, anyone have any suggestions as to how to "tone down" the texture itself to stop it from over-exposing so strongly?

The textures are:

rock.png:

and

rock-test.png

#5 Stephen: being a coder, I'm not sure this will help.

But in Photoshop you can modify the color range of an image so that instead of going from 0->255 to 0->127. It will adjust all colors in your image automatically, and going from 0->127 will not wash out the terrain.

Image -> Adjustments... -> Levels...
The bottom slider is the one you want

(I might be totally mis-answering your question, but from what I read thats what you need)

#6 Will give that a shot Thomas (or my artists will, hehe), thanks for the pointer!

#7 Hi guys,

Resources that adjust the terrain's brightness and contrast (like the Day/Night resource) create two problems; the terrain is dimmed with the overexposure still present (the problem you've seen), and the resource will dim static lights along with the sunlight.


The Lighting Pack is designed to work around the first problem:

-Open 'sgLighting.h' and comment out the line '#define SG_USE_TERRAIN_COLOR_CORRECTION'. The color correction is used to enhance the terrain's textures, otherwise the 16bit terrain textures start showing color bands. Unfortunately to use Day/Night type resources you need to sacrifice the nice terrain textures.
-Removing the color correction macro doesn't affect the terrain blender, so you need to either turn on the C++ blender ('blender.cc' line 18, comment out '# define BLENDER_USE_ASM') or comment out the Lighting Pack code blocks in 'blender_asm.asm'.


This change is Day/Night specific:

-Add the line 'glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_EXT,GL_MODULATE);' to 'terrRender.cc' after every occurrence of 'sgTerrain::sgRenderBlockBegin(multitextureFog);'.

Although I've never tried to use the Day/Night code, based on the changes it makes to 'terrRender.cc' this should work.

Let me know how it goes.

-John

#8 @John: Thanks a lot for your time--good info!

After reviewing the lighting pack's documentation, as well as my (limited) understanding of the technique, and more specifically the concept behind the day/night resource, it seems to me that instead of hacking the lighting pack to work with the day/night resource as it exists, there could be a better solution that would involve re-working the day/night resource for more effective utilization of the lighting pack. The first fix above specifically concerns me, mostly because it involves disabling functionality of the lighting pack itself, especially the asm blender (doh! performance decrease is normally bad when you can avoid it).

Time based illumination changes ("day/night") is probably an area that most games are going to want in some form--not all of course, but I would suggest that it's a pretty industry standard feature now in many game genres. With that in mind, it looks to me like a good time for someone to re-work the day/night resource to be more appropriate for the lighting pack, so I guess I'm volunteering!

That being said, my rendering/lighting knowledge is limited in the extreme. Do you have any references online that you would suggest would be good background material for researching this type of re-write for the resource, and/or suggestions as to how to overcome the issues without the restrictions in your fixes above?

Feel free to email me details if you like, and once we get a good solution working, we'll be more than willing to post up a patch and/or new integrated resource to the community.

P.S: Thomas' suggestion about simply changing the levels of the textures itself worked like a champ, but it doesn't address the second issue you pointed out, and also does cut the texture's color functionality in half, so isn't a positive long term solution either.

#9 Hi Stephen,

I recommend trying the fix I listed above first. You don't have to shutoff the terrain blender:

Quote:-Removing the color correction macro doesn't affect the terrain blender, so you need to either turn on the C++ blender ('blender.cc' line 18, comment out '# define BLENDER_USE_ASM') or comment out the Lighting Pack code blocks in 'blender_asm.asm'.

The only longterm solutions I can see that solve both problems involve recalculating the lighting during time/color sifts,which although possible, is very in efficient, or storing multiple light maps for the terrain and certain interior surfaces, which causes a significant rendering and memory overhead. I haven't looked into it much, so I'm sure there are other alternatives, but even if you create a new resource you'll still need to hack up the Lighting Pack a little.

Hope this helps!

-John

#10 @John: I got the lighting pack working with the original day/night resource just fine... I am going to dig in and see if I can stop the modulation on the inside of interiors, so we can use statics there... otherwise, the dynamic lights coming on or off depending on time of day is super cool!!!

The lighting pack totally rules...

Thanks!,
-Josh

#11 Hi Josh,

That would be awesome! If you need any Lighting Pack specific info just ask, I'd be happy to help out with this.

The day/night resource rocks man. :) Thanks!

-John

#12 Updated tutorial Josh ? :)

#13 John,

Are there certain Macs that lack fog coordinates?

#if defined(TORQUE_OS_MAC)
   gOpenGLDisableFC = true;

Thanks,
-Josh

#14 Hi Josh,

I disabled fog coordinates on Mac because the stock TGE fog coordinate code seems to have an endian related issue (I think it's only on interiors, other objects seem to be fine). When fog coordinates are enabled the fog colors are assigned to the wrong verts. The same issue happens with TGE's stock interior vertex lighting. There's more information related to this issue in this thread.

Here's a snapshot of a completely clean TGE 1.2.2 with fog coords enabled:


-John

#15 I hope people are still tracking this thread...


I've applied the Day/Night resource (Sam's Celestial version) to a Lighting Pack modded TGE 1.3

One thing that I notice is that all DTS objects are lit from the initial direction of the sun, and not from the updated sun vector.

This is a problem with the Day/Night resource and stock TGE 1.3 as well, it seems.

I've dug around a little in the sgLightingModel code to try to get the lighting model to pickup the gCelestials->mSunVector, but I think this is a little beyond me. (Although I have successfully altered the sgLightManager to pickup DTS dynamic shadow vector from the sun vector when a vector light is the sun...)

I'd also love to get the outside of interiors lit correctly according to the sun, but nobody seems to have tackled that yet. :)

Can anyone offer any advice?

#16 But what will be if you use some light source that mach position of sun, and lit objects by this light?

>>altered the sgLightManager to pickup DTS dynamic shadow vector
it is realy good thing, in my project all structurs will be made like dts not dif, so dynamical shadows will be good feature for me.

#17 Hi guys,

Trying to add the 'gCelestials->mSunVector' into all of the lighting code (both TGE and the Lighting Pack) is not a good idea - instead make sure the sun object's directional vector is updated to use 'gCelestials->mSunVector', then all of the code that uses the sun's direction will work without any changes.

The easiest way to handle this is to add the following line in the beginning of Sun::registerLights:

mLight.mDirection = gCelestials->mSunVector;

(Make sure to include the header file that defines 'gCelestials'.)

Let me know if this helps!

-John

#18 Hey John,

That works perfectly, thanks for the tip. Having the lighting model in sync with the sun position makes a huge difference to the day/night system.

Cheers!

-Seb

#19 "mLight.mDirection = gCelestials->mSunVector;"

I followed this last fix: and didn't see any difference. What was that supposed to change? somthing with shadows?


Did any one ever come up with a major update to the Day/Night? I'm working on a minor one but a I submitted it once and never heard back... :-(

#20 I think I understood about 5 words the post so far, but the environment artist in me is drooling over the idea of getting a lighting pack/day night cycle in the an RTS made with the RTS environment pack I am working on.