Jump to content
The Dark Mod Forums

Projected Lights


Recommended Posts

Files are being committed as I type. All of the light_* vectors are draggable according to the light type (point/projected) in vertex editing mode.

 

The lighting render mode does work (things get updated in real time), but not fully as intended. The direction of the projected light is ok, but the intensity and the affected area are not correct. This would have to be fixed in the future, but I haven't yet looked into the GL rendering stuff. I also noticed that the original GTKRadiant code was NOT handling projected lights correctly, inspite of what I wrote above, especially the rendering shows weird behaviour. Just compare the results with DoomEdit to get an idea.

 

We will need some testing as soon as the light inspector is fully functional, so that the key/values are set correctly on light type change and so on.

 

Note that I've yet again changed the colour definitions of the light vertices, so maybe you need to delete your local user.xml. This only affects us SVN people, for the actual release the upgradepath is already in place.

 

The code also could do with some tidying but for now that should be ok.

 

Let the bugfixing begin!

Link to comment
Share on other sites

Perfect. Don't worry about the renderer, I am sure that will need some fixing up in order to get it to work with projected lights.

 

You can get some pretty bizarre behaviour if you move the light_start and light_end vertices around, including an hour-glass shaped light if you move it the wrong side of the origin. I would be tempted to leave this as "use at your own risk" given how frequently I imagine this feature is employed, however if it would be relatively easy to constrain these vertices to only move along the line connecting the origin with the target, this might be helpful.

Link to comment
Share on other sites

Yes, I encountered this hourglass bug as well and I already have something in mind to fix it. This will be committed soon :).

 

The light_start and light_end positioned off the line between origin and target are perfectly valid, so we should leave this as it is.

Link to comment
Share on other sites

I didn't go as far as to create a map. I just created a default projected light via the Light Inspector, added a light_start key manually and set it to <0, 0, -128>, entered Vertex mode and tried to drag it.

 

It immediately snapped back to the light origin and refused to move from there.

Link to comment
Share on other sites

Ah, you didn't create a light_end, did you? The test relies upon the light_end to be set as well, as the normal vector is collinear to light_start - light_end.

 

I just checked in DoomEdit: The light_end vector is assumed to be if unset. So the light_start can also be positioned "below" the light_end, and the light is still rendered correctly.

 

I will go and try to handle such a situation, I will just finish my current work (make the light components snappable).

Link to comment
Share on other sites

The following changes are committed:

 

- Light vertices can now be snapped to the grid.

This applies to vertex selection mode only. If any vertices are selected, these are snapped to the grid. If none are selected, ALL are snapped, so that the user doesn't have to selected each of them.

 

-light_start change triggers light_end changes and vice versa

If one types in a value for light_start, the light_end is automatically added as well (unless there is already one set). There is also some rudimentary validity check in there.

 

- Validity check for light_start/light_end:

This is still not perfectly fool-proof, but it should work. After a drag operation, the LightInstance checks if the light_start is "below" the light_end and swaps them if this is the case. I couldn't figure out any benefit from light_start being below the light_end vertex, as the light is still "coming" from the light_origin (I first suspected that the light direction was reversed too, but this is not the case in Doom).

 

The case light_start == light_end is catched and reverted to default values (light_start to the origin, light_end to light_target).

 

The light_start dragging should now be correctly constrained, although not all situations are catched immediately.

 

It's still possible to type in some senseless values for light_start and light_end (and all the others as well, to be precise), but I will leave that to the mappers responsibility.

Link to comment
Share on other sites

Seems to work.

 

I think the whole idea of having start and end vectors is stupid -- they should be scalar values between 0.0 (the light origin) and 1.0 (the light_target vector), but of course we are stuck with what the game requires.

Link to comment
Share on other sites

Agreed. I think there will appear even more issues with the vertex handling as soon as the beta mappers get their hands on this feature. For now it should suffice.

 

EDIT: Is the light inspector design already finished or are you still changing the layout? (The colour selector is huge, I would rather move it the the bottom left corner.)

Link to comment
Share on other sites

Agreed. I think there will appear even more issues with the vertex handling as soon as the beta mappers get their hands on this feature. For now it should suffice.

 

Possibly, although I'm assuming that not many people will use this feature anyway. I don't think I ever used a projected light, and even when you do (for projected shadows etc) I cannot imagine that the start and end are that important when you can just set the target vector to whatever you want.

 

