Jump to content
The Dark Mod Forums

Projected Lights


Recommended Posts

I will have a look at this and post my findings here. There are quite some sections in the light entity code that have explicitly been written for the handling of projected lights, so maybe we won't have to do everything from scratch.

 

From my observations in DoomEdit, the projected light is basically a cone defined by four vectors: origin, target, left and up. The light center vector seems to be irrelevant. Only the origin vector is a position vector, all the others are measured relatively. The light radius is meaningless for a projected light and changing the value has no effect. So, a projected light can be distinguished from a point light by its missing light_radius key - the point light in turn is missing its light_target key.

 

The light target points from the origin to the center point of the cone's base area. From that point the vectors right and up define the extents of that base area. The vectors right and up are always orthogonal to the according edge of the base area, thus the base area can be twisted as well by dragging these vectors and doesn't need to be a rectangle.

 

The cone can be turned into a frustum by defining the "explicit" start and end vectors. These are measured relatively from the origin vector and describe where the cone is cut off. The start and end vectors are pointing to two points in space. The vector between those two points is the normal of the plane that actually cuts off the cone and turns it into a frustum. The start vector can be pointing "above" the tip of the cone, but this is meaningless and has no effect. On the opposite, the end vector can point "below" the base area of the cone, which stretches the light cone. In this case the light target vector just defines the direction the light is pointing and its end point is not an element of the base area anymore.

 

Next point is to investigate how DarkRadiant reacts on loading a map containing a projected light.

Link to comment
Share on other sites

DarkRadiant opens a map with a simple projected light without complaining. When selecting the light, the cone is displayed correctly, so the light is recognized as projected light.

 

The light is rendered almost correctly, which surprises me. The only drawback is that the light center is also affecting the rendering of the projected light, which it shouldn't. This is certainly connected with the value returned by the offset() method, that refers to the light center variable (this will be easy to fix).

 

The light can be rotated and everything, the drag plane operator has no effect, which is ok I think.

 

The light radius and light center keys are visible in the projected light, which is unnecessary, but perhaps this even has some advantages when turning the projected light back into a point light.

 

So what's missing?

The only way to create a projected light (at least according to my current little knowledge) is to set the key/values correctly, which should be easier.

 

The vertex operators for the light_target, light_right, light_up and light_start, light_end vectors are also missing.

 

EDIT: And the light_start / light_end vectors are ignored at the moment, this has to be implemented as well.

 

What would be the preferred way to do this? Should we implement a light inspector dialog like in DoomEdit, or should this be done via (specialised) EntityInspector controls?

Link to comment
Share on other sites

I just did some experimenting with this. You can turn a point light into a projected light by adding the light_target, light_up and light_right vectors, then deselecting and reselecting the light volume. Obviously setting these vectors manually in such a way as to obtain a meaningful result is next to impossible.

 

I think we will need two things:

 

1. A proper Light Inspector as you suggested, similar to the DoomEdit version. I was originally hoping this could be managed through the entity inspector but this would only work if there was a single boolean flag used to set a projected light, which there isn't.

2. Draggable points to adjust the target, up and right vectors. Do you think the draggable center code could be used for this fairly easily?

Link to comment
Share on other sites

1. A proper Light Inspector as you suggested, similar to the DoomEdit version. I was originally hoping this could be managed through the entity inspector but this would only work if there was a single boolean flag used to set a projected light, which there isn't

I first thought about a toggle button, but a light inspector offers much more possibilites for us, so I would vote for this way of doing it as well.

 

2. Draggable points to adjust the target, up and right vectors. Do you think the draggable center code could be used for this fairly easily?

At least the VertexInstance can be re-used for this for sure. I also know that the callback functions are already in place, so considering the knowledge I gained during the light center task, I think I can add those vertices rather easily (fingers crossed).

 

First I feared that we would need to write the render code as well, which is luckily not the case, since I'm quite naked in terms of OpenGL.

Link to comment
Share on other sites

I first thought about a toggle button, but a light inspector offers much more possibilites for us, so I would vote for this way of doing it as well.

 

Already started.

 

First I feared that we would need to write the render code as well, which is luckily not the case, since I'm quite naked in terms of OpenGL.

 

It could certainly be tidied up, there is far to much "#if defined(USE_SOMETHING_OR_OTHER)" and "#if 0" in there. We should find out which draw code is supposed to be used, and delete the rest. Also the code in light_draw() and relatives should be moved into appropriate member functions on the related object (RenderableLightRadius or whatever), but this is not a priority).

Link to comment
Share on other sites

The light target is now rendered correctly, but it seems that the projection wireframe is not calculated correctly by the Radiant code. I have a light_target of , but the cone's base area is exactly at half the height .

 

Seems like there is something rotten in the projection code, so I will look into this.

 

Another thing I believed to notice is that DR does not display the projected light without any light_radius key/val, but I maybe wrong. Have you noticed something like this, Orbweaver?

Link to comment
Share on other sites

Another thing I believed to notice is that DR does not display the projected light without any light_radius key/val, but I maybe wrong. Have you noticed something like this, Orbweaver?

 

