greebo

Fleshing out your fantasy is so cool...*drool* I really plan to do a week of mapping during the Christmas holidays together with angua (as we did last September), so that this map gets a huge push forward. This will also produce a lot of input for DarkRadiant, I suppose. At the moment we have the bonehoard core section (the part that most of you know, although angua changed it quite a bit in the last months), a large hall leading underground to this core, so the entrance itself is still missing. These concepts are helping a lot (thanks again, kfmccall!) (I will have to write on my thesis during the holidays as well, so I hope that won't interfere too much.) Yeah, that's funny how the same thoughts come up even with half a continent in between . Please feel free to make some suggestions, it's always good to get even more inspired.

Cool, that was quick! I must say that I like both (angua likes them too, she's looking over my shoulder), very inspiring, especially the entrance in the first concept is fitting really well with our imagination. For the actual map we would combine these two, such that the entrance is a bit less exposed to the "empty" surroundings, if you know what I mean. It should perhaps be at the end of some mini-canyon, where the rocks block the way to the left and the right, it would feel more embedded in the mountain (this would be a bit like the entrance to the Paths of the Dead in Tolkien's Lord of the Rings, I guess, although the canyon wouldn't have to be very long, around 50 meters would be quite enough). The valley can be reached from the leftovers of the temple. The second shot is pretty cool as a starting point of the mission. There could be some ruins of buildings that once had walls too, as counter-weight to the pillars. Looking great, this is very appreciated!

Am I right assuming that you installed the Catalyst Control Center from ATI? It needs the .NET Framework to run, so if you really want to get rid of this, you will need to swap your drivers as well (there should some non-CCC Drivers available from ATI). If you have an nVidia, I unfortunately don't have an idea. But you should be able to get rid of the welcome screen at startup anyways. What is it exactly that's appearing?

That really depends on many things, but in principle this should be no problem. Things to keep an eye on: Light counts: How many lights do you have in your map, and (more important) how many are shadowcasting lights? If you place them such that the light volumes don't intersect much, there shouldn't be much of a problem (roughly spoken). Models: How many models with high polycounts do you have in your rooms (and how many of them cast shadows)? Visportals: If you place visportals in your map you can tell the engine which parts of your maps should be rendered at the same time and which are invisible. If you place them wisely, you can have plenty of rooms like that. You have the global limit of 4096 entities in your map (this includes AI, models, moveables, water volumes and such). But this limit is not a problem if you ask me. Nice shot btw. It could use some more textures and more lights though, this really adds to the atmosphere.

I really have no idea, this is most probably the result of some serious ego trip... The deeper I'm digging into the brush code, the more I want to reorganise it. What the heck is the point in maintaining a file with fricking 4200 lines (see brush.h)? Regarding that interface you mentioned: perhaps I will really do this, but I think I will need some assistance when that time comes, especially when it comes to implementation details (I'm still green regarding C++ design). However, for now I'll try to get the feature completed without doing a whole rewrite, let's see how far I can get...

You mean something like this: class IBrushFace { public: virtual const char* GetShader() const = 0; virtual void SetShader(const char* name) = 0; virtual const TextureProjection& GetTexdef() const = 0; virtual void GetTexdef(TextureProjection& projection) const = 0; virtual void SetTexdef(const TextureProjection& projection) = 0; virtual void GetFlags(ContentsFlagsValue& flags) const = 0; virtual void SetFlags(const ContentsFlagsValue& flags) = 0; virtual void ShiftTexdef(float s, float t) = 0; virtual void ScaleTexdef(float s, float t) = 0; virtual void RotateTexdef(float angle) = 0; virtual void FitTexture(float s_repeat, float t_repeat) = 0; virtual bool isDetail() const = 0; virtual void setDetail(bool detail) = 0; }; This is from ibrush.h, but it's currently disabled by #if 0 compiler directives.

I have made some progress at last. After a short intermezzo with the brush_primit files, I added a method to the Patch class, which gets called on the PasteTexture command. In this method I read the scale of the texture definition and apply this very scale to the brush. Before my change it was only possible to copy the shader name to the patch; right now the scale is copied over as well. For the next step, I will have to figure out how to retrieve the shift values / texture coordinates from the brush face and apply it to the patch accordingly, which will be a little tough, I'm afraid, but it should be feasible with some projection operations.

I found two conversion functions TexMatToFakeTexCoords and FakeTexCoordsToTexMat which convert a texture matrix into what's called "fake" texture coordinates (shift, scale and rotation). I assume that the fake texture coordinates are the ones that are presented in the surface inspectors. At least I know now where to look for the actual transformations. Overall, the code organisation is a terrible mess, the classes are distributed somewhere in the brush.h / brush_primit.h / .cpp and brushmanip.cpp files. It seems to me like they were thrown into the next best place as they were created. Without Eclipse's Ctrl-H search function I would be completely lost... Maybe I will extract some of these classes into new files, if I get too sick of always having to search for the class names. edit (just saw your post): yes, the problem is indeed related to patches. I lack some basic understanding of how textures are handled in the code, so I started at the map files. As soon as I will have understood the brush code (which I will need if I want to extract texture information from the faces) I will move on to the patch texture code.

I started looking into the brushface texture code and this is what I was able to find out so far: - From messing around I found that the brush face definition in the map file can be read like this: ( -1 0 0 96.4022 ) ( ( 0.0080353 0 -0.5 ) ( 0 0.0357143 1.14286 ) ) "textures/bleh" 0 0 0 (nx ny nz d) ( (scalex scalexy offsetx) (scaley scaleyx offsety) ) "shadername" don't know with the plane normal vector and d its distance. The interesting part is the texture coordinate bit, with the offsetx,offsety being measured in multiples of the actual image width (e.g. if you apply a 256 pixel wide texture, an offsetx of 0.5 would mean that the texture is shifted by 256*0.5 = 128 pixels in the x-direction). The other four values can be used to express the texture scale and rotation. If the texture is not rotated (0°), the scalexy/scaleyx values stay zero. Maybe these values are stored in multiples of the image width as well, I have yet to find out. - It doesn't look like there is any documentation of how the texture coordinates are stored in the map files. Nor does anyone on Doom3World fully understand it (or at least no one is sharing his knowledge). I found some threads (http://www.doom3world.org/phpbb2/viewtopic.php?t=11101, http://www.doom3world.org/phpbb2/viewtopic.php?t=13639) with some links to old quake docs but that doesn't help a lot. At least I was confirmed with the values stored in image width/height multiples. - Next step will be butchering around in the codebase to find out how the map file values are translated into the values the surface inspector is showing. Maybe this is easily done with some scaling by the image dimensions, maybe there is some transformation matrix involved. The code is - as usual - undocumented, apart from some parts in the surface inspector code that have some comments from Shamus. I will post back here what I can find out, anyone with more knowledge in this matter feel free and speak up!

I don't think so. It would take some alternative callbacks to implement this, which maybe tedious, but definitely feasible. I could try to implement it, if it is a priority.

I will also take a look at the camera movement shortcuts, which seem to be hardcoded. Perhaps I can make them use the shortcuts.ini file, so that the user can use the WASD keys instead of the arrow keys to navigate the camera. If this cannot be done easily, I will come up with something else. edit: Just realised that it is already possible to define the free move shortcuts, so I guess there is nothing to do here. I will now clean up some code and see if there is anything else left to do...

Changes committed. It wasn't too hard after all, I had to add a new minSelectionCount condition and the event "Select" to the XML file, that is evaluated by the EventMapper. Check out the file input_orbweaver.xml, where I stored the settings as you suggested: ALT+Left-Click: NewBrushDrag Left-Click (nothing selected): Select Left-Click (anything selected): Manipulator SHIFT-Left-Click: Toggle Selection (as in vanilla GtkRadiant) Gtkradiant defaults are working as well of course, just leave the new event "Select" commented out.

No, I haven't switched yet, will try it out soon.

Just wanted to rename interface.xml into input.xml and sourceforge threw this "Forbidden" error, so you're not alone with that problem, it seems. I also noticed that the renamed file appears under "deleted" in the commit list and the newly named file under "added". Maybe this is the wrong way of handling it? The 403 error message is thrown immediately after Tortoise wants to add the newly named file (the old one is still there at this point), so maybe this is a conflicted situation. I deleted the old file and added the new one by hand, without the renaming stuff.

Ok, I will have a look at it and implement it if it's easy enough. I need to fix the strafe thing as well. EDIT: the strafe thing is now fixed.

I think I get the idea what you want to do. I could change the system such that if nothing is selected, the left click is interpreted as "selection", whereas if the selection count > 0, the click would be seen as "manipulate". How would you add more objects to your selection? Would you want to do it by Shift-LMB? I could add such a "SelectionCount" condition to the XML file and have it checked by the EventMapper.

It's kind of tricky to determine for the system what the user actually wants to do, hence the massloads of different button/modifier combinations in vanilla GTKRadiant. A NewBrushDrag can be activated when 0 brushes are selected, but that can be the same circumstance in a Selection drag, so how would DarkRadiant know? Something similar goes for the manipulator/selector distinguishing. I for myself will put NewBrushDrag to Alt-LMB, as in most of my mapping time I'm doing selections and manipulations, only a minimal percentage of my actions is creating new brushes (in later stages of my Bonehoard mapping I didn't create any brushes at all, mostly it's messing around with textures and grid alignments). However, feel free to suggest something, I could have a look if it's somehow possible to implement it.

Ah, I seem to have added one multiplier too much, I will fix this soon. @single-left-click: I think you have to move the NewBrushDrag to something different like Alt-LMB, because this event gets catched and is not passed to the RadiantWindowObserver. Then you can change the ordinary selector to something different. I also believe that it is not possible to set the CycleSelection to the same buttons/modifiers as ToggleSelection, but I may be wrong here. Would this make much sense to have them undistinguished?

Ok, the first implementation is committed, along with some changes and documentation here and there. The XYViews, the CamView and the RadiantWindowObserver are using the EventMapper class to retrieve their events/states. All the settings are saved in interface.xml and are quite straightforward to use. One thing I changed in comparison to the original GTKRadiant settings is the forward strafe behaviour of the camera view. I reversed the direction such that a mouse "up" movement actually moves the camera forward, as it was already suggested by SneaksieDave. Code cleanup is still to come.

Yes, this was the idea to introduce an intermediate layer who takes care of all the distinguishing. It's of course possible to change it, I tested the system with the Radiant default settings as well as with a LMB selector without any modifiers. One has to look out for double assignments of button/modifier combinations, as it may be possible, that one combination is recognised and hence catched by an "earlier" callback method and never reaches the "deeper" queries. It's perfectly safe to experiment with the settings, not everything is possible. One can also use up to five mouse buttons now (three is the default). I tested my setup with my thumb button assigned to the "Paste Texture" command, works like a charm.

Current status: The RadiantWindowObserver and the XY View are already using the new system. I already tested it with a Blender-style view drag (Alt-Shift LMB) and a Selector that's not using shift, i.e. pure LMB for selecting. I also de-coupled the NewBrushDrag feature from the selection event such that one can define anything else for a BrushDrag (like Alt-LMB drag). The GTKRadiant defaults are of course working as well. What's left is the Camera Controls (won't be too hard) and the code clean-up (there is a lot of unneeded stuff in the window observers).

I've implemented an EventWrapper class (don't know if the name is appropriate) that interprets all the incoming button/modifier combination and returns a result. All the buttons/modifier combinations are defined in the user.xml file. Currently I'm planting this system into the XY View, which is progressing well so far.

Was it related to the dummy brush stuff in the new mapdoom3 module? Edit: just saw it in the logs, info_player_starts without angle seemed to throw an exception.

Orbweaver, could you try to open a large map like askave.map or bonehoard.map? My latest build crashes after map load with a singletonmodule assertion error (still referenced at shutdown). Can you reproduce this? It works fine with DR 0.7.1.

While reorganising the selection system I found some code parts that are relevant for determining which modifier & mouse button combination is needed to perform which action. I also found some stuff in include/windowobservers.h that is related to the mouse button mapping. At the moment Radiant recognises only three buttons (with IDs 1, 2 and 3 for left, middle and right button). I did a quick check and could find out that the thumb button of my Logitech MouseMan Optical has ID=4. I use this button a lot (mainly as double click button). I will dig in some more and post my progress here, eventually I can come with some flexible system, that allows the user to assign even more mouse buttons if he wanted to (and if he knows the button ID, which is not a problem, as I already added some notify message when an "unknown" button ID is incoming). I would think of some sort of translator class that gets the mouse button IDs and keyboard modifiers as input and returns the according state. The information of what combination is translated into which state is stored in the registry. So, if the RadiantSelectionSystem wants to know how to interpret the incoming input signals, it asks this class and retrieves the according state.