Re: Property groups (was: Morph plugin Identifying user properties signals)

[bART Janssens-2]

On Sun, Apr 20, 2008 at 1:01 AM, Timothy M. Shead <tshead@...> wrote:
> On Fri, 2008-04-18 at 23:27 +0200, Bart Janssens wrote:
>  > Tim, the blue "+" in the properties panel is shown for each group, but
>  > clicking it always adds properties to the first group. Is this a bug?
>
>  That's a bug.

OK, I've been looking into it, but the two solutions I see require an
SDK modification:
1. Allow external modification of the property grouping, i.e. add
something like register_property(iproperty* Property, const
std::string& GroupName) to iproperty_group_collection
2. Add a create... method in k3dsdk/properties.h that takes a group
name as argument

2 would require some way to pass the group on property registration or
creation, I'm not sure that is desirable.

While looking at k3dsdk/properties.cpp I saw that at line 289 the new
property is first put in a "null_property_collection". Why is that?

Cheers,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

On Sun, 2008-04-20 at 10:58 +0200, Bart Janssens wrote:

> On Sun, Apr 20, 2008 at 1:01 AM, Timothy M. Shead <tshead@...> wrote:
> > On Fri, 2008-04-18 at 23:27 +0200, Bart Janssens wrote:
> >  > Tim, the blue "+" in the properties panel is shown for each group, but
> >  > clicking it always adds properties to the first group. Is this a bug?
> >
> >  That's a bug.
>
> OK, I've been looking into it, but the two solutions I see require an
> SDK modification:
> 1. Allow external modification of the property grouping, i.e. add
> something like register_property(iproperty* Property, const
> std::string& GroupName) to iproperty_group_collection
> 2. Add a create... method in k3dsdk/properties.h that takes a group
> name as argument
>
> 2 would require some way to pass the group on property registration or
> creation, I'm not sure that is desirable.

I'd say that all of this is the wrong approach.  At some point, you can
only jump through so-many abstractions to try and tell the UI layer how
to work.  What's really needed for this case (and cases like it) is a
new type of plugin - a UI plugin that replaces the auto-generated list
of properties normally displayed by the Node Properties Panel, for
specific plugins.  That would give plugin authors the flexibility to
provide plugin-specific behavior in the UI.  In this case, you'd have a
button for adding morph targets, but it would actually add two user
properties "under the hood", and display them in a logical way.  I'm in
the middle of converting Tools to plugins, I'll look into this when
that's done.

> While looking at k3dsdk/properties.cpp I saw that at line 289 the new
> property is first put in a "null_property_collection". Why is that?

It has to do with the order in which objects are created; try assigning
the final destination in the ctor and see where it bombs.

Cheers,
Tim



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[hoako]

Bart:
I'd like to share my opinion on the MergeMesh properties.

Here you can test my last patch on the morph plugin.
http://sourceforge.net/tracker/index.php?func=detail&aid=1944722&group_id=11113&atid=311113
I guess properties should be like this (see my example)
input_mesh (like any other modifier, so it will be automatically connected, not
input_mesh1)
input_mesh1 already "coded"

This way the user will easily find how to use the plugin. Adding more inputs is
optional of course, but this makes things clearer for the user.(reduce the FAQ size)

Cheers!
Joaquín



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On 4/23/08, Joaquín Duo <hoakoduo@...> wrote:
> I guess properties should be like this (see my example)
> input_mesh (like any other modifier, so it will be automatically connected,
> not
> input_mesh1)
> input_mesh1 already "coded"

I am currently reimplementing the MergeMesh plugin in C++. The
polyhedra part is in SVN now, and has k3d::imulti_mesh_sink in its
interface list. This means you just need to select a bunch of meshes
and apply the MergeMesh modifier from the right-click menu. The UI
code in k3dsdk/ngui/modifiers.h/cpp (modify_selected_meshes function)
will then create and connect a user property for each selected mesh.

