Jump to content
The Dark Mod Forums

Recommended Posts

Posted

Hmm. Are you sure that lights are groups? None of the Light* classes seem to inherit from Doom3Group. I've traced through the light creation code, and as far as I can tell it just returns a single scene::Node (actually a LightNode), which contains a single Light object and a set of pointers to scene::Instance objects. Are you suggesting to make a light center class derived from scene::Instance and put it in that set? I'm probably missing something, but I can't see any other way to do it, and that doesn't sound like a good way - I had assumed that those instances were supposed to be instances of the light itself (i.e. LightInstance objects).

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

Posted

You mean this note? (light.cpp, at the top)

 

/// Doom3 special behaviour:

/// The entity behaves as a group.

 

It mentions entities that are "grouped under [the light entity]" too, but I can't figure out what "grouped under the light entity" means, as I'm quite sure it's not inheriting from Doom3Group.

 

The only occurrence of the word group in light.cpp apart from that comment block is "Doom3GroupOrigin m_funcStaticOrigin", which is the declaration of a member in the Light class. Doom3GroupOrigin is just a vector3 with some additional scene traversal stuff in it; as far as I can see it doesn't have much to do with groups, despite the name.

 

Odd.

 

I guess I'll just have to keep puzzling through the code until I find something useful. :(

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Posted

This is my progress so far: I was able to successfully add an LightCenterInstance together with the selectionTestComponents routine to the LightInstance class. This means that I the light center can be selected and highlighted.

 

I now need to add the required callbacks to the SelectionSystem so that the light center is rendered immediately and not after a forced SceneChangeNotify. This will be a bit tricky, but at least I know now what I need to do (at least I think I do). An ObservedSelectable should do the trick.

Posted
I now need to add the required callbacks to the SelectionSystem so that the light center is rendered immediately and not after a forced SceneChangeNotify. This will be a bit tricky, but at least I know now what I need to do (at least I think I do). An ObservedSelectable should do the trick.

 

How does other code deal with this, for example when you drag vertices or brush faces? Perhaps you need to add the SceneChangeNotify yourself?

Posted

If I get it right, the SelectionSystem does handle this itself. It's a network of callbacks that is constructed and at the end there is a RadiantSelectionSystem::pivotChanged() method, that should take care of this . *fingers crossed*

Posted

The first step is done: I can select the light center (at the moment at 0,0,0) and all the callbacks to the SelectionSystem are up and running. The only drawback is, that the light center has to be located within the small rectangle that represents the light origin. I will look into this.

Posted
The first step is done: I can select the light center (at the moment at 0,0,0) and all the callbacks to the SelectionSystem are up and running. The only drawback is, that the light center has to be located within the small rectangle that represents the light origin. I will look into this.

 

That's probably because that rectangle is the selection volume for the light itself.

Posted

Update: I can now select a light center located outside of the small 8x8x8 representation of the light, it highlights correctly. Next is to figure out how to set the drag callbacks correctly.

Posted

Update 2: The light center is draggable now, but I have to resolve some issues with correctly saving the entity values on change and map load.

 

EDIT: Values are saved ok, now I will have to do some extensive testing with existing maps for bugfixing. And the code has to be cleaned up as well.

 

EDIT2: Seems like the light boundaries are not rendering correctly anymore after saving the map, which is strange as I haven't touched this rendering code. As I will have to reorganise the code anyway before committing, I will do this first and then look into this bug, I don't think it will be too hard to spot.

Posted

Couldn't get much done since yesterday, but I'm through now with disentangling the light.cpp file into separate files. Next step is the documentation, which should be done rather quickly. Hopefully the bugfixing won't take me too long so that I can commit the changes this weekend.

Posted

Yet again an update: The bugs with the box rendering and the saving/loading of the light center are resolved. What remains is the correct transformation of the light center on scaling/drag-resizing the light (at the moment the light center stays where it is and happens to land outside of the light box).

Posted
What remains is the correct transformation of the light center on scaling/drag-resizing the light (at the moment the light center stays where it is and happens to land outside of the light box).

 

That's exactly what it should do. The light center is specified relative to the light origin and does not depend on the volume boundaries (of course the origin may move as a result of the resizing).

Posted

Should it really stay where it is? If yes, that's fine for me, because it would mean that the feature is finished then.

 

What about the center being placed outside of the light bounding box? Wouldn't that cause problems? (I haven't tested it in Doom3 yet.)

Posted
Should it really stay where it is? If yes, that's fine for me, because it would mean that the feature is finished then.

 

