Sun vs Directional Light and flare

Life gets weirder for me. Ok, I wanted to have some controllable light (as in aka I want pitch black and a sun that rotates around the terrain) I can't find the sun control for the default light will find that later, but in the mean time I added a second light source and turned on sun glare. Well the second light has no glare only the default light source has glare and the second light should have the glare but only the default sun has glare. I want to move the sun on a timer and I want the second light source to have glare (aka multiple suns around the planet)
Here is the only thing I got so far, as you can see only 1 glare, if I move the camera and face the second light source, no glare. I am pretty sure I remember where the default light setting is, but in the mean time how to I add halo to the current light source as a secondary halo? Make it show on top of that.

I forgot to mention the default light source is WHITE the secondary light source is YELLOW, in this scene you can see the default light source is YELLOW and the secondary light source is also YELLOW. When I add a new light source the default took on its properties, I can add a screen shot of my project settings to show the default light should not be yellow if you like.

 

By "default light" do you mean "ambient light"? The color (and thereby the intensity is set in the Render Settings.

But the ambient light is not directional and has no flare, cookie, etc.

It is the amount of light everywhere, and you set it in concert with your in-game lights to fill shadows to the degree you want them filled.

By adjusting the ambient light, you should be able to do a nice sun with a single in-game light.

 

Doc, that sun with flare you are seeing is after I added a light source which is not on the horizon. The sun is actually in the sky, off the top of the image. The sun with the flare is the result of me setting flare on with sun attached to the new light source.

 

Sorry for misunderstanding your problem -- the screenshot wasn't super-clear about what objects you had in your scene.

That is very strange all right!

 

Here give this a try and see what results you get. Create a terrain, standard size, use dirt as the texture for the terrain, rumble it up some. Ok, now add in a skymap, one of the default like 'sunset' is fine. Ok, now go into the settings and change the ambient light to black. This will make the terrain black (aka trying to represent full darkness), now, add a secondary light source, place it at 1000,1000,1000, this should be sufficient. Now, change the light source to directtional (or point) and up its intensity to 8 from 1. No difference in the base terrain light. Change the distance to 2000, still no change on my end.Play around with the light settings to see if you can get the terrain to be fully lighted from the secondary source (other than the built in default light that I want turned off completely since I can't control its orientation or location)

Basically have the light that you just added try to light up the terrain that you have with an ambient black. This in 'theory' should be the solution to turning off the ambient light and allowing you full control over the light source. I can't get it to work on my end.

 

Directional lights are infinite. It doesnt matter where they are placed in the scene. Its only their rotation that makes the difference in lighting and when lensflares are shown.
When using a point light be sure to increase the range, when you want it to light the whole terrain. A Point light has no rotation effect. Light is only changed, when moving it arround, flares are shown all the time.

As Halos are based on the distance the light travells, directional lights have NO correct halo because it would be endless. Setting a halo to a point light would mess up your scene too, because, you would have to set the range of the point light far enough to light your whole scene... your halo would be that big too.

Now for the conclusion

Use a script to move your directional lights around your scene like suns would do. Be sure to point the directional lights z-axis toward the scene all the time in order to get a correct lighting and to see lensflare effects (You can have multiple lensflares at the same time, its no problem).
Create a Sun (Particle, Sphere-Model, whatever you want) and let it travel with the lightsource for a more convincing effect.

If you only need the lensflares (no sun models) then it would be enough to simply rotate your directional lights anywhere in the scene. Moving them around will have no effect at all. The above stated movement will only be neccessary to control the fake sun models position in a correct context to the incoming light.

Lights in a realtime 3D engine work different from those in 3D Render Applications. Consult the docs for more information about how lights work in Unity.

I hope this will be useful.

Frank

 

Thanks for the pointers, however, it doesn't solve the underlying problem. No way to turn off the default light that has the diffusion on it. Which means the scene is always lit. Nothing in the documentation that I have found to kill the default light source that has diffusion attached to it. If you try what I suggested about creating a terrain, give it a texture turn diffusion to black, then create a point light to point at the terrain placing the light at 1000,1000,1000, give it a value of 8 for its intensity, a range of 2000 which is beyond the terrain by an additional 1000, an angle of 179, constantly point the cone to the terrain, the black area of the terrain made by the diffusion doesn't get lit.

Consulting the documentation is a great thing but, when this is a problem the documentation doesn't say "here is how you disable the default light which has the diffusion attached to it", if it did, would be no need to start this thread

Thanks again for the pointers, still in dire need to kill the default light source with diffusion attached to it.

 

That's because there isn't any such thing.

--Eric

 

Looks like I found a bug then. The skybox should not be lit then if the light source can be turned off. Here are all the results to further demonstrate the issue. Maybe in the mean time I can just switch the skybox to a night sky. Here are the shots where I can't seem to stress the black on the terrain which should not be there but it is. More in next post, I can only do 3 attachments at a time.

 

Here are the rest of the shots. The basic scenario is this, I want to just create my own light source have it properly light the terrain, bout it really. I'll wait until you get the rest of the light sources working against the terrain since I think Spotlight would fix this problem in general (although maybe not the black area)

 

I don't think so--skyboxes don't use lights at all (wouldn't make sense for something that's infinitely far away and not actually part of the scene in a conventional sense). I've seen no issues with lighting terrains, aside from only directional vertex lighting working, but UT is well aware of that, and they're working on it as they said.

A directional light works fine. A spotlight would be the worst choice, as it is the slowest, and really not intended for lighting large areas. If you don't want solid black areas, then turn the ambient lighting back up maybe? It looks like your light is nearly parallel to the terrain, so naturally not much is going to be lit. Try turning it so that it's aimed more down at the terrain, not across.

As Alpha-Loup said, directional lights are infinite, and have no position in 3D space. You can put one at 0,0,0 or 3492,-3483,2855 and it will make no difference at all. The only thing that matters is the rotation.

--Eric

 

I just ran an experiment with "sun" lighting, simulating the light effects as the sun rises, travels across the sky, and sets.

• 
  * Edit -> Render Settings -> Ambient Light is set to pure black.
  * Placed a simple terrain spanning 0,0 to 2048,2048; center at 1024,1024.
  * Added the sunset skybox to the camera.
  * Placed a directional light and attached a script so it always pointed towards 1024,1024 (using LookAt).

And this is what I saw:

• 
  * The terrain was lit correctly as the directional light traveled trough the sky, above the horizon.
  * The terrain was lit when the directional light passed beneath it. Therefore, the directional light must be turned off when below the horizon. (This was expected.)
  * The skybox was always self-illuminating and not affected by the directional light. (This was expected.)
  * The skybox could be dimmed by changing the material -> tint color attribute. (This was expected.)
  * Even when the skybox tint color is pure black and all lights are off, the skybox remains illuminated a fair amount. (This was not expected.)

From this experiment I would surmise that the RenderFX/Skybox shader has an anomaly, in that it is always illuminated even when the tint color is pure black. This may be by design, but it is not what I expected.

 

I think this is an artifact of the method used to allow overbrightening. As it is, 50% tint = full brightness, but you can lighten it more than that. If you make a new shader that's the same as the skybox shader, but you change all instances of "combine texture +- primary" to "combine texture * primary", then you can have a pure black skybox when the tint is set to pure black. But then you can't overbrighten it, either...100% tint = full brightness in that case.

--Eric

 

I want to get rid of ambient lighting all together. I want the light to be pure to the other light sources. Add ambient lighting to the other light sources if need be, but get rid of the ambient from the render settings menu all together and apply it only to the 'other' light sources. If I have ambience, I want it to be specific to the other light sources and not a global setting in my case. I understand where you are coming from on the rest of the subject, I really do. Based on earlier conversation they are working on terrain lighting from the other light sources. I can't currently achieve the desired outcome for the lighting in Unity that I would normally be able to do naturally in DX9. I'll post up some images of what I am talking about tomorrow night, have to pull out some old DX9 code.

 

What about combine texture * primary double? (Or combine texture * primary quad.) Would that allow over-brightening, while still bottoming out at 0?

I dug around the wiki, and it looks like Aras had posted a blended skybox shader, which might also do the job.
http://www.unifycommunity.com/wiki/index.php?title=SkyboxBlended

[Edit: I just tried the blended skybox shader, replacing the "+- primary" expressions with "* primary double." I dropped in the sunset and blue sky textures. Tint color combined with the blend property provide excellent results for controlling day/night, with the ability to darken to 0 or over-brighten.]

 

This can be done. Drop in a new shader for the skybox (see above, with modifications) and turn off the ambient lighting. The directional light will control the lighting on the terrain and the tint color + blend properties will control the lighting of the skybox. Below is some code that accesses tint color and blend. This code assumes the skybox is global, set through Edit -> Render Settings.

Code (csharp):

1. var color = Color(0.5, 0.5, 0.5, 0.5); // just an example color
2. RenderSettings.skybox.SetColor( "_Tint", color );
3. RenderSettings.skybox.SetFloat("_Blend", 0.5); // just an example
4.  

 

Is this the effect, you want to create?

 

That effect is close to what I want, but I think I need to play with creating a custom skybox shader. Directional light (aka 360 degree light) was not on the horizon it was in the sky, and the lighted hills were ok, but the base terrain was black. So this is incorrect behavior. I can't seem to explain the fact that there was no horizon light at all. The light was in the sky, the terrain was lighted like the light was on the horizon, but it simply was not there. Now, if it was at the horizon, then I would expect only the hills to be lit and the black area to be black. I'll get the chance to play around with it more in detail and do more screen shots tonight when i get off work and supply other shots as to what else i am trying to accomplish. Thanks everyone again for all the hints and ideas.

 

Well, as I said before, directional lighting has no position in space; only the direction (rotation) has any effect on the lighting. Whether it's on the horizon or in the sky is irrelevant.

--Eric

 

Eric:

According to this, Aras is stating that directional light is shining horizonatally, which it didn't matter as far as I knew, but I would assume he knows more than I do, I always assumed that directional light had no direction other than everywhere (all directions) but I am wrong on this. The light was in the sky, not on the horizon, was directional, so had no direction and the terrain was still black.

Here is some screen shots of more like I am trying to do, the sky is completely black in this scene, and the first image is the terrain lit up with the global light like Unity does without ambience. The next 2 shots are where I turned off the global light and the only lights are point lights from the headlamps of the tank lighting up the terrain, buildings, trees, everything around it within the cone diameter.

Hope this simple demonstration can shed some light on what I am trying to accomplish. This is a crappy program I wrote about 2 years ago, using DX9 library functions.

 

Getting closer to success as to what I want, I can actually live with what I have so far I think. Here is a screen shot but there is an error that dev's might want to know about. This shot shows the sun as it comes to rest near the horizon, now, the good thing here is that I now have the terrain going black as the sun disappears off the horizon under the terrain, I need to work on its orbit some more but its really almost there.

 

Directional light, being, well...directional...yes, it certainly matters. A directional light only has a direction, hence the name. This simulates the light from the sun, where the sun's light rays are essentially parallel (since it's freakin' huge ). A directional light has no source, and no distance, therefore Range and Attenuate do nothing. Moving a directional light around in 3D space has no effect on anything whatsoever; its rotation is the only thing that matters. This is what the directional light gizmo is illustrating.

There is no such thing as "the" global light; any directional light is global, and affects everything based on what its direction is. Except, of course, for shaders which don't use lighting, such as a skybox, where it wouldn't make any sense for it to be affected by lights. It's also unlikely you'd want to completely turn off ambient lighting; even at sunset, there are light rays bouncing around and lighting things up. Real-time CG doesn't do bouncing light rays, of course, so you use ambience to fake this. You can script this, so you'd have a high amount of ambient light at noon, and a low amount during the evening (and very little at night).

A point light, on the other hand, emanates from a given point and lights everything in all directions around it. Therefore it has a source in 3D space, and distance matters (assuming you have Attenuate turned on). Point lights and spot lights aren't used in the terrain shader at this time, but you wouldn't want to use them for global terrain lighting anyway. You would want to use spot lights (but not point lights) for headlights, so no, you can't do headlights on terrains right now.

--Eric

 

What would cause the sun to blink in and out?
It is on a constant rotation around the surface. It seems solid on one side of the orbit and blinks in and out / disappears on the other side. Terrain still lights like it should at this point, but the graphic for the sun goes in and out.

Update to this thing, maybe this is because of what is happening but the light source doesn't effect the grass or the trees. So although my structures go dark/black and back to lit, the grass and trees remain constant on there lighting.

 

More lighting oddities:
http://www.jbwws.com/unity/faithdesertofdreams.html

Usual web controls, space to jump, W,A,S,D to move around mouse look, right click and can go full screen, etc. I have increased the light orbit speed so give best result for showing day/night cycle issues. The light should not be penetrating the building, lighting from beneath, lighint from behind on inside should only light from doorway, etc.

Easier then giving tons of screen shots.

 

Those aren't oddities; that's just how lighting in realtime 3D works. Geometry never occludes lighting unless you have a realtime shadowing system, like the one in Unity Pro. Realtime geometrically correct shadows are relatively expensive, more or less so depending on the method you use, which is why you never really saw them used in games until just a few years ago. The only other alternative is to bake shadows into lightmaps. This is a lot more common since it's much faster, but of course not very flexible.

Not sure about the sun blinking; I didn't see any of that. However, anything with a collider will block lens flares (including invisible triggers), unless it's on the Ignore Raycast layer, so keep that in mind.

--Eric

 

Ok here are my problems in order of importance:
1) directional light illuminates through static mesh's. Take a square room, place it in a scene and have a directional light outside the room point at the center of the room and orbit. Each of the walls will illuminate as it rotates around. The light should not penetrate the room unless there is an opening for the light to come in (aka window / door / etc) Note: I do own Unity Pro so if there is a way to accomplish this by a single click on a check box that I am over looking great)

2) last image posted showed the light through the mountain, if you exit the building from my web player I have linked and watch the sun, you will notice that the sun dips beneath the horizon but is still visible for a few seconds, unlike sunrise where the sun is not visible until it breaches the horizon, on sunset, it is visible quiet a bit under the surface

