Re: [Adonthell-devel] Mapedit filtering

[Kai Sterker]

On Thu, Jun 2, 2011 at 2:11 PM, Kai Sterker <address@hidden> wrote:

I wasn't able to do much the last week, but I finally go around and
updated the modeller GUI for the connectors and other meta data. See
attached shots from within the gui builder to get a first impression.

Basically, when you press the "Add Connector" button on the main gui
meta-data tab, a dialog will open with a list of available connectors.
I figured that for consistency and simplicity, it would be best to
have on global list of connectors to chose from, and have a fixed size
for each connector. I also figured we'd need two sizes, on if the
connector is used on left or right side and one when used on front or
back side. The dialog allows to add new connectors and also to change
size of existing connectors. All defined connectors would be stored in
a single data file, probably inside the model directory.

Once a connector has been added to the list in the meta-data section,
the face where it should be attached and its position can be updated
directly in the list. There'll be a drop down for the four sides and
the position can be either entered directly or altered by dragging the
connector with the mouse inside the view.

All that logic I'll have to implement next. It's not as much as it
sounds, but as always with gui stuff, it's fairly tedious work without
any challenge. In other words, boring. So might take a few days to get
all of it wrapped up.

Anyway, there's still time for suggestions and last minute changes ...

Kai


> On Wed, Jun 1, 2011 at 11:44 PM, James Nash <address@hidden> wrote:
>
> In general, I like your idea quite well, but it appears quite
> difficult to implement. I had hoped for something that fits quite well
> into the existing framework. So let me start by explaining what is
> currently there, and then think about how something like your idea
> could be added on top of it without a year of coding :-).
>
> There are two ways to pick mapobjects for placing on the map:
>
> 1. Click on an object in the mapview.
> 2. Click on an object in the entity list.
>
> Once picked, you can place that object down as often as you want,
> unless you release it by right clicking or pressing ESC.
>
> The problem is that objects not present on the map or at the current
> location can only be selected from the entity list. And that contains
> all available mapobjects. Thus, the idea is to filter that list in
> some fashion.
>
>
> Placing objects itself is aided by a dynamic grid. This works very
> well for objects of the same size (or multiples of that size), but
> requires manual adjustment for objects of different sizes. Like a
> straight wall and a corner part.
>
> The idea here is, that in almost all cases, a tile has 4 sides to
> which other tiles can connect. And if regarding a single side, in
> almost all cases an adjusting tile will be either centered or aligned
> to one of the outer edges. The grid controls work under that
> assumption. See here:
> http://adonthell.berlios.de/doc/index.php/Tools:Mapedit:Grid
>
> The problem, of course, is that you will have to switch back and forth
> between the grid controls and the main window often as right now there
> is no information how two tiles are connected and therefore the grid
> cannot adapt automatically.
>
> That is where I thought your idea could help in two ways:
>
> 1. By indicating matching tiles, the entity list can be filtered to
> only show tiles that can be attached to the selected object. (But it's
> less suited to filter for pieces of matching furniture, for example.
> That's why I still see the tag based filtering as a worthwhile
> alternative.)
>
> 2. By specifying how any two tiles are aligned, the grid can be
> automatically set accordingly, so that the picked mapobject can be
> placed directly on the map without the need for manual adjustments.
>
>
> I'm not as good as you in providing mockups, so I have to do with a
> simple description of the sequence I would envision.
>
> 1. Pick a horizontal wall piece.
> 2. Enable "matching filter" (hopefully with a simple key shortcut)
> 3. The entity view shows a number of matching horizontal and corner pieces.
> 4. Place a line of wall pieces (left click), then release the current
> piece (right click)
> 5. Pick a corner piece from the entity list
> 6. The filter changes to show mapobjects matching this new piece.
> 7. The grid changes so the corner can be placed seamlessly next to the
> last horizontal wall piece. (left click)
> 8. Release the corner piece (right click), select a vertical wall
> piece from the entity list.
> 9. The filter changes
> 10. The grid changes.
> 11. (and so on) ...
>
>
> The advantage I see here is that the amount of work required to get
> this working is very small. Filtering a listview in GTK+ is trivial.
> The grid and alignment stuff is already there, it just needs to be
> toggled via a function call instead of a button press. No need for
> extra highlighting, edge detection, showing "drop down" lists of
> matching mapobjects (although I would quite like the latter, so maybe
> at a later point it could be added as an alternative for picking from
> the entity list.).
>
>
> There is a second part to all that, and that is defining the meta-data
> required by the above. I do like your general idea here, as it seems
> much more convenient than what I had in mind. But instead of adding a
> special "connector" shape, perhaps we could just stick to the four
> edges (back, front, left, right) of a tile (I'd rather not worry about
> top and bottom). Consider the following ASCII art
>
> Let that be a horizontal wall piece. You'd have connecting edges on
> the left and right.
>
>   ,-----------,
> A '-----------' A
>
> Since you want to be able to add that same wall piece on either side,
> your connecting edges would have to have the same id.
>
> Now let there be a matching corner tile.
>
>    ,-----,
> A '---, |
>       | |
>       |_|
>       B
>
> The left side would have the same id as the horizontal wall above. The
> front side would have a different id, equal to that of matching
> vertical wall pieces.
>
> When the horizontal piece is selected, the filter would show the
> corner since one of its sides has the same id. We could even improve
> the code and only consider ids of facing sides. (I.e. object A left id
> == object B right id would be a match whereas object A left id ==
> object B left id would not result in a match).
>
>
> A ground tile OTOH would usually have the same id on all four sides. A
> transition tile between different types of ground would have different
> ids. The auto-filtering would then work well for those too.
>
>
> For most decoration, ids for the sides would not make sense. But there
> might be exceptions, for example if you have a middle part of a table
> or bench and two corner parts.
>
>
> In addition to the side ids, we'd need to specify the alignment meta
> data. I don't think we can get away with a simplistic
> center/left/right scheme. We may need something similar to what you
> proposed: the area where the connection is made. Again, I would keep
> it simple and just specify one such "connector" per side, with a start
> and end position. Initially those would be the corner points of that
> side, so for a lot of tiles no change to the values would be required.
> For L, T, or X shapes, you could adapt them as needed,
>
> In theory, it would be nice to specify the "length" once for each id,
> because matching "connectors" should be the same size on every shape.
> Then you would just adapt the starting point of the connector, if
> necessary. But in practice, the implementation would be more difficult
> without much added benefit.
>
> The grid can then be positioned such that the connectors on facing
> sides line up, which is simple math.
>
>
> Implementation wise, a "connector" object would have a side, an id,
> and two integers for start and end position. (Since we already know
> the side, we only need one coordinate for each). Each model then
> simply gets a list of connectors. That way, if we want to get fancy,
> you could have multiple connectors per side. For now, I can't think of
> a case where this would be needed. A GUI for editing these four
> properties would be easy to add to modeller and I wouldn't even mind
> saving the connector data in the actual model. In addition, the
> selected connector could be displayed on the model, so it would be
> easier to set start and end.
>
> OTOH, maybe keeping connector data separate from the model would allow
> to "pick" from a list of existing connectors. That might make adding
> connectors to a model easier, as you do not have to type the id every
> time. I'm certainly open to suggestions here.
>
>
> As for the other meta-data fields you suggested:
>
> * Tags: my idea is that you can add additional tags in mapedit,
> together with the "automatic", directory based tags. There's already a
> tab in the entity property dialog for that purpose, it just has no
> logic implemented yet. The property dialog shows the first time you
> add a new object to the map, and it can be brought up any time later
> by hovering over an object and pressing enter. My idea was, that the
> tag list for that mapobject would have the same functionality as the
> tag list in the filter dialog, so that you can bring that up instead
> to filter for similar objects without the need to know which tags
> might be assigned to any specific object.
>
> * Description: not sure if this should go into modeller or mapedit.
> But I assume you'd want to be able to see it in mapedit.
>
> Maybe I've got an idea here: would it be helpful if the entity
> property dialog had a button that would open the current mapobject in
> modeller? Then you could edit description and tags and stuff in
> modeller (where it would seem to belong more naturally) and only have
> a readonly display in mapedit, Don't expect fancy stuff like automatic
> synchronisation when saving in modeller, however! But it's only a
> single button click to reload the entity list anyway.
>
>
> Okay, this was kinda long, so lets hear your opinion first. I admit
> that it's not as fancy as what you had in mind (shows I'm no artist,
> just a lazy programmer), but it should come close in functionality and
> require only a little bit of additional coding to make it work. So
> what do you say?
>
> Kai
>
>> My 2p on the filtering:
>>
>> Perhaps it's better to reflect the directory structure of the models in 
>> mapedit for now. Related wall parts and suchlike are already grouped in a 
>> single directory, so we can exploit that. Perhaps have one 
>> pane/dialog/whatever with collapsible directories (like Windows Explorer) 
>> and another which then shows a list of mapobjects within the currently 
>> selected directory.
>
>> As far as the templates go, there are a few simple options for hiding them:
>> - We just move them out of the gfx48/models48 directory trees and keep them 
>> separately somewhere else.
>> - Or: In mapedit we just hide any directory whose name matches *template* 
>> (possibly this can be enabled/disabled via a tickbox somewhere).
>>
>> Ultimately though, I think meta-data that describes which mapobjects fit 
>> together and user-defined tags are the way to go. Once we have a format for 
>> such data and have augmented the mapobjects with it we can do much better 
>> filtering. IMHO, finding mapobjects that way will ultimately be the default, 
>> so users don't need to know or care about the directory structure.
>>
>> I think the meta-data topic deserves a bit more discussion first though. Off 
>> the top of my head, I'd like support for stuff like:
>>
>> - User-defined keywords (aka tags) to help categorise the mapobjects
>> - Descriptions: I'm thinking a free text field where designers can put 
>> comments about intended usage, tips, instructions etc.
>>
>> As for describing how objects fit together, I'd propose something like the 
>> following:
>>
>> - We have something that describes the surfaces where two related objects 
>> touch. E.g. the left & right vertical sides of a facing wall piece. When 
>> tiling that piece, the left side of one touches the right of the other. 
>> Let's call it a "connecting surface" for now (can't think of a snappier name 
>> right now).
>>        - This connecting surface would most likely be created in the 
>> modeller as a special kind of shape. It is saved as an individual file 
>> though.
>>        - It gets a unique ID assigned to it (probably automatically)
>>        - Possibly it has an optional, user-friendly display name too
>>
>> - Then, when creating actual object in the modeller you can import relevant 
>> connecting surfaces and position them on the model. The idea is that you 
>> describe where any other object that contains the a connecting surface with 
>> the same ID can connect.
>>
>> I think this is preferable to, for example, explicitly linking from one 
>> object to another since that can quickly become a maintenance nightmare when 
>> you get lots of objects.
>>
>>
>> Later on, the mapeditor can use this meta-data to suggest the next object to 
>> place on the map. I imagine this to be a bit like auto-complete in an IDE or 
>> browser address bar. E.g. I put an object on the map and as I move the mouse 
>> cursor near one of its connecting surfaces I get some kind of indication 
>> that there is a connecting surface (maybe it lights up or I get a different 
>> cursor). Some key or button press then displays a new object that is 
>> connected to the previous one (maybe it's duplicate of the one I just placed 
>> initially) and using some other button I can cycle through other available 
>> objects until I find the one I want.
>>
>> Hmm... this'll be a lot easier to describe in picture. I'll make a quick UI 
>> mock-up. brb!
>>
>>
>>        - James
>>
>>
>>
>>
>> On 1 Jun 2011, at 19:49, Kai Sterker wrote:
>>
>>> Seems I've ran into a bit of trouble with my tag based filtering idea
>>> for mapedit. I've attached the filter dialog I've implemented so far,
>>> but I'd like to get some input on the underlying logic.
>>>
>>> Basically, there are two ways to filter the list of map objects: show
>>> only objects that "match" the current object, i.e. all objects that
>>> could possibly be placed seamlessly next to the current object. Since
>>> the meta-data for this feature would have to be supplied by the user,
>>> I did not start on this type of filter yet. I've got some concept in
>>> mind and I don't expect much trouble there.
>>>
>>> I did start with the supposedly easier, tag based filtering, where the
>>> components of the model path make up the tags attached to each model.
>>> (In the future, this might be extended with user-supplied tags, too).
>>> The result of the current model48/ content is shown in the filter
>>> dialog screenshot (The Count column gives the number of models with
>>> the given tag).
>>>
>>> My idea was, to automatically exclude the "template" stuff from the
>>> model list, but in a way that would be obvious to the user. So it's in
>>> the list like a regular tag, but unchecked by default. Going with
>>> that, the filter logic would have to be "hide all objects that contain
>>> 'template/' in their file path". But then I thought, when editing a
>>> map, I might want to see all "inside" "walls". And it would be easier
>>> if I could just check those two tags to narrow down the list. But that
>>> would also include all the inside wall templates. And now I am stuck,
>>> not really able to decide which route to go.
>>>
>>> Maybe just hardcode the template stuff filtering and otherwise go with
>>> the latter filtering logic?
>>>
>>> Or there could be two columns of checkboxes, one for inclusion and the
>>> other for exclusion. Then I could include "inside" "wall"s and exclude
>>> "templates" at the same time (and "stone" and "mine" and "cave" walls
>>> too, if I wanted), OTOH, perhaps I'd be better of to just filter for
>>> "plaster" "walls" then.
>>>
>>> Anyone got a better idea?
>>>
>>>
>>> I've got some stuff to work on besides the filtering, so I'll let that
>>> sit for a little and wait for your suggestions.
>>>
>>> Kai
>>> <filter.png>_______________________________________________
>>> Adonthell-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/adonthell-devel
>>
>>
>

meta-data.png
Description: PNG image

connectors.png
Description: PNG image