Itches, Glitches & Anything Else...

[greebo]

While I'm here - another thing that is starting to bug me. I've mentioned before about the camera speed for fine tuning and you kindly reduced the minimum to 1. Now I'm finding I am frequently switching between high speed and low speed as I am spending more time mapping. I can't imagine how people manage with one speed. Is there any way to have some sort of shortcut? Maybe two speed settings and a hot key to switch between? Or maybe better, just the one speed setting as now but slider keys like the keys that zoom in and out the grid size, to increment/decrement the camera speed.

 

Yes, this can be implemented with a switch. That's a nice feature, I would use it too. Please track it.

[Fidcal]

Great! - thanks greebo. Now on tracker.

[Komag]

Ah good, I would also love that feature.

[SneaksieDave]

Camera speed... aren't others using Ctrl-Shift-Mousedrag for fine control? Maybe I'm misunderstanding.

[OrbWeaver]

Could you have another go at the bonehoard or graveyard.map (both are on SVN)? It takes at least 7 - 10 seconds to take the "Invert Selection" to take effect in the smaller one of these two.

 

Well I tried to create a profile with the bonehoard, but I gave up waiting for it to finish (several minutes).

[greebo]

Really?

 

It doesn't give up on my end, but I assume your machine is not much older than mine. This really speaks for a loop going on in the selection system, but it should not take forever. Is it the same with graveyard.map or perhaps city_area.map? They are much smaller (~1400 primitives).

[Komag]

Camera speed... aren't others using Ctrl-Shift-Mousedrag for fine control? Maybe I'm misunderstanding.

 

Ah missed that one! I see that Ctrl-Shift-drag moves on a horizontal plane and just Ctrl-drag moves on a vertical plane. These only work when in mouse-look mode, of course. It works pretty good, nice for small fine precision

[OrbWeaver]

It doesn't give up on my end, but I assume your machine is not much older than mine. This really speaks for a loop going on in the selection system, but it should not take forever. Is it the same with graveyard.map or perhaps city_area.map? They are much smaller (~1400 primitives).

 

I just tried with graveyard.map (after I finally managed to download it -- the link between me and Spar's server is broken once again, but I found a list of open proxies to use to bypass the problem) and once again it takes a prohibitive amount of time just to Invert the empty selection.

 

I will try again using a debug build, in case the profiling instrumentation is causing the slowdown. Alternatively, it is possible that I have found an infinite loop bug.

[Crispy]

the link between me and Spar's server is broken once again, but I found a list of open proxies to use to bypass the problem

So much for the robust self-re-routing nature of the internet.

[OrbWeaver]

I will try again using a debug build, in case the profiling instrumentation is causing the slowdown. Alternatively, it is possible that I have found an infinite loop bug.

 

Nope, doesn't work in Debug either.

 

So much for the robust self-re-routing nature of the internet.

 

Indeed, I don't understand it myself. If a link is down, it should just find another one.

[greebo]

This is strange. Does it work in small maps?

[Fidcal]

SneaksieDave and Komag: Thanks so much - those controls are truly excellent both for fine control and also somewhat for rapid movement at least on an average map. Amazing flexibility. Fairly intuitive but needs practices to get really good.

[OrbWeaver]

This is strange. Does it work in small maps?

 

Yes, it works fine in a single-brush map and my testmap containing 192 imps.

[OrbWeaver]

I've rewritten the filesystem visitor code for improved performance (no "Searching" delay when populating the model list), but there is something wacky going on with parsing the resource files -- it seems that everything is read twice, so absolutely everything shows an "already defined" warning. This requires further investigation, but I wanted to get the performance code committed first.

 

EDIT: Found the problem (I think), and it may not be a DR issue: there is a file called materials/andy.mtr in BOTH pak000.pk4 and pak005.pk4 in Doom3/base. The previous code built a unique set of filenames first, before visiting them, which means that only one of these files would have been looked at. Now, the callback is used immediately without first building a unique set -- but because the callback uses the filename to open the file during the visit, the same file is opened both times (because the name lookup just returns the first matching file).

 

I think I will add back the unique set code (using std::set, not some ghastly linear search through a GSList) so that only one file will be visited. However, this will mean that definitions will be missed out if they are defined in an MTR file which has the same name as an MTR file somewhere else.

[greebo]

Supposedly this is the behaviour of Doom 3 as well? Perhaps this was implemented like this on purpose? I can't really say, as I haven't tested such a case with the game.

[OrbWeaver]

I think you are right, there are some comments about storing the archives in reverse order so that "lower" ones override "higher" ones when a file is located. I've added the std::set code and it works like before, although I haven't committed yet since I need to do some cleanup.

[greebo]

So I gather the code is working much faster now? What was causing the slowdown?

[OrbWeaver]

What was causing the slowdown?

 

There were two problems:

 

1. Traversing the VFS to build a list of files, then traversing the list of files to invoke the callback on each one takes twice as long as just calling the callback the first time round.

2. The list was actually implementing a unique set, but this was enforced by traversing the entire list each time a file was added to check that the name wasn't already present. This is O(n^2) efficiency.

 

The new code invokes the callback during the first VFS traversal, but it also has adds each file to an std::set and checks that each new file is not already in this set before invoking the callback.

[greebo]

That definitely sounds better. The list is generated during startup and can be re-used, isn't it?

[OrbWeaver]

There is no persitent list as far as I am aware, the code just visits each Archive (which may be a PK4 or a directory like ~/.doom3/darkmod) and asks each Archive to search for the matching files within itself.

 

There is still a bit of inefficiency because the VFS visitor class gets passed a filename, not a file object itself. It then opens this filename using VirtualFileSystem::openFile() or ::openTextFile(), which actually initiates a NEW search through the VFS for the named file.

 

Changing this would be quite difficult however, because the visitor class would need to be passed an object which can be opened as either text or binary depending on the requirements, which would mean merging ArchiveFile and ArchiveTextFile into a single class (which would be a good idea, but probably a lot of work). I'm also not sure how much real difference it would make to the speed.

[greebo]

I wonder why the list is not saved in memory - I believe this would significantly speed up the lookups. It probably can only get better (as usual for GtkRadiant code), but I agree that this is quite some work. That's the kind of project for a few long winter nights.

[Fidcal]

I don't know if this is a glitch or just a limitation of the way selection and filtering works or (I'm hoping) there's a way to do it I don't know of.

 