3) the directional light has no effect on trees and grass, meaning that they do not get lit up when the sun is up and get darker when the sun leaves the visible area, baked light won't work for me since I want to have realtime sun movement, eventually multiple sun sources. its easier to just load my web player exit the building and observe the light issues

4) I am working on an alternative to using built in skybox's and trying to figure out clouds, i want to have cloud layer below the sun source, probably won't worry about shadows on it ,but I want it to block out the sun glare at least

5) I want light sources outside to only effect outside and shine through windows and doorways, but not light based on pure direction, as it has been pointed out directional light is unforgiving, it lights anything based on its direction, but to me it should be blocked based on a ray cast. A 360 degree light is just that, it is a light source that goes out in 360 degrees from center to infinity, the real sun is a 360 degree light source, as Eric pointed out, this is currently not achievable (which I thought it was since I do have other engines that are free that somehow have accomplished this for torches and such where the light fills up a given depth and breadth of an area in a sphere range and is blocked by walls, etc)

I would be simply happy with the ability to place an EGO around the entire structure that somehow at this point blocks the directional light all together and deal with lights internally. Torque Shader Engine/Game Engine both handle indoor/outdoor lighting independently of each other, so I can't believe that it is impossible and that is just how it is in Dx and OpenGl. Everything that I am reading so far is telling me that for me to have live outdoor lighting and not have it effect indoor lighting, that it can't be done, so I have to be misreading the answers.