I agree simply naming them input_1, ... was a mistake, though. Using
input_mesh1 and so on is clearer. Another possibility would be to use
the name of the node we are connecting to?

regards,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[hoako]

Bart Janssens wrote:

> On 4/23/08, Joaquín Duo <hoakoduo@...> wrote:
>> I guess properties should be like this (see my example)
>> input_mesh (like any other modifier, so it will be automatically connected,
>> not
>> input_mesh1)
>> input_mesh1 already "coded"
>
> I am currently reimplementing the MergeMesh plugin in C++. The
> polyhedra part is in SVN now, and has k3d::imulti_mesh_sink in its
> interface list. This means you just need to select a bunch of meshes
> and apply the MergeMesh modifier from the right-click menu. The UI
> code in k3dsdk/ngui/modifiers.h/cpp (modify_selected_meshes function)
> will then create and connect a user property for each selected mesh.
>
> I agree simply naming them input_1, ... was a mistake, though. Using
> input_mesh1 and so on is clearer. Another possibility would be to use
> the name of the node we are connecting to?

Yes, it's a possibility.
In my opinion I would use input_mesh# for the name and changing only the Label
for the name of the connected mesh.
Having standard naming is easier to filter the properties by scripts for example.

I don't know your opinion about making it a modifier instead of a mesh_source.
(like morphpoints) This way it could be used to attach a mesh to the current
working pipeline. Thats why i suggested having input_mesh and input_mesh1 by
default, for easy starting, and then adding more meshes.
If it its applied to multiple nodes the behavior should be different.
In fact this way the resulting mesh should take the name of the first selected mesh.
What do you think?

Cheers!
Joaquín


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[hoako]

Joaquín Duo wrote:
> I don't know your opinion about making it a modifier instead of a mesh_source.
> (like morphpoints) This way it could be used to attach a mesh to the current
> working pipeline. Thats why i suggested having input_mesh and input_mesh1 by
> default, for easy starting, and then adding more meshes.
> If it its applied to multiple nodes the behavior should be different.
> In fact this way the resulting mesh should take the name of the first selected mesh.
Ups! Sorry...
I just looked at the code for replying (says mesh_sink). Seems this is the
behavior.

Cheers!
Joaquín


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Joe Crawford]

>  I don't know your opinion about making it a modifier instead of a mesh_source.
>  (like morphpoints) This way it could be used to attach a mesh to the current
>  working pipeline. Thats why i suggested having input_mesh and input_mesh1 by
>  default, for easy starting, and then adding more meshes.
>  If it its applied to multiple nodes the behavior should be different.
>  In fact this way the resulting mesh should take the name of the first selected mesh.
>  What do you think?

I would definitely prefer it as a modifier. Its works great that way
in some other apps.

Sincerely,

Joe Crawford
___________________________________
Owner - Celestine Studios and Joetainment Enterprises
Cell: 604-866-3050
Email: joetainment@...
Web: http://celestinestudios.com

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On 4/25/08, Joe Crawford <joetainment@...> wrote:

> >  I don't know your opinion about making it a modifier instead of a
> mesh_source.
> >  (like morphpoints) This way it could be used to attach a mesh to the
> current
> >  working pipeline. Thats why i suggested having input_mesh and input_mesh1
> by
> >  default, for easy starting, and then adding more meshes.
> >  If it its applied to multiple nodes the behavior should be different.
> >  In fact this way the resulting mesh should take the name of the first
> selected mesh.
> >  What do you think?
>
> I would definitely prefer it as a modifier. Its works great that way
> in some other apps.

I'm getting a bit confused at this discussion, because I *think*
everything already works the way you both want it. To help focus the
discussion, I have made a summary of the different cases at:
http://www.k-3d.org/wiki/User:Barche/Mesh_Modifier_Types

P.S. Joe, great to see you're back :)

Cheers,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[hoako]

