greebo

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

Hm, no, I haven't checked this in Doom3 yet, but I should certainly do this. How likely is it for a DoomEdit feature being not supported by the game engine?

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.

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.

Ok, there was something else wrong with my light then.

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?

Ok, so my task is to add the draggable vertices, and you create the light inspector?

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

I'm pretty sure that we will need (smaller) upgradepaths in the future for importing user defined things like "Show Size Info" and so on, unless the positions of the settings within the xml are not changed in any way. In that case it's possible to leave the user.xml alone. At the moment some registry structures are not quite done, but they should be "stable" at the time DR 1.0 is ready for release. Beyond this point, we probably have defined every possible colour in the xml files and all the other things have settled in - then we could do away with the upgrade paths. I just have to take care of some smaller logistics, i.e. which part of the user tree gets saved into the custom user.xml and which part not. Which will also take some restructuring, I'm afraid. The question is, how important is it for us to safely upgrade pre-1.0 Darkradiant releases. If the priority is low, we could now mess around with the structure until it fits our needs, but the users may have to delete their user.xml on upgrading (or DR would delete it on upgrading). (I hope my post makes sense...) At least I can promise that I will look into it and take care that, by the time 1.0 is released, everything is in order.

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?

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.

I split the user.xml file into parts: the default colourschemes went into colours.xml and the upgradepaths into another xml file. This should at least make maintaining of the files a bit easier. Memo to ourselves: We have to increase the version tag in the user.xml before we release the next version, otherwise the upgrade won't be triggered.

The changes to the light center handling are committed. I also made the colours of the light center customisable. @crispy: Thanks!

Just added three new colours for the light center, and the upgrade paths are growing already, so I will have to come up with something to make the upgrading a bit easier. I think this will be the next thing after the light center, but should hopefully be done this weekend. edit: Another possiblity would be to have the light center inherit the colours from the patch vertices, but somehow I would prefer that being customisable.

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. 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. Thanks, it took me quite some time.

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.

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?

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.

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.

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

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

Personally, I can understand the request for such a feature as I know from my own experience how different the mod can appear to "outside people". The public fora with their relatively low post counts definitely don't reflect the actual mod activity very well and it may appear that there is not much going on (which is NOT the case in any way, believe me). The mod is a bit like an ant hill or a beehive in that respect. Just look at the global post count of the forum to get an idea. Basically, I believe I could implement such a PHP/MySQL-based webapp in a reasonable time, if the team really agrees on such a feature, that wouldn't be much of a problem. BUT I am with Springheel here: such a list needs quite some dedication to stay up to date, and this may backfire and leave an even worse impression if the list is chronically outdated. I'd happily offer my help for keeping the list up to date, but that will not be possible for me all the time, as I can't keep track of every team member's progress. Perhaps we could add a single wiki page with write access for team-members only?

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.

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.

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.