Draggable Light Center

[Crispy]

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

[OrbWeaver]

I may be wrong about the Doom3Group thing, however I do recall a note to that effect in the comments.

[Crispy]

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.

[greebo]

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.

[OrbWeaver]

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?

[greebo]

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*

[greebo]

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.

[OrbWeaver]

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.

[New Horizon]

Wow, getting closer. Great work!

[OrbWeaver]

Yeah, and at the end of it someone will understand Instances, which I certainly don't.

[greebo]

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.

[greebo]

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.

[OrbWeaver]

Excellent, it sounds like you are almost there with this feature.

[greebo]

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.

[greebo]

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

[OrbWeaver]

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

[greebo]

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

[OrbWeaver]

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.

[greebo]

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.

[greebo]

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.

[greebo]

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?

[OrbWeaver]

It compiles and runs OK, but I can't seem to drag the light center. Is there something you need to do to activate the drag mode?

[greebo]

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.

[OrbWeaver]

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.

[greebo]

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.