It works OK with me if there is a target AND an up vector AND a right vector -- the light_radius can be deleted and it still renders as a projected light.

Link to comment
Share on other sites

I have rewritten the calculation of the light cone (or rather the light pyramid) vertices, nothing too elegant, but it seems to work (light_start and light_end are still ignored at the momen).

 

The light vertices (target, up and right) are also renderable now, I will commit these changes after a fresh compile and continue to work on this during the next week.

Link to comment
Share on other sites

I could manage to make the light_target vertex draggable, although it's still a bit of a hack and I will have to move some member variables around. Took me about 10 minutes including compile times, so I'm positive that this feature will be finished as soon as I find some time.

Link to comment
Share on other sites

I have rewritten the calculation of the light cone (or rather the light pyramid) vertices, nothing too elegant, but it seems to work (light_start and light_end are still ignored at the momen).

 

Do you know whether start and end are supported by Doom 3? It would obviously be a waste of time to implement these in the editor if the game doesn't support them.

Link to comment
Share on other sites

Well there are a few widgets in DoomEdit which have no effect, such as the "Brightness" slider in the Light Inspector. It is also possible that these options were introduced in GtkRadiant and do not exist at all in DoomEdit, so it is certainly worth a check.

Link to comment
Share on other sites

A cool feature for projected lights would be the ability to "track" a particular object, rather than using a manual target vector. This could either be done as a one-off configuration step (such as a button in the light inspector that allows you to autopopulate the target vector by pointing towards a named entity), or as a permanent constraint hidden in an editor key (such as "editor_drTrack" on the light object), whereby moving either light or tracked object would result in the target vector being updated in realtime.

 

Unfortunately this is not trivial to implement since there is no way of looking up an entity by name (only by traversing the scenegraph and picking out the correct one when you get to it, which is SLOW), but if the necessary infrastructure could be put in place it could potentially make projected lights much easier to use.

Link to comment
Share on other sites

The draggable target seems to work ok now, I had to add some additional calculations so that the base area vertices get transformed correctly when the target is dragged around. I needed to create a transformation matrix for the light_up and light_right vertices and now the base area stays in shape and only the direction of the pyramid's height gets changed.

 

Now I'm working on the selection test stuff, which is a bit trickier than I expected, but I'm biting my way through.

 

Haven't checked the light_start and light_end stuff yet, will do this soon.

 

Unfortunately this is not trivial to implement since there is no way of looking up an entity by name (only by traversing the scenegraph and picking out the correct one when you get to it, which is SLOW), but if the necessary infrastructure could be put in place it could potentially make projected lights much easier to use.

I believe this information could be stored in DarkRadiant-specific entity keyvalues, and the nodes would get connected upon map load. This way we would have to do the lookup once and beyond this point the nodes would "communicate" to each other on their own that their state has been changed. A good amount of validity checks would have to be done when connecting the entities on map load but it should be feasible.

 

However, this is certainly a feature for post-1.0 releases IMO.

Link to comment
Share on other sites

Haven't checked the light_start and light_end stuff yet, will do this soon.

 

I just tried it and they work. I set light_start and light_end vectors (in Doom Edit) which were rendered correctly in Doom3.

Link to comment
Share on other sites

I believe this information could be stored in DarkRadiant-specific entity keyvalues, and the nodes would get connected upon map load. This way we would have to do the lookup once and beyond this point the nodes would "communicate" to each other on their own that their state has been changed. A good amount of validity checks would have to be done when connecting the entities on map load but it should be feasible.

 

That is certainly one way to do it. If Entity objects can be set as Observers of other Entity objects, then this mutual relationship could be set up by parsing the keyvalues, whereupon each entity would become aware of any changes made to the others.

 

 

Calculating the vector is easy, it is a simple subtraction. The complex part is setting up the aformentioned observer relationship to ensure that the tracking is always maintained.

 

I just tried it and they work. I set light_start and light_end vectors (in Doom Edit) which were rendered correctly in Doom3.

 

Interesting, I never knew this feature existed. I wonder if projected lights take the falloff into account. It is possible that some changes may need to be made to the renderer, depending on how much support already exists for projected lights.

Link to comment
Share on other sites

Sorry for the late update, I haven't had much time except for lunch breaks and during the breakfast :).

 

The light frustum is now rendered correctly (including light_start & light_end), although I will have to do some testing in the near future.

 

Next thing is to setup the callbacks and update routines, so that the rendered frustum is updated while dragging. I believe that the entire feature can be finished till sunday.

Link to comment
Share on other sites

Speaking of the light inspector (I haven't synced up with SVN while working on the projection stuff). Could you add the light_start / light_end vectors as well, ideally with a separate checkbox like DoomEdit does?

Link to comment
Share on other sites

Speaking of the light inspector (I haven't synced up with SVN while working on the projection stuff). Could you add the light_start / light_end vectors as well, ideally with a separate checkbox like DoomEdit does?

 

Yes, I will do that. I also need to add the options (No shadow/diffuse/specular).

Link to comment
Share on other sites

Good news so far, I got all five vertices to be draggable. Now I'm ironing out some bugs while transforming the vertices and I need to make sure that the vertex drag also affects the lighting rendering in real-time.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...