Sun points at center of terrain, rotates around terrain and keeps its direction pointing at center while it orbits. It is lighting the correct side of the hills and the correct side of the meshes, but it is also passing through hills and messes and lighting the opposite side which would be true based on what I am reading.

Now, the 3 tank images show that the light is limited to what it hits, and if I were to go into the buildings and have the tank pointing its light at the building only the light that comes through the window will light up the interior, I realize I am talking about point light vs directional light, and point light has range where as directional light does not. Maybe all of this is for not until such time as the other 2 light sources especially point light, works against the terrain. I need a light source that I can project at a range that extends past the orbit of the object that houses the light to the terrain, does not penetrate walls but can shine through doors and windows.

I could probably achieve a desired effect using multiple different light source types IF I could get directional light blocked from illuminating the interior of the building all together. Say add a point light to the same object that the directional light is on, give it an angle of like 180, a distance of 2000 (which is beyond the object to terrain distance). This light would help with the shine through of doors and windows, wouldn't have to light the terrain since the directional light is lighting the terrain.

How do I keep the directional light (block it somehow) from lighting the interior of the building walls? A large cube around the building that stops the directional light maybe? Any idea on this would help.

I can repeat the 'blocking' on all other buildings that I do not want directional light effecting, and allow the point light to effect, maybe that will get the desired results. Still playing around with all of the light settings until I get the desired lighting outcome.

