[Meshlab-devel] Some new ideas for Meshlab

[Sebastian H. <seb...@go...>]

Hello Paolo,

We met recently with our most experienced 3D software user, who will now
start using meshlab for some parts of his work, to go over Meshlab and
its plugins.  He liked Meshlab very much and had a few suggestions to
make it even better.  We also have a couple things to discuss about how
edit plugins work.  We would be happy to do the work for these changes
but want to get your opinion about our ideas.  We know that there are a
lot of things here so if you prefer a conference call please feel free
to let us know.

1.  Currently to rotate the mesh when using an edit plugin you have to
push escape or the toggle button to exit edit mode each time.  In order
to be more like other 3D software packages alt+middle mouse button
should also be able to rotate the model.  In edit mode MeshLab already
supports mouse wheel to zoom and middle mouse button click to drag the
mesh just like 3DS Max so we think adding the 3rd type of motion to the
middle mouse button makes sense.

2.  We would like a Save function that saves the mesh to the file it was
opened from without explicitly asking for a name and path.

3.  After saving a mesh with "Save As" we would like the mesh to now be
linked to the file you just saved instead of the file that was
originally loaded (like most all other applications do).  Right now, for
example, if you "Save As" mesh.obj as mesh2.obj you are still working on
mesh.obj instead on mesh2.obj. Isn't it a better idea to to use
mesh2.obj instead?


4.  When an edit plugin has a Dialog which has a close  button (x),
clicking the x closes the dialog but does not trigger the EndEdit
function to be called or close the plugin. You can never get the window
back without toggling the edit plugins's button which is confusing to
users.  glArea has a slot to do this but it seems the programmer must
create a signal and emit it when the close event for the tool window is
handled as the edit_hole plugin does.  Here are two possible solutions:
a) create  a class called MeshlabEditWidget which programmers would be
able to override in their plugin that sends a close siglnal out and link
it like in edit_hole .  b) create an event filter to trigger this slot
in glArea and recommenced the user install it.

5. The current design for the MeshEditInterface does not have any
capacity to handle layer switching.  This causes some Edit plugins to
crash because the interface requires the programmer to handle the
switching between layers all on their own by always checking to see if
the MeshModel& passed in is the same one that it thought it was working
with before.  Most plugins dont do this and thus crash when you have
them open and switch layers.   We propose the edit interface be changed
to provide a mesh document on the StartEdit function and overload
StartEdit as was done for applyFilter in MeshFilterInterface.  Then also
have a function which is call to indicate when a user switches layers.
The default implementation of this function could be just to call
EndEdit with old MeshModel and StartEdit again with current MeshModel so
that plugins that dont use it will effectively reopen each time a layer
is switched and not crash.

6. Edit plugins do very crazy things when you try to open meshes in
multiple windows (and by window here we mean QMdiSubWindow/GLArea) and
switch between windows when the edit plugin is open or try to start an
edit plugin for one window without closing that same edit plugin for
some other window.  The problem is that there is just one instance of
each edit tool and this one instance now has to deal with two windows.
All kinds of things go wrong when two glAreas try to uses this one
instance at the same time.

There are two possible solutions to this.  a) Closely restrict access to
the MeshEditInterface instances at all times, allowing only one window
to use an instance at any one time.  If an instance of an
MeshEditInterface is open for one window and the user tries to open this
tool for another window Meshlab must call EndEdit, then call StartEdit
for the new window.  b) (the option that we prefer).  Change the way
that the plugins are loaded so that the plugin is not an instance of a
MeshEditInterface but instead a Factory for creating instances of
MeshEditInterface.  Each time a window requests the edit tool an
instance of MeshEditInterface is created for that window.  When the
window is closed the instances of any MeshEditInterface it requested are
de-constructed.  This allows the edit tool to operate on multiple
windows without crashing.  Also this will ease the pain to the
programmers because they will not need to worry about local data being
corrupted by using the tool in multiple windows.  The current system
causes the programmer to think about many strange cases.  Also this
design allows for the tool to potentially store some local data so that
it can remember what it was doing on a mesh after being open and closed
(this can also be achieved by reading and writing mesh attributes).
Additionally this would allow multiple edit tools to be placed in the
same plugin reducing the number of plugins Meshlab has to load.

7.  When you start meshlab in linux with metacity there is this empty
meshlabStdDialog showing which is later populated with the filter ui
when you chose a filter from the list.  Could a new dialog window be
created each time a filter is run instead of opening and hiding this
one?  As it is now linux with metacity users have to try to drag this
window from the corner of the screen to uncover the file and edit menu.

We know that this is a lot of stuff but we hope to here from you soon.

Thanks,

Oscar and Sebastian