The picture below shows the west wing of my manor.

 

I surrounded it with a brush and used 'select inside'. None of the models are selected so I assume that is normal. Note the upper windows are groups of brushes and window texture while the downstairs windows are models and not selected. This itself is worrying because eventually I want to clone this entire west wing and mirror it to the form the basis of the east wing.

 

Selecting touching adds pretty well everything in the map.

 

My current task is to line up internal windows with externals downstairs so I want to hide everything but the downstairs.

 

Selecting Region XY view also does not include the downstairs windows even though they are well within the boundaries (though it does include furniture models inside) and of course, it includes the upstairs anyway. Actually, if I zoom out further then Region XY does include the lower windows but most of the manor is included too including upstairs.

 

Selecting inside then manually adding the windows then Region set from selection still excludes the windows which were part of the selection.

 

There's a select entities button but I can't see any effect.

 

OK, try the opposite way round, surround the upstairs, select all, HIDE, - this gives me a good view of just the downstairs (well, there is some upstairs furniture floating around!) and I can carry on with what I want to do.

 

The above does demonstrate to me though that trying to select one exclusive area to work on is risky if you can't be confident everything will be included.

 

And what is different about manwindow01.lwo compared to other models like furniture? Or maybe it's just their position near the boundaries? I did try surrounding with a second brush then surrounding then and select inside but no go; those elusive windows eluded me again!

 

[greebo]

I noticed that sometimes rotated models have a huge bounding box, so it might be that the stairs are not fully "within" the selection brush.

 

Select Inside should select the models too in principle, so it could be a bug. Can you save me a part of this map to your repository and track this on bugs.angua.at so that I can take a look at it? It won't be anytime soon, because I'm busy with SDK coding in my freetime, but I can see into it in my next DarkRadiant coding sweep.

[Fidcal]

Yes, OK, I was thinking of putting the whole map up in a few days anyway and it's probably best in case only part doesn't have exactly the same problem. Come to think of it I can't save part of the map without first selecting part so the same problem might affect the saved part.

[Fidcal]

Cross hairs 'spontaneously' enabled. I was texturing, mostly in full screen camera view, also used clipper and surface inspector. Went back to the grid view and saw cross hairs enabled. Went to Preferences and found it enabled (definitely not by me as it's days since I used prefs and you just can't miss noticing cross hairs.) I can't see any shortcut key or button I might have accidentally pressed. Very insignificant little glitch if it is one at all but worth mentioning.

 

Piggyback question: is there a way to remove a point set in clipper? I sometimes click again to reposition 1 instead of dragging it and finish up with point 2 where I don't want it. Sometimes I set a point 3 I don't want at all. I have to hit the QE button to clear it and start over. Anyway to just clear the last setting? Or even clear all would help as I'm often in full screen grid view so QE button hidden.