 |
I think such an operation is possible through the "Select Complete Tall" feature, isn't it? You drag out a brush, then hit Select Complete Tall, which removes the brush and selects everything that is completely within its bounds. Not sure how it acts with light radii extending that box. |
 |
There are 2 options, "select complete tall" and "select touching", which both have issues. "Select complete tall" is confined to 2 axes, not 3, so one axis will be infinitely selected. "Select touching" is not precise, because if the brush used for selection is even only flush with something else, those 'external' objects will also be selected. A proper coord-based function would allow for very precise selections for all axes. |
|
|
Ok, do you think it's worth adding an option analogous to Select Complete Tall, like "Select within Brush Bounds"? Or should it rather be a script method / console command / dialog? |
|
|
I will say - whatever is easiest for you. I think it will be possible to script automation for either. |
|
|
Revisiting this, have you tried using the "Select Inside" command? You have to drag out a brush, "Select Inside" will remove the brush and select everything that is fully inside the brush bounds. Is this working for you, also for your scripting purposes? |
|
|
'Select Inside' has essentially the same issue as 'Select Touching' - it will select external objects that are flush against the bounds of the brush used for the selection. This could be overcome by making the brush smaller by 0.125 units, but that's not an ideal solution, hence the request. Select complete tall = does not select objects which are flush against the selection. Select touching = selects external objects which are flush against the selection. Select inside = same as "select touching". What we really need is mathematically precise selection, especially because we're also dealing with extremely fine brush details. |
|
|
I see. Can you whip up a small test scene with a setup you'd like to have supported? That would be helpful. |
|
|
Here's a mockup, if that's what you were asking?:- https://www.violae.net/temp/DRselectcoords.gif |
|
|
I've been hoping for a small .map file, actually. Which contains a few elements and a brush that you would like to use as selection bounds. Especially those cases you described as "flush against the selection", it'd be useful to have such examples in that map, then I can use that one to test my code. |
|
|
Something like this?:- https://www.violae.net/temp/coordtest.map |
|
|
Yes, thanks. That is useful. So I assume the brushes which have their faces in the same plane as that one large brush should not be selected. The "is the candidate inside" part of the selection test should only succeed if the brush is really within the selector brush (< operator) instead of operator <=. |
|
|
In the case of this test map, if we are to select exactly within the ranges of -64 to 64 (all axes), it would be exactly 31 brushes. There are tiny 0.125-unit brushes in there that would either be incorrectly excluded internally or included externally from these bounds. I hope that clears it up. Sorry, I'm not a programmer so I just explain it the best I can. |
|
|
I've added a separate command "SelectFullyInside" (failed to come up with a better name), it's in the Edit menu right where the others are. New in this build is the ability to pass arguments to the Select* commands in the console, so you can define the bounds used for these commands, like this: SelectFullyInside "-64 -64 -64" "64 64 64" I haven't added a dialog so far, not sure if you really need one? On the testmap you sent me: when using this new command on this test scenario, nothing will be selected, as no brush is fully within the -64 -64 -64 to 64 64 64 bounds, at least that's what I could figure out. Can you confirm that this is correct? There will be a portable package available shortly in the artifacts of the build run: https://github.com/codereader/DarkRadiant/runs/2813617745 |
|
|
This shouldn't be correct. Here's some code identical to the big middle brush in the coordtest.map:- _____________________________________ brushDef3 { ( 0 0 1 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.5 ) ) "_emptyname" ( 0 1 0 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.4999999702 ) ) "_emptyname" ( 1 0 0 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.4999999702 ) ) "_emptyname" ( 0 0 -1 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.5 ) ) "_emptyname" ( 0 -1 0 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.5 ) ) "_emptyname" ( -1 0 0 -64 ) ( ( 0.0078125 0 0.5 ) ( 0 0.0078125 0.4999999702 ) ) "_emptyname" } _____________________________________ So the numbers you posted should be correct and select this brush, but it depends what axes is considered the negative? The math confuses me. If to go from north/west/up to south/east/down, then the coords are actually "-64 64 64" to "64 -64 -64", if that has any meaning at all... |
|
|
The brushDef you posted is indeed a 128x128x128 brush centered at the origin, it's bounds are from "-64 -64 -64" to "64 64 64". A brush with the exact same size should not be able to select this object using SelectFullyInside, but Select Inside will select it. It seems I'm not fully getting your request, so I re-read your comments above. I have questions about this one: >> 'Select Inside' has essentially the same issue as 'Select Touching' - it will select external objects that are flush against the bounds of the brush used for the selection. But that's not what I see. If I create two cubes next to each other (touching at one face), and use one of them for "Select Inside", the touching brush will not be selected. |
|
|
I checked it again and you're right, it seems I made a huge mistake - but that's a good thing! It means precise selections were possible all along. Still, a way to do this via a dialog or the console would be easier to automate using something like AutoHotkey or similar software. Depending on how much of your time that would take. Keep in mind, I set all of these requests to low priority tweaks, so, don't feel like you need to spend so much time on it or get it into this particular version. |
|
|
Ok, thanks for the confirmation. The build here https://github.com/codereader/DarkRadiant/actions/runs/933147540 contains a change to the commands, so you can indeed call the selection commands with two vector arguments, like I described above. It's possible to launch commands through Python scripts too, if the console is not flexible enough. Console: SelectInside "-64 -64 -64" "64 64 64" Python: GlobalCommandSystem.execute('SelectInside "-64 -64 -64" "64 64 64"') # mind the single and double quotes Can you give this a shot? |
|
|
Eheh, forgive me but I have no idea what to do with this GitHub page... Do you have a direct link to a build? |
|
|
Oops, just turns out I had to sign in! Nevermind! |
|
|
It works great. My only gripe is now with the console view itself. The input field is not active when it's opened. I can work around this but only if I know the exact location of the field on the screen. Being about to TAB around different elements in different windows is pretty important to automation. |
|
|
You mean the entry box is not focused when the Console tab is activated? |
|
|
Yes and I hate to sound too fussy. If I can get every mapper to full-screen the console before doing automated processes, then I can at least TAB into the input field. So it's not a huge deal, I'll leave it up to you if it's easy to fix or not. Otherwise, great work! |
|
|
I added a quick fix to propagate the focus to the command entry box. If the build is succeeding, you should find the artifact soon here, to try it out: https://github.com/codereader/DarkRadiant/actions/runs/936051677 And sorry, I wasn't aware that you had to sign in to download anything, obviously I've been logged in all the time. |
|
|
Didn't work, but honestly, don't worry about it too much. This is really only for us to do mass automated exports of "sectors" of maps. If we need to make the console fullscreen before doing this, and just click+TAB, then everything will work just fine. We're already very happy! :D |
|
|
Ok, fine by me. :) I'll set this to resolved then. |
- Anonymous