Edit
As to Eric's point of

Then we can never use directional lights in a scene where we have buildings with interiors since a wall / objects inside the building will be effected by directional light, proof of this is just to stand in my building from the web player and watch the floor, ceiling and walls. If I didn't move the sun on a timer, had it stationary and baked my light sources, those walls / floor / ceiling would still get lit depending on the location of my sun. Which is not desired at all.


What I want is a combination of Directional + Point or just Point with Distance since Point would be the actual light I would probably want / need. I am working on getting rid of Directional and deal with changing the render settings for the ambient light, maybe this will give me the desired outcome since Point is effected by objects where as Directional really isn't.

 

Lights light everything within range unless otherwise specified. If you don't want a light to affect something, set the objects to be ignored to an ignoreLight layer, and set the light to ignore that layer.

Light can't simply be "blocked" without implementing a shadowing system.

 

Great Idea, I'll give that a try!
Thanks

Thats going to work, I have to have 2 copies of everything, a pain but will work out for what I am trying to do. 1 copy is the interior and have it on the ignoreLight layer that I created, the other copy is the exterior that I want effected by the sun as it orbits, they sit on top of each other and are on the two layers. So my exterior shell is effected by the directional light like the terrain is, and my interior is ignored by that light source. Secondary light source for the shine through effect does effect the interior but does not effect the exterior.