Bart Janssens wrote:
> I'm getting a bit confused at this discussion, because I *think*
> everything already works the way you both want it. To help focus the
In my point of view:
When applying it as a Modifier it doesn't create a new MeshInstance. You may
change this anyway without making it a mesh_modifier.

I think that input_mesh should be fixed (not user property) on the plugin.
input_mesh1 should be user property (unlike my MorphPoints, which I am going to
change, when there is a automated user property added), because you may desire
to delete it.

Last thought, I don't know which is better when selecting multiple objects for
merging:
1-Create a new MeshInstance
2-Reuse the first selected object for the target MergeMesh (don't know if select
respect the order)
3-Never use this method in the Code and create a script for doing so.

If we use 2 or 3, then MergeMesh should definitely be a mesh_modifier, since
it'll never be a new object by itself. Anyway, if you use
Create->Mesh->MergeMesh it will create a new MeshInstance anyway.

> P.S. Joe, great to see you're back :)
Definitely, we needed you Joe back :D. Good to read you Joe!

Cheers!
Joaquín


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On 4/26/08, Joaquín Duo <hoakoduo@...> wrote:
> When applying it as a Modifier it doesn't create a new MeshInstance. You may
> change this anyway without making it a mesh_modifier.

There is still the problem of the transformations of the inputs. If
you don't keep the original MeshInstance, they are lost. For plugins
like MergeMesh and boolean operations, this is not intuitive. That's
why the connection is now made to the transformed_mesh property of the
instance.

> I think that input_mesh should be fixed (not user property) on the plugin.
> input_mesh1 should be user property (unlike my MorphPoints, which I am going
> to

I think all inputs should use the same system. We can either stick
with user properties, or provide methods to manipulate inputs in
imulti_mesh_sink. I prefer the user properties, since they already do
everything we need. Implementation is simple, since we only need to
iterate over all user properties of k3d::mesh* type (see
merge_mesh.cpp).

> change, when there is a automated user property added), because you may

Note that the properties are already added automatically to any plugin
that has imulti_mesh_sink in its interface list.

> Last thought, I don't know which is better when selecting multiple objects
> for
> merging:
> 1-Create a new MeshInstance
> 2-Reuse the first selected object for the target MergeMesh (don't know if
> select
> respect the order)
> 3-Never use this method in the Code and create a script for doing so.
>
> If we use 2 or 3, then MergeMesh should definitely be a mesh_modifier, since
> it'll never be a new object by itself. Anyway, if you use
> Create->Mesh->MergeMesh it will create a new MeshInstance anyway.

I very much prefer 1 (as currently implemented):
 - It automatically keeps the transformation of the inputs
 - If you don't like the way the inputs are transformed, you can
simply unhide one of the hidden inputs, and tweak using the tools
 - Everything is already in place to manipulate the inputs from the UI
or from scripts, since they are just user properties.

There is no single interface for a modifier in K-3D. It is just a
combination of an input interface and an output interface. A
combination of imulti_mesh_sink and imesh_source is just as much a
modifier as a combination of imesh_sink and imesh_source (the
"classic" modifier).

Cheers,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[hoako]

Bart Janssens wrote:
> On 4/26/08, Joaquín Duo <hoakoduo@...> wrote:
>> When applying it as a Modifier it doesn't create a new MeshInstance. You may
>> change this anyway without making it a mesh_modifier.
>
> There is still the problem of the transformations of the inputs. If
> you don't keep the original MeshInstance, they are lost. For plugins
> like MergeMesh and boolean operations, this is not intuitive. That's
> why the connection is now made to the transformed_mesh property of the
> instance.
Ups, I forgot about this.