It should stay where it is relative to the origin. If the origin moves, it will need to move in world space but this will presumably be taken care of automatically just by refreshing its render position relative to the new origin.

 

What about the center being placed outside of the light bounding box? Wouldn't that cause problems? (I haven't tested it in Doom3 yet.)

 

Perfectly OK. I have used that in my own maps with DoomEdit to produce certain ambient lighting effects.

Posted

Ok, in that case the feature is implemented now. The last thing I needed to take care of is that the light center stayed unaffected by the drag plane manipulators, which is already working. :)

 

After the code is cleaned up and I did some testing together with angua the code is ready to commit, this will most probably be tomorrow.

Posted

Hmpf. Just found that the light center is not selection tested if it is positioned out of the light volume. I'll have to further investigate this, as simply extending the AABB of the light doesn't do the trick.

Posted

I think I got everything working, the draggable light center is committed now. There are some smaller things that I'm still unhappy with, like hardcoded colour definitions for the light center vertex, but nothing spectacular.

 

Orbweaver, could you check if scons compiles without complaining?

Posted

Ah, forgot to say, you have to change into Vertex mode to drag it around.

 

The Light Center is basically a component of the Light itself, so you have to switch into component mode to manipulate it. This way I could use all the existing routines of the RadiantSelectionSystem.

Posted

That makes sense, it is quite good to be able to switch on and off the dragging, especially when the default position is at 0,0,0 and hence indistinguishable from the light origin in terms of selection.

 

However this only seems to be the case if the center is within the light boundaries. If the center is outside, you can drag it any time. Could this be made more consistent, as it would confuse users if some light centers are more easily draggable than others?

 

What would also be quite nice, is if the rendering (in lighting mode) would update in realtime, rather than when you finish the drag. This works again if the center is outside the volume, but not inside.

 

Nonetheless, this is an excellent feature. Congratulations on getting it working.

Posted
However this only seems to be the case if the center is within the light boundaries. If the center is outside, you can drag it any time. Could this be made more consistent, as it would confuse users if some light centers are more easily draggable than others?

I will look into this and fix it (sometime in the evening, I have to leave now). This seems to be something I missed during testing.

 

What would also be quite nice, is if the rendering (in lighting mode) would update in realtime, rather than when you finish the drag. This works again if the center is outside the volume, but not inside.

Ah, I haven't tested this in lighting mode, as I thought that the light center didn't affect the lighting at all. I think I know where to look for this, so this should (hopefully) be easy. :)

 

Nonetheless, this is an excellent feature. Congratulations on getting it working.

Thanks, it took me quite some time. :)

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

    • Ansome

      While updating my first FM, I noticed a lot of silly things I did because I was still new to DR. For example, there was a model for a wheel that I wanted the player to be able to turn that had its origin off-center. I didn't know I could just re-export the model inside DR to fix its origin, so instead that wheel triggers a func_mover it's bound to. A silly solution in retrospect, has anyone else made somewhat janky or roundabout solutions to technical challenges in their maps? I'd love to hear about 'em!
      · 5 replies
    • datiswous

      If you use DarkRadiant in Linux while using a dark theme, a large amount of the icons are hard to see, because it's dark-color on dark background (wish DR darkmode was a little less dark). A workaround is switching to a light theme when using DR. I'm using XFCE as DE, so I made this script (mostly copied from this code), which works as a toggle. Then I set it to a keyboard shortcut. The switch works even when DR is already opened.
      current_theme=$(xfconf-query -c xfwm4 -p /general/theme) if [[ $current_theme == 'Adwaita-dark' ]]; then xfconf-query -c xsettings -p /Net/ThemeName -s 'Mint-X-Grey' xfconf-query -c xfwm4 -p /general/theme -s 'Mint-X-Grey' else xfconf-query -c xsettings -p /Net/ThemeName -s 'Adwaita-dark' xfconf-query -c xfwm4 -p /general/theme -s 'Adwaita-dark' fi This only works for the XFCE DE though.
      · 0 replies
    • datiswous

      I just bought/build a new pc, so probably less performance related whining from my part from now on..
      Sorry in advance!
      Here are the specs
      · 4 replies
    • jivo

      In case you missed it, I updated the Visible Player Hands mod to version 2.0. It now works while a weapon is selected and has a Linux version too.
      Check it out if you're interested: Visible Player Hands 2.0
      · 0 replies
    • thebigh

      Starting a playthrough of the whole Dark Mod, from oldest mission to newest. I've knocked over the first few already and about to start Living Expenses. Only ~170 missions to go!
      · 12 replies
×
×
  • Create New...