greebo

My account will be moved on Tuesday, 27/02/2007 8:00 CET, so expect a bit of downtime on that day. Hopefully the current issues with the drivespace will be resolved till Tuesday, so that I can pull a backup from the server before they move my account.

Already done.

I downloaded your map and was able to change the patches such that they align up properly without overlap. You had them oriented head-to-tail, that's why you had to overlap them. Try dragging a single vertex around and look at the camera view which vertex you're actually changing and you'll see what I mean.

Have we already posted at Doom3World on recruiting a sound fx creator? I saw a recent thread where somebody offered his help as sound creator, but I guess he's already taken. Or is the Doom3world community rather not our main target group?

I think the arms are too massive, as Ishtvan already pointed out. I did a quick comparison with da Vinci's study: Even da Vinci's study has massive forearms, but you can see the difference at the biceps (even if you take the angle into account). I did not even measure at the same height on the template torso, so the ratio may be even more than 0.32 if you measure more towards his waist. It's only a rough comparison though, and overall I think it's not bad. The arm's length is ok, IMO.

The above book just arrived here in Austria. I ordered it from an private U.S. seller at Amazon's marketplace on Monday and 5 days later it's lying in front of my door. Even faster than the book I ordered directly from Amazon.com

I think the torso of the guy in the middle is ok, it's just his arms that seem to be a bit unproportional, IMO.

I was running into the same problem like you and I found out that the orientation in world and in texture space was different and I dragged the wrong vertices around. I will add some buttons for flipping and rotating the selected patch vertices, they will sure come in handy. edit: FlipX/FlipY buttons are available now. @New Horizon: Thanks.

It does make the S and T entries kind of obsolete, because you can drag it per mouse anyway. Perhaps it might be handy to leave the X,Y,Z coord manipulators still there for (rare) editing and diagnostic purposes. I will open the according issue on the Bugtracker.

The new Surface Dialog is feature complete and the TexTool is up and running. Do we still need the Patch Surface Inspector (Shift-S) as a dialog window or should I incorporate it into the menu as "Curve > Edit Tesselation"?

I've got news on this. The preference "Patch Subdivide Threshold" does influence how the patches are tesselated in DarkRadiant. Lowering this value (and restarting DarkRadiant) makes the patches subdivide smoother. A value of 2 yields the same result as DoomEdit, I believe: However, I don't know if this is the remedy for all inconsistencies, but at least it's a start. If everybody agrees I will make 2 the default threshold value. Performance issues in game are unlikely because this affects only the tesselation in DarkRadiant itself, not in the Doom 3 engine (unless you choose fixed tesselation, a patchDef3).

Updated my first post again.

Anyway, it won't make it in any of the near-future releases I guess. (Except the case one of us gets fed up enough with the current system... )

It's not necessary. Only focused widgets will catch keypresses in the first place. You'll have to disconnect it on destruction though.

Yeah, that's fairly easy. First step is to implement a toggle() method of the dialog that does the actual toggling. Second step is to create a command like this: GlobalEventManager.addCommand("ToggleLightInspector", <Caller>) Third step is to connect the dialog window via: GlobalEventManager().connectDialogWindow(GtkWindow* lightInspectorWidget) in the LightInspector constructor. That's it. All shortcuts that are not caught within the dialog window itself will be propagated to the "background" windows.