Double work but gets the results I am looking for. Thanks for that tip.
-Zumwalt

Edit:
never mind, point light has the same issue as directional light, it is not blocked by the mesh walls, spot light has the same issue also, all 3 light sources light all walls based on where they are and what they are pointing at. I have a secondary light source attached to the same orbiting sphere and I have it as a point light, range 2000 (which is larger than the distance from the source to the terrain), all it should do is light based on the openings, but it lights the interior based on the same rules as directional light, I have checked my settings and made sure that the point light was set to only my ignoreLight layer and no other light source was so this is what I got

1) A room with 1 opening on the terrain
2) 1 directional light ignoring my ignoreLight layer
3) 1 point light only lighting my ignoreLight Layer
4) both lights attached to a sphere that is at 1000,0,1000 to begin with and orbits from 0,1,0 at range of 1000.

Expected results, interior is not lit on room until such time that the light source is within the door range and only what light would normally come through the door would light the interior.

Actual results, interior gets lit based on location of point light and current point in orbit.

 

Shadows don't work for this either, Soft or Hard. I will compile this back up and place it on the web server so you can view what happens with shadows as you stand in the room based on this configuration.

NOTE: in the above picture the source of the light is below the terrain. It should be blocked by the building itself and the terrain.

http://www.jbwws.com/unity/faithdesertofdreams.html

Ok, Here is what is in the scene:
1) Directional light ignoring ignoreLight layer
2) Point light only lighting ignoreLight Layer with shadows (hard) enabled, angle 30, range 2000

Image shows its configuration, I just enabled hard shadows before I built it and deployed it.

Open the web player and see results as light is orbited.

 

All lights are like this, in all engines, on all graphics cards. That's just the way 3D hardware works. Lighting in the real world is complex, and realtime 3D lighting is vastly simplified for the sake of speed. In order to get "realistic"-looking results you have to use a variety of tricks.

Then you'd basically have ray-tracing, which would be very slow. This is just not feasible right now, unless or until we get realtime raytracing graphics cards.

That's what a point light is.