My opinion: In order not to confuse the user MergeMesh shouldn't hide the source
node (since the user could press "show all", then it's lost). There should be a
separate option, a script by now, that disables them from render on Renderman or
the Viewport. (setting the painter to None, i can do it)

Cheers!
Joaquín


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sat, Apr 26, 2008 at 9:00 PM, Joaquín Duo <hoakoduo@...> wrote:

> Bart Janssens wrote:
>  > On 4/26/08, Joaquín Duo <hoakoduo@...> wrote:
>  >> When applying it as a Modifier it doesn't create a new MeshInstance. You may
>  >> change this anyway without making it a mesh_modifier.
>  >
>  > There is still the problem of the transformations of the inputs. If
>  > you don't keep the original MeshInstance, they are lost. For plugins
>  > like MergeMesh and boolean operations, this is not intuitive. That's
>  > why the connection is now made to the transformed_mesh property of the
>  > instance.
>  Ups, I forgot about this.
>
>  My opinion: In order not to confuse the user MergeMesh shouldn't hide the source
>  node (since the user could press "show all", then it's lost). There should be a
>  separate option, a script by now, that disables them from render on Renderman or
>  the Viewport. (setting the painter to None, i can do it)

Well, I hadn't thought about that case. You are right, it would be
confusing. Maybe we should indeed remove the MeshInstances of the
inputs, and replace them with a TransformPoints modifier instead. This
would also make the MeshInstance implementation simpler, and it would
not have to duplicate code.

The procedure for a many-to-one modifier would then become:
for all selected meshes:
  create a TransformPoints modifier
  connect the inputs that  went to the selected MeshInstance to the
TransformPoints modifier instead
  delete the MeshInstance
  create a user property the input and connect it to the output_mesh
of the TransformPoints modifier

regards,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[hoako]

Bart Janssens wrote:

>
> Well, I hadn't thought about that case. You are right, it would be
> confusing. Maybe we should indeed remove the MeshInstances of the
> inputs, and replace them with a TransformPoints modifier instead. This
> would also make the MeshInstance implementation simpler, and it would
> not have to duplicate code.
>
> The procedure for a many-to-one modifier would then become:
> for all selected meshes:
>   create a TransformPoints modifier
>   connect the inputs that  went to the selected MeshInstance to the
> TransformPoints modifier instead
>   delete the MeshInstance
>   create a user property the input and connect it to the output_mesh
> of the TransformPoints modifier

I find this idea too complicated.
I wouldn't delete the MeshInstances. It's OK like it is, but it shouldn't hide
objects.
This is the workflow I imagine (let's suppose we have layers):
- The user creates all the objects to merge (layer 0)
- S/he merge meshes and creates a new object (linked to the transformed meshes)
- The user moves the new object to layer 1
After that the show/hide commands should work on layers. This works OK with the
procedural generation philosophy.

I guess later a User Dialog for merging meshes could be added, so the user could
  choose
- Transformed Mesh o Output Mesh
- Delete the instances. (Use the TransformPoints option)
- Make a copy of all meshes as FrozenMesh for inputs. (so objects are not
"linked") Optionally delete the original.
We could implement the option we want, later this Dialog will probably be
necessary. So i think the current option is OK but without hiding.
Whats your opinion?

Joe: Do you agree?

Cheers!
Joaquín




-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sun, Apr 27, 2008 at 10:28 AM, Joaquín Duo <hoakoduo@...> wrote:

> Bart Janssens wrote:
>  >
>  > Well, I hadn't thought about that case. You are right, it would be
>  > confusing. Maybe we should indeed remove the MeshInstances of the
>  > inputs, and replace them with a TransformPoints modifier instead. This
>  > would also make the MeshInstance implementation simpler, and it would
>  > not have to duplicate code.
>  >
>  > The procedure for a many-to-one modifier would then become:
>  > for all selected meshes:
>  >   create a TransformPoints modifier
>  >   connect the inputs that  went to the selected MeshInstance to the
>  > TransformPoints modifier instead
>  >   delete the MeshInstance
>  >   create a user property the input and connect it to the output_mesh
>  > of the TransformPoints modifier
>
>  I find this idea too complicated.
>  I wouldn't delete the MeshInstances. It's OK like it is, but it shouldn't hide
>  objects.
>  This is the workflow I imagine (let's suppose we have layers):
>  - The user creates all the objects to merge (layer 0)
>  - S/he merge meshes and creates a new object (linked to the transformed meshes)
>  - The user moves the new object to layer 1
>  After that the show/hide commands should work on layers. This works OK with the
>  procedural generation philosophy.

I think requiring layers for this to work is overkill. We should first
decide if the current situation where MeshInstance provides a
transformed output is desirable or not. I prefer inserting a dedicated
TransformPoints node, since this allows a simplification of
MeshInstance. Depending on the answer to that, we can decide if we
want to keep the input mesh instances around and hide them somehow
(flag, painter, layers...).

>  I guess later a User Dialog for merging meshes could be added, so the user could
>   choose
>  - Transformed Mesh o Output Mesh
>  - Delete the instances. (Use the TransformPoints option)
>  - Make a copy of all meshes as FrozenMesh for inputs. (so objects are not
>  "linked") Optionally delete the original.

Having such a dialog is a good idea, but the options should just be a
boolean for "Transformed input" and "Frozen input". The implementation
then depends on what is decided for the MeshInstance transformed_mesh
property.

Regards,

--
Bart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Joe Crawford]

>  I guess later a User Dialog for merging meshes could be added, so the user could
>   choose
>  - Transformed Mesh o Output Mesh
>  - Delete the instances. (Use the TransformPoints option)
>  - Make a copy of all meshes as FrozenMesh for inputs. (so objects are not
>  "linked") Optionally delete the original.
>  We could implement the option we want, later this Dialog will probably be
>  necessary. So i think the current option is OK but without hiding.
>  Whats your opinion?
>
>  Joe: Do you agree?

These are mostly very good ideas, however, dialog boxes in general are
a horrible idea, especially any blocking/modal ones. They really slow
users down.

I think a lot of these plugins that we've added can probably get
buttons in the property editor, so that the property editor just just
allow you to edit properties, but also allows you to push buttons that
perform actions related to those modifiers/properties.

This is really key in the 3dsmax UI, and it works really really well.
Maya and XSI make use of it somewhat as well.

In any case, we definitely need alternatives to dialog boxes. Nothing
should ever block or detract from the users interaction with the 3d
scene/viewport.

I would be happy to write up a proposed UI workflow for this merge
mesh modified, based on the concepts I replied to, which are all
pretty good ideas.

Is the current system testable in the subversion version?

In general, I'd be interested to hear about anything new and testable
that people would like artist/user feedback on.

Sincerely,

Joe Crawford
___________________________________
Owner - Celestine Studios and Joetainment Enterprises
Cell: 604-866-3050
Email: joetainment@...
Web: http://celestinestudios.com

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[hoako]

Joe Crawford wrote:
> These are mostly very good ideas, however, dialog boxes in general are
> a horrible idea, especially any blocking/modal ones. They really slow
> users down.
I agree.

>
> I think a lot of these plugins that we've added can probably get
> buttons in the property editor, so that the property editor just just
> allow you to edit properties, but also allows you to push buttons that
> perform actions related to those modifiers/properties.
>
> This is really key in the 3dsmax UI, and it works really really well.
> Maya and XSI make use of it somewhat as well.
>
> In any case, we definitely need alternatives to dialog boxes. Nothing
> should ever block or detract from the users interaction with the 3d
> scene/viewport.
>
> I would be happy to write up a proposed UI workflow for this merge
> mesh modified, based on the concepts I replied to, which are all
> pretty good ideas.
>
> Is the current system testable in the subversion version?

Yes it is. :)
>
> In general, I'd be interested to hear about anything new and testable
> that people would like artist/user feedback on.
There is a morph plugin. I don't know if something could be improved.

Cheers!
Joaquín


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development