I get the idea of memory-saving and such, but I believe that this is not the way Radiant works, because the duplicated items can always be changed once they are duplicated (entity key/values, shaders, whatever). The memory-intensive data like model meshes and shader images shouldn't be stored in the scenegraph instances in the first place, should they? This should be the job of some sort of cache (like the recently implemented GLTextureManager) that keeps track of the "large" data junks. I'm sure that this system can be simplified a lot without the distinction of nodes and instances. Just scene::Nodes in three flavours (as you said: Root, Entities and Primitives) with a defined interface for rendering, selection and manipulation. No multi-parenting or node-sharing. (Could well be that I'm just imagining this to be more simple than it is.) (Just saw your edit) Funny, this is exactly the way I did implement the "mini-scenegraph" of the TexTool. I have a raw definition of a so-called TexToolItem with some default methods. Each TexToolItem is allocated via boost::shared_ptrs and stores its own vector of TexToolItem children (I think that's an n-tree, isn't it?). Upon selection, rendering or transformation each TexToolItem propagates the according calls down to it's children (the default methods being defined as virtual TexToolItem::transform(), so that the implementations can override it by their own methods).

Well, I guess I did not entirely understand what the difference between node and instance is, then. Is the intention of using a Stack or std::list that each instance should know its parent (even multiple parents)? Are there any scenegraph objects that have more than one parent node? Are there some school-examples of how a scenegraph should look like? I'd be keen to know, I guess I will start googling.

Sorry, what do you exactly want to have? The LightInspector being toggle-able by hitting "J"? That could easily be done.

I just wanted to drop a note here that this entire scene::Instance stuff sucks, sucks and sucks even more. (*rant*) Now there are BrushInstances and PatchInstances. That's fine with me, because they can be identified with a scene::Path (that's a delicious typedef Stack, a so-called "unique" key - as if a simple int didn't do the trick...). The problem starts with FaceInstances, because it turns out that they aren't any scene::Instances at all, they just happen to be named Instances. Hence they don't have a scene::Path and there is no possibility to check whether they are already in my list of selectables or not. Something has to be done here, but if we start to change this part of GtkRadiant, I fear that we can rather rewrite a good part of the core app... Conclusion: the TexTool will probably not be able to keep track of its selections, because of this half-assedness with FaceInstances (apart from some ugly hacks I couldn't think of another way, therefore I'll leave it at that).

Yes, that's of course a better idea. I'm not sure if it's possible, because the selectionsystem is an astonishingly winded maze of callbacks. If you select or deselect a single instance, the call passes through the RadiantSelectionSystem class several times, going in and out. Each helper class seems to be provided with a SelectionChangedCallback that points back to the RadiantSelectionSystem, sometimes this callback is even passed deeper in the "hierarchy", if that name is even appropriate. I played with the thought of re-writing it, but that won't be very wise probably, because it works after all.

Yes, I let the window catch the ESC key to make it more intuitive. I also thought about pressing ESC twice to let the "Deselect" command propagate to the main window (first ESC = deselect texture vertices, another ESC = deselect the actual brushes/patches). I was already working on that, but my first attempt failed. This is on the plate. Yes, vertex editing for brushes is impossible, although (as you already stated), a scaling would be possible. I will probably remove the corner vertices and replace them by axis-aligned scale manipulators. With rectangular faces, it would be ok to have the manipulators on each edge, but with more than four-sided faces this won't work. Agreed, this would be helpful. Don't know how hard this would be to achieve, but I'll see to it. This may be impossible, but I'll try to think of a solution. Currently, the TexTool gets notified upon selection change, but it is not possible to compare the previous selection to the current one, you just get a bunch of objects. It could be the same face as selected before or it could be a patch, you can never know. Perhaps it's possible to link the TexTool more deeply into the SelectionSystem, so it may be possible to get a grip on what exactly happened during the last selection change.

No, it's not listed in the wiki, because I intended to describe an installation without all that copying of DDLs and stuff from an existing DarkRadiant installation. If I don't find a way around it, I will fall back to the steps you just described.

That's strange. I will have to get to a "clean" computer without my build environment, so I hopefully can complete the tutorial and see what might be missing.

Try this: Take the latest release version 0.8.1 and install it somewhere in case you haven't done this yet. Then take the DLLs from this release and pack it into your install/ folder (where you checked out the SVN stuff). Does this resolve anything?

That's what I meant in the above post with "vertex merging (like Alt-M in Blender)". I'm currently working on the brush faces, if everything goes well, I'll have that in till I go to sleep. edit: updated my first post