Only if you're doing a scale model of a solar system. In a normal scene like the one you have, modeling the sun with a point light would be wrong. A directional light simulates the actual lighting conditions of the sun on Earth (or some other planet), since the light rays are highly parallel, as I mentioned before.

No engines have light blocked by walls; realtime 3D makes no attempt to actually simulate light rays. That's just far too slow. Instead it makes a relatively simple calculation based on where lights are and where the object is, completely ignoring any other geometry. Shadows, if they exist, are added on top of this.

Light from torches and so on is handled with point lights, which of course Unity has. They are still not "blocked" by walls though, for reasons I just mentioned.

Either a) use shadows or b) have the interior be a separate model on a different layer, and have the directional light not affect that layer.

In the case of b), however, you can't automatically have light shining through windows and making light squares on inside walls. You can still fake that with spot lights and light cookies or baked lighting. This is what most games do.

If you're thinking that method sounds too complex to use with a dynamic moving sun, you're correct. Notice how nearly all games have static global lighting...there is a reason for that.

You should understand that realtime 3D is a complete and total fake--it doesn't work like the real world, and has its own rules. Objects aren't really solid, light isn't really made of rays, etc. Instead you have to use a collection of tricks to get the results you want.

--Eric

 

If all of that is true, then why does my tank game I wrote with dx9 only have the objects lit based on a point, which only lights the outside of an object and the inside black unless there is a window in which case only the lit areas bare based on the allowed cut out area? I do not see how a basic dx9 based game that I wrote circumvents these flaws without any effort?

Light from the tank headlights hits the building outside, does not penetrate the mesh to the inside, the lights on the inside of the buildings do not extrude out and light the outside etc. I am just trying to understand the logic in all this. If this behavior will always exist so that Unity's laws on lights are based on what all DX and OpenGL light laws are, then why can I produce the effect in other engines that are very simplified but I can't do the same in Unity?

I do not understand your definition of a point light and its function. The light should light the surface, not pass through and light the interior also. That totally defeats the purpose in having multiple light sources since they all have the same base flaw.

I will try to get more screen shots of the tank simulation and see if i can place another camera inside the building so I can show the light effects and screen shot them for this thread. I made no 'cookie' for the window, or did no baking, its real time lighting on a very simple not even game level dx9 library set.

Screen shots to come as soon as I get my new video card installed, got me a more powerful video card today.

Thanks for the very detailed definition. Hope what I show shots of doesn't cause too much confusion.

 

That's how the hardware works. That's how it's always worked. Lighting is just not done using simulated light rays or anything like that, because it would be very slow.

I don't see how that follows. If your point lights have a range, then they will only light objects within range. So if an object is outside the range of the point light, then it won't be lit.

And yes, all lights in all games everywhere have this "flaw". I can't comment on your tank game since I have no idea what the setup is. You can sometimes see instances in games where light is shining "through" a wall where it wouldn't do that in real life, because the designer didn't take care of it. Sometimes it's not worth it; you just let it go and hope it's not too noticeable. Everything's a compromise...realtime shadows will do what you want more or less automatically (though you still usually have to do some tweaking), but the price is that they slow everything down.

--Eric

 

The challenge is that you can't think of a directional light as the sun if it actually orbits. Since location doesn't matter, the ground doesn't block out all the light. When the "sun" passes below the horizon (being directly below) it will still light objects through the ground. Same with a point light.

Actually, what is the best way to do this, because it is kind of annoying? There does seem to be some sort of light needed to represent a sun -- that would be closer to a directional light with a source... like a crazy orthographic spotlight. I mean, I understand why the existing lights behave the way they do and why objects appear lit through the ground, but...

The best luck I've had is turning off the intensity of the "sun" light when the "sun" object's Y value drops below the ground. See here:

http://everydayrevolution.com/sun.html

I should probably lerp that value from 1 to 0 so that it fades below the horizon.

Without turning the intensity off, when the "sun" is directly below the ground (midnight) the objects are still lit from below.

Oh, and if you click that link, note that the sun is only moving that fast so that I could make sure my solar calculations are accurate over a full year of locations... and yes, my quality settings were dumb for web player. Also, note that at night things shouldn't be black... I go with an ambient dark desaturated blue to feel like night. I only made them black for this thread.

 

Yep, seems straightforward enough to me...can't think of anything better offhand.

--Eric

 

Ok, I got schooled on this by some local artists because I wasn't for sure this was all true. What I want is an Omni light (point) with dynamic shadows (part of the either the light or the object) or a Spot light with dynamic shadows. If the Omni had a strength for the fall off then have full strength at the core and fade to zero to the edge. The Omni light needs to have line of sight so does the spot light. Depending on the engine will depend on if the light sources can do this, it is not specific to the hardware and a limitation of 3d. It is a limitation of the engine itself.

 

You do. From the manual:
Point lights shine from a location equally in all directions, like a light bulb.
Spot lights shine from a point in a direction and only illuminate objects within a cone - like the headlights of a car.

This is the Attenuate and Range options for the point light. These options are also detailed in the manual.

You need to read the lights and shadows part of the manual. I don't think that the point light meets this need (I may be wrong, I just did a quick test) and the spot light might if you set a really wide angle. I think, however, that you should read the manual sections about light and shadows for more details.
[/list][/list]

 

I take it then you have not tested the theory on what the manual says vs reality. I have a link in this thread to a compiled version. Lights shine through and light the opposite wall and ignore line of site. I am all fine with people saying (read the manual) but in this case, the manual vs reality don't match. You can call it shadows all you want but shadows are static in Unity not dynamic. (hard vs soft doesn't matter)

Please WATCH the light source while standing in the room. A line of site spot light or omni light would NOT light the interior of the room unless the light source was at an angle where the door is open. This is not, however the case with Unity.

It really is one thing to tell me that I should read the manual but when I have proof in a web link where you can stand in a room and watch results, that is a totally different story.


The entire problem is that Unity does not support Line of Site for light sources. Spot, Point or Directional. Directional should not have Line of Site, Point (omni) or Spot (especially spot) should have line of site, which it does not. If just 1 of the sources had line of site it would be the solution I need.

 

The problem is you apparently haven't set it up right if you're using dynamic shadows, and you don't quite seem to understand the underlying technology here. I'm not saying that in a mean-spirited way so don't take that wrong please. The docs are correct; Unity does certainly have dynamic shadows. Check this out as one example. If you'd like, I'll set up a simple scene which shows them in action in an outdoor setting.

Whether you have dynamic shadows is up to the engine, yes. Like I said before, shadows are added on top of the usual lighting. It's not default behavior; you have to specifically turn on shadows and tweak them to look good, and it's up to each object whether it casts and/or receives shadows. Since there are no "light rays" and objects therefore can't block lights, you have to fake it somehow, and there's no one method of doing so. Unity uses shadow maps, which don't seem to work on quite as many cards as stencil shadow volumes, but have other advantages. e.g. soft shadows, being able to have shadows with transparent cutout objects, usually faster. (Though not exactly fast; you have to be careful with them.)

If we're still talking about simulating the sun, you don't want a point light or a spot light, you want a directional light. Especially if you're going to use dynamic shadows. Trust me on this.

--Eric

 

Setup, room with player in it, Spot light, 2000 range, attached to orbiting sphere, angle 179. Set color to red for emphasis. Soft shadows

http://www.jbwws.com/unity/faithdesertofdreamsspot.html

Setup, room with player in it, Point light, 2000 range, white light used, attached orbiting sphere, hard shadows

http://www.jbwws.com/unity/faithdesertofdreams.html

I am talking dynamic light, dynamic shadows, line of sight is ignored. Those two links show this plainly.

If you want I can also attach screen shots of the light settings if you like.

Forgot to mention, the outside of the building is lighted by a directional light pointing at the terrain at all times on the same orbit path. The room is not effected by the directional light AT ALL. The directinional light ignores the room. My entire point is that dynamic light sources do not take into consideration line of site.

What I mean by static vs dynamic on shadows is my interpretation of what is happening to the shadows in a line of sight situation, the shadows are placed correctly if the sun does not move (point / directional / spot) but the moment they move, the 'shadowed' out portion of the room is no longer shadowed out, other portions of the room shadow correctly IF the light source was in the room, but the light source is not in the room so the room should not be lit technically at all until the light source (spot / point) reaches line of sight to the door. I am horrible at explaining my problem it seems, and my visuals (pics) along with my web links are not explaining the issues I guess. I thought if I showed the problem using what I am told to use, then the problem would be very clear to those in the know. I guess I am clear as mud.

 

Looking at this whole thread, I think an in-depth tutorial on lighting in Unity (or in games in general), would get a lot of mileage. If there was a strong market for Unity books, I would say the topic even deserves its own book. :wink:

I haven't read it, but something like "3D Lighting: History, Concepts, and Techniques" looks like very good background reading for anyone wanting to understand lighting in the realm of computer graphics.

 

The person who explained to me the "line of sight" issue was a buddy of mine who works for Simutronics. (makers of HeroEngine). The problem here is that what I am trying to do, will bleed into other portions of my game, including game levels where the light source will bleed from level to level in the same fassion as it is bleeding into my building. I need to get the light sources with line of sight figured out before I can really move forward on this. My levels will include dynamic lighting in rooms that I do not want to bleed out of the room if the doors are shut. I want the halls to be pitch black unless the player has a spot light or omni light source (aka tourch or something else). I will be attaching light sources off of particles with a life span.

From what I am told, at the very least the program should support spot lights with line of sight limitations. What I am asking the engine to do, well the engine might not be able to handle it.

 

At least read the two pages in the Unity manual about shadows; they explain the various parameters pretty well I thought. Here's a really basic scene which has a sun "orbiting" (or the "planet" is "rotating", whatever ) and casting shadows. I'm just turning off the light when the angle > 180, but Charles is right; some kind of lerp would be nicer. It's still a good idea to turn off the sun at night even with dynamic shadows, because you can still get the "lit from below" effect (distant objects with no shadows, 1-sided polygons, etc.), not to mention it's faster.

Also included web player, in case you don't have Pro (or Unity (or a Mac)) and are incredibly bored....

--Eric

 

First, a disclaimer. I am pretty critical of almost everything, and even Unity does not escape my criticisms. However, the Unity game engine is extremely capable, and despite any flaws, bugs, or shortcomings, there is almost always a way to accomplish what you want to do. Take this as words of encouragement. If you hang in there, you will achieve your vision.

The terrain engine is a relatively new feature, something I would almost say is beta, though the UT folks may say otherwise. I would recommend against using the terrain engine unless you consider yourself an early adopter willing to accept short-term constraints.

Assuming you are not an early adopter, go with the typical mesh and textures for your level geometry. If the geometry is large, there are many tricks to address performance.

Keep in mind that all computer games are smoke and mirrors. The computer will never blindly manifest your vision of a game level without suffering great performance hits. (This will change with time and technological advances, however.) In the end, you will always need to engineer the "trick" required to bring your game to life within acceptable performance constraints.

The key to resolution for most problems is not whether the engine can do what you need to do, but whether you understand how to construct your need so the engine can implement it.

Addressing your specific need to have doors constrain lights, I would recommend putting each room in its own layer. See this URL (file:///Applications/Unity/Unity.app/Contents/Documentation/Documentation/Components/Layers.html) for more information. If you need more help, the Unity community is knowledgeable and very willing to help, as is obvious from this thread.

So, hang in there. Some things might seem difficult or impossible, but I would posit that you just need to get through the learning curve. Be persistent and you will see your vision realized.

 

Thanks Eric, your has the same bleed through problem mine has. Entire walls get lit. You do have the light coming through the door and window like I want but yours has the same problem mine has, the entire walls in the room get lit still. I seriously don't think there is a way around this currently with Unity.

Thanks, that shows it is not just my setup that has the problem. At least this shows I am not a total idiot.

 

are you talking scene view or a build? eric's web player works exactly like what you want to do. i've had odd results in scene view like lights staying on after turning them off or even deleting them all together. usually takes a relaunch to clear. or are you getting confused by ambient light? eric's webby doesn't have any bleed through here but it does look like ambient is kicked up when it's daytime.