EDIT: Is the light inspector design already finished or are you still changing the layout? (The colour selector is huge, I would rather move it the the bottom left corner.)

 

I am still changing the layout, in particular I have to add the start and end widgets. I put the colour selector on the right because it logically goes with the texture selection, however I can put it inside an HBox to shrink it to a normal size rather than having it stretched out across the pane.

 

One thing I am wondering - do you think the entry boxes for vectors are even necessary? I cannot see many mappers wanting to type in vectors manually when they can just drag the light to whatever shape they want, and if they DID need precise values they could easily use the Entity Inspector for this. Perhaps we should limit the dialog to just selecting projected/pointlight with default parameters (and an option to enable the start/end properties) and let the dragging take care of the rest.

Link to comment
Share on other sites

Possibly, although I'm assuming that not many people will use this feature anyway. I don't think I ever used a projected light, and even when you do (for projected shadows etc) I cannot imagine that the start and end are that important when you can just set the target vector to whatever you want.

I always think of Cragscleft with its lamps that are hanging from the ceiling, which would be a perfect excuse for a projected light. Or a searching lamp on the top of a prison tower (moving like Sauron's eye to search for prisoners). Oh my, I must get to mapping someday... :rolleyes:

 

I am still changing the layout, in particular I have to add the start and end widgets. I put the colour selector on the right because it logically goes with the texture selection, however I can put it inside an HBox to shrink it to a normal size rather than having it stretched out across the pane.

Please do think of a checkbox to remove both light_start and light_end at the same time. The way I've implemented the automatic adding of light_end when a light_start is typed in (and vice versa), I found that it is impossible to remove both keys, because they get re-added each time you delete one of them. This could easily be handled by the light inspector just by ticking off the according checkbox.

One thing I am wondering - do you think the entry boxes for vectors are even necessary? I cannot see many mappers wanting to type in vectors manually when they can just drag the light to whatever shape they want, and if they DID need precise values they could easily use the Entity Inspector for this. Perhaps we should limit the dialog to just selecting projected/pointlight with default parameters (and an option to enable the start/end properties) and let the dragging take care of the rest.

I would leave them, they don't hurt either IMO. Perhaps they will come in handy when additional functionality is added to the light inspector in the future, so that the number changes are visible in real-time.

 

However, if they cause a lot of work for you, I'm all for dropping these text fields.

Link to comment
Share on other sites

Please do think of a checkbox to remove both light_start and light_end at the same time. The way I've implemented the automatic adding of light_end when a light_start is typed in (and vice versa), I found that it is impossible to remove both keys, because they get re-added each time you delete one of them. This could easily be handled by the light inspector just by ticking off the according checkbox.

 

It is not actually possible to remove both keys at the same time, even if I add a checkbox (which I do plan to), it will still be necessary to remove the keys in two steps (by calling Entity::setKeyValue() each time), and on each occasion the key-changed signal will be fired immediately.

 

I'm not desperately keen on adding other keys automagically to be honest, although I appreciate the problem it is intended to solve in this case. Key modifications should be independent of each other, even if it means the object temporarily enters an "undefined" state. Could you not assume that if light_start is unset, the start plane is at the origin whereas if light_end is not set, the end plane is at light_target?

 

However, if they cause a lot of work for you, I'm all for dropping these text fields.

 

They don't create much work, but they do obviously take up space and I am going to have to validate them in some way (or possibly convert them into X, Y, Z spinboxes).

Link to comment
Share on other sites

I'm not desperately keen on adding other keys automagically to be honest, although I appreciate the problem it is intended to solve in this case. Key modifications should be independent of each other, even if it means the object temporarily enters an "undefined" state. Could you not assume that if light_start is unset, the start plane is at the origin whereas if light_end is not set, the end plane is at light_target?

Ok, thinking about this the second time, it is better to leave this to the user. The changes are already committed.

Link to comment
Share on other sites

I think I'm going to scrap the entry boxes, they clutter the dialog (and the code), don't line up properly, and are probably not going to be used anyway.

 

I will try having just the light-type buttons, and a checkbox to enable/disable the start and end keys for projected lights. Perhaps there should also be a checkbox for light_center on pointlights, although it probably suffices just to add the key with a default of 0,0,0.

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...