Named arrays

[bART Janssens-2]

Tim,

While adding named array support to SubdivideFaces, I needed to be able to
construct the target array in a random order. To do this, I put a variation
of the named_array_copier in the mesh module, that has a "copy" method
instead of a "push_back" method, so data can be copied to any position in the
target array. Because this requires memory to be allocated, there is also a
resize function.

Is it OK if I merge the copy methods into the named_array_copier in the SDK,
and add the resize function to named_array_operations?

Cheers,

Bart

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> While adding named array support to SubdivideFaces, I needed to be able to
> construct the target array in a random order. To do this, I put a variation
> of the named_array_copier in the mesh module, that has a "copy" method
> instead of a "push_back" method, so data can be copied to any position in the
> target array. Because this requires memory to be allocated, there is also a
> resize function.
>
> Is it OK if I merge the copy methods into the named_array_copier in the SDK,
> and add the resize function to named_array_operations?
>  

Yep, I knew we'd need this sooner-or-later.  Instead of your resize()
function however, I've added resize() to k3d::array and
k3d::named_arrays, which is much easier to implement and is consistent
with the goal of making k3d::array "just like a vector, but without the
types".  I've also moved k3d::named_array_copier to its own set of
files.  Good luck getting my changes though - the svn issues have gotten
worse (see followup).

Cheers,
Tim

--
Timothy M. Shead, K-3D founder
http://www.k-3d.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sat, Jul 19, 2008 at 8:01 PM, Timothy M. Shead <tshead@...> wrote:
> Yep, I knew we'd need this sooner-or-later.  Instead of your resize()
> function however, I've added resize() to k3d::array and
> k3d::named_arrays, which is much easier to implement and is consistent
> with the goal of making k3d::array "just like a vector, but without the
> types".  I've also moved k3d::named_array_copier to its own set of
> files.  Good luck getting my changes though - the svn issues have gotten

OK, I've added the copy methods, and also adapted SubdivideEdges to
use it, so in theory the functors can run in parallel. I must say the
named array system as a whole is very impressive. Hopefully it will be
possible to use a similar system in the conversion to CUDA.

Cheers,

--
Bart

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> OK, I've added the copy methods, and also adapted SubdivideEdges to
> use it, so in theory the functors can run in parallel. I must say the
> named array system as a whole is very impressive. Hopefully it will be
> possible to use a similar system in the conversion to CUDA.
>  
As it happens, I just ran into an interesting issue, one that will
affect MergeMesh.  I started working on replacements for the legacy
blobby operator modifiers (i.e. BlobbyAdd, BlobbySubtract, etc) which
accept multiple inputs and implement imulti_mesh_sink.  Because this is
basically a special-case of merging multiple meshes, it has to deal with
meshes that have differing sets of named arrays.  In the MergeMesh
implementation we are copying the first input's named arrays, then using
named_array_copier on the remaining inputs, but this will not produce
valid results.  Assume you have two input meshes, each with 10 points.  
The first mesh has vertex arrays A and B, while the second mesh has
vertex arrays B and C.  After running MergeMesh, the output will contain
vertex array A containing 10 values and vertex array B containing 20
values - boom!

I see two reasonable alternatives in this scenario - either the merged
mesh contains the union of all its input arrays, or the intersection.  
The first case assumes that a sensible "default" value can be assigned
when an output array is missing its input counterpart, something that
generally isn't true.  I favor the latter approach for its simplicity,
and because I generally dislike creating data out of thin air.  To
handle this approach I am working on mechanisms to generate named_arrays
by cloning a set of named_arrays instead of just one, and relaxing the
named_array_copier semantics to handle array mismatches quietly (since
it won't be an error condition to use named_array_copier on named_arrays
that don't have the same sets of arrays).

Cheers,
Tim

--
Timothy M. Shead, K-3D founder
http://www.k-3d.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, Jul 24, 2008 at 7:31 AM, Timothy M. Shead <tshead@...> wrote:
> generally isn't true.  I favor the latter approach for its simplicity,
> and because I generally dislike creating data out of thin air.  To
> handle this approach I am working on mechanisms to generate named_arrays
> by cloning a set of named_arrays instead of just one, and relaxing the
> named_array_copier semantics to handle array mismatches quietly (since
> it won't be an error condition to use named_array_copier on named_arrays
> that don't have the same sets of arrays).

Yes, I had a feeling things weren't going to work correctly with
MergeMesh in case of different array sets. I had also considered
setting default values for the missing arrays, but as you said, there
is no way to know what is sensible, and we'll most likely just end up
confusing the user.

Regards,

--
Bart

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Thu, Jul 24, 2008 at 7:31 AM, Timothy M. Shead <tshead@...> wrote:
>  
>> generally isn't true.  I favor the latter approach for its simplicity,
>> and because I generally dislike creating data out of thin air.  To
>> handle this approach I am working on mechanisms to generate named_arrays
>> by cloning a set of named_arrays instead of just one, and relaxing the
>> named_array_copier semantics to handle array mismatches quietly (since
>> it won't be an error condition to use named_array_copier on named_arrays
>> that don't have the same sets of arrays).
>>    
>
> Yes, I had a feeling things weren't going to work correctly with
> MergeMesh in case of different array sets. I had also considered
> setting default values for the missing arrays, but as you said, there
> is no way to know what is sensible, and we'll most likely just end up
> confusing the user.
>  

I've committed a first-iteration set of changes for this, you can see
example usage in modules/blobbies/add.cpp ... seems to work fine right
now, we'll see what I think after I've slept on it ...

Cheers,
Tim

--
Timothy M. Shead, K-3D founder
http://www.k-3d.org



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development