Bugs with light entities with a model

[Tels]

There are two bugs (at least):

 

* the light is shown in the editor at the origin of the model, not taking "light_center" into account

* the model loses its rotation upon reloading the map. That is, it is shown unrotated in the editor, while it is correctly rotated in game.

 

Tracked here:

 

http://bugs.angua.at/view.php?id=2097

 

and

 

http://bugs.angua.at/view.php?id=2098

[greebo]

* the light is shown in the editor at the origin of the model, not taking "light_center" into account

Cannot reproduce that in the most recent SVN build. When loading the map in DarkRadiant and switching to "Lighting" mode, the light emission is clearly centered at the point where the light_center vertex is. You can drag the light_center around in vertex mode and see how the light will follow.

 

Looking at atdm_streetlamp_spot_lit_1 it's easy to see that the light is not emitted from the 0 0 0 origin, otherwise the floor would hardly be lit.

 

edit:

 

* the model loses its rotation upon reloading the map. That is, it is shown unrotated in the editor, while it is correctly rotated in game.

I can confirm that. Interestingly the rotation is immediately correct as soon as the light is altered in some way (e.g. light_center vertex is dragged), the model snaps into the correct rotation at once. I guess this is easy to fix.

[Tels]

Cannot reproduce that in the most recent SVN build. When loading the map in DarkRadiant and switching to "Lighting" mode, the light emission is clearly centered at the point where the light_center vertex is. You can drag the light_center around in vertex mode and see how the light will follow.

 

Looking at atdm_streetlamp_spot_lit_1 it's easy to see that the light is not emitted from the 0 0 0 origin, otherwise the floor would hardly be lit.

 

edit:

 

