|
»
»
»
« Return to Thread: Re: Property groups (was: Morph plugin Identifying user properties signals)
Re: Merge Mesh properties was: Property groups
by bART Janssens-2
::
Rate this Message:
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
> 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
« Return to Thread: Re: Property groups (was: Morph plugin Identifying user properties signals)
| Free Forum Powered by Nabble | Forum Help |