No, what I mean is that the "light pyramid" (or whatever that thing is called" is at 0 0 0, e.g. it looks (without lighting mode) in the editor that the light is at "0 0 0". That pyramid is also used as the center of the "light radius" indicator.

 

That means it is hard to adjust the light_center in the editor, because you do it "blind". I guess one could use the lighting mode or the small red rectangle I see in your screenshot, but still, the light_radius is drawn at the incorrect place, thus you cannot see how far the light really reaches.

 

Does that make it more clear and shed some light on this issue?

 

 

I can confirm that. Interestingly the rotation is immediately correct as soon as the light is altered in some way (e.g. light_center vertex is dragged), the model snaps into the correct rotation at once. I guess this is easy to fix.

 

Already saw the fix, neat

[greebo]

No, what I mean is that the "light pyramid" (or whatever that thing is called" is at 0 0 0, e.g. it looks (without lighting mode) in the editor that the light is at "0 0 0". That pyramid is also used as the center of the "light radius" indicator.

 

That means it is hard to adjust the light_center in the editor, because you do it "blind". I guess one could use the lighting mode or the small red rectangle I see in your screenshot, but still, the light_radius is drawn at the incorrect place, thus you cannot see how far the light really reaches.

Huh, "blind"? The obvious solution is to switch to lighting mode and to drag the light_center vertex around. The light volume lines are indeed correct, as the volume in-game is the same as in the editor:

 

 

This can be seen by switching on r_showLights 2. I reduced the height of the volume in the editor to produce that screenshot, but the light_center is still the at the same 0 0 100 coords. You can see that the lighting does not reach beyond the volume, even though it should when you add the light_origin+light_center+light_radius vectors. The wall above the light volume is unlit.

 

And the pyramid is handled the same in the D3 engine, just switch on editLights and see where the boxes are drawn, they are located at the light's 0 0 0 origin.

[Tels]

Huh, "blind"? The obvious solution is to switch to lighting mode and to drag the light_center vertex around. The light volume lines are indeed correct, as the volume in-game is the same as in the editor:

 

 

This can be seen by switching on r_showLights 2. I reduced the height of the volume in the editor to produce that screenshot, but the light_center is still the at the same 0 0 100 coords. You can see that the lighting does not reach beyond the volume, even though it should when you add the light_origin+light_center+light_radius vectors. The wall above the light volume is unlit.

 

That is certainly good news, but I cannot use the lighting mode on my laptop as it is too slow (crappy internal intel "graphic card" .

 

And on my 64bit Ubuntu PC it looks like this:

 

(That might be because of Linux, or because I have still to use 0.10.0 because I cannot compile a newer DR for 64bit here and the 32bit compiled version from my laptop does not run here):

 

 

After dragging the origin around:

 

 

And still, it is misleading if you see the lighting pyramid and bounds in the wireframe and they do not match what the real light volume is.

 

And the pyramid is handled the same in the D3 engine, just switch on editLights and see where the boxes are drawn, they are located at the light's 0 0 0 origin.

 

I am sure one cannot use "editLights" under linux and as I do not have windows, this is not an option for me

[Tels]

To re-iterate what I am trying to do:

 

I have an entity which is a light with a model. The model has somewhere the origin, and the light center is somehow offset from that origin. The quest before me now is to find that offset, in a fast and efficient manner

 

So I create the combo entity, and add "light_origin" to the entity and add some random numbers.

 

Then I need to find out if these numbers are correct. Currently:

 

* editLights doesn't work on linux

* r_showLights 2 (which is neat!) does show the light volume, but it doesn't give an indication of the center, so the light origin might still be 2 units off to the side

* the editor draws the light bounds and light pyramid in wireframe at the wrong place, so I cannot use this.

* editor in lighting mode doesn't work correctly here.

 

The last option, which I think could work, is using the "vertex" of the light origin. I overlooked that small red thing

 

Before I used the following:

 

* draw a brush in the editor, use its measurement numbers to figure out the light offset, then manually confirm it in D3. (However, D3 restarts and map loading are quite costly).

 

In any event, even if you don't change this, I found a workaround. But still I would like to see the bounds in wireframe reflect the real light bounds, not some useless thing centered around 0 0 0.

[greebo]

And still, it is misleading if you see the lighting pyramid and bounds in the wireframe and they do not match what the real light volume is.

Why is it not matching? The wireframe of the light in the editor is the same as what r_showLights 2 is showing me in-game. (Only origin + light_radius determine the volume.)

 

I am sure one cannot use "editLights" under linux and as I do not have windows, this is not an option for me

I didn't say you should use that, it's just to show that the engine still locates light "edit boxes" at their origin, as does DarkRadiant.

 

To re-iterate what I am trying to do:

I have an entity which is a light with a model. The model has somewhere the origin, and the light center is somehow offset from that origin. The quest before me now is to find that offset, in a fast and efficient manner

Just drag the light_center vertex where you want it to be! Switch to Vertex Editing mode (V) and drag the little green vertex around. Doesn't this work?

 

In any event, even if you don't change this, I found a workaround. But still I would like to see the bounds in wireframe reflect the real light bounds, not some useless thing centered around 0 0 0.

The light volume is centered around the origin. Unless you can prove that the engine is doing it otherwise, I don't see a reason to change the editor's behaviour.

[Tels]

Why is it not matching? The wireframe of the light in the editor is the same as what r_showLights 2 is showing me in-game. (Only origin + light_radius determine the volume.)

 

That means that although I can move the "light_center", the light volume stays the same, and thus very high values in the light center would mean the light gets cut off at the volume boundary? Eeek.

 

I was under the impression it also shifts the light volume around, sorry for not understanding this earlier.

 

I didn't say you should use that, it's just to show that the engine still locates light "edit boxes" at their origin, as does DarkRadiant.

 

 

Just drag the light_center vertex where you want it to be! Switch to Vertex Editing mode (V) and drag the little green vertex around. Doesn't this work?

 

The light volume is centered around the origin. Unless you can prove that the engine is doing it otherwise, I don't see a reason to change the editor's behaviour.

 

That means in extreme cases we would need to add a "model_origin" spawnarg. That way the light_center (more like "light_offset") can be left at "0 0 0", and thus the volume stays there, while the model gets shifted around?

[rebb]

That means that although I can move the "light_center", the light volume stays the same, and thus very high values in the light center would mean the light gets cut off at the volume boundary? Eeek.

 

Afaik the Engine uses the "light-center" for the shading and shadow-volume creation, and the light-volume itself mainly provides the light-related texture projections. That means you can for example create a fake spotlight using a standard light, by moving the light-center further away ( it can be outside the actual light-volume ).

[greebo]

That means in extreme cases we would need to add a "model_origin" spawnarg. That way the light_center (more like "light_offset") can be left at "0 0 0", and thus the volume stays there, while the model gets shifted around?

Not sure if we have control over that, that might be contained in closed source. Also not sure if there is really much need for that, when other workarounds exist (like manually placing lights or def-attaching them).

[Tels]

Not sure if we have control over that, that might be contained in closed source. Also not sure if there is really much need for that, when other workarounds exist (like manually placing lights or def-attaching them).

 

Yeah, that is true. I just wanted to avoid the "def_attach" because it means 2 entities instead of 1, which wastes memory and loading/saving time and also a very tiny amount of runtime resources.

[Tels]

Afaik the Engine uses the "light-center" for the shading and shadow-volume creation, and the light-volume itself mainly provides the light-related texture projections. That means you can for example create a fake spotlight using a standard light, by moving the light-center further away ( it can be outside the actual light-volume ).

 

What a mess!

[rebb]

What a mess!

 

I'd call it "pretty flexible" .