Generic Polyhedron Primitives

[bART Janssens-2]

On Wed, May 20, 2009 at 6:19 AM, Timothy M. Shead <tshead@...> wrote:
> Fair enough ... to figure-out what the key / API should be, it would be
> useful to document all of the data types that we currently cache ...
> could you add that to the wiki?  Point VBOs and cached triangulations
> come to mind, what else is there?  While the list of cached data isn't
> set in stone, I wouldn't expect it to grow all that often.  It will also
> be useful to enumerate what hints need to be created to support
> efficient updates.

Basically, this is what is cached:
For non-VBO painters:
- Face Normals
- Triangulations
- SDS data
For VBO painters, additional caches are used:
- Points
- Normals (depends on the regular normals cache)
- Index VBOs for edges
- VBOs for  the triangulated data (depends on the regular triangle cache)
- VBOs for the SDS data (depends on the regular SDS cache)

I'm leaving on a holiday now until Monday, and I'm not taking my
laptop, so I'll not be able to update the wiki before Monday evening.

Cheers,

--
Bart

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

> On Wed, May 20, 2009 at 6:19 AM, Timothy M. Shead <tshead@...> wrote:
>> Fair enough ... to figure-out what the key / API should be, it would be
>> useful to document all of the data types that we currently cache ...
>> could you add that to the wiki?  Point VBOs and cached triangulations
>> come to mind, what else is there?  While the list of cached data isn't
>> set in stone, I wouldn't expect it to grow all that often.  It will also
>> be useful to enumerate what hints need to be created to support
>> efficient updates.
>
> Basically, this is what is cached:
> For non-VBO painters:
> - Face Normals
> - Triangulations
> - SDS data
> For VBO painters, additional caches are used:
> - Points
> - Normals (depends on the regular normals cache)
> - Index VBOs for edges
> - VBOs for  the triangulated data (depends on the regular triangle cache)
> - VBOs for the SDS data (depends on the regular SDS cache)
>
> I'm leaving on a holiday now until Monday, and I'm not taking my
> laptop, so I'll not be able to update the wiki before Monday evening.

Awesome!  I'll add this to the wiki in the meantime ...

Cheers,
Tim


------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Wed, May 20, 2009 at 11:41 PM, Timothy M. Shead <tshead@...> wrote:
> Awesome!  I'll add this to the wiki in the meantime ...

I've added the proposed key types as well, now. Mostly, items
depending on multiple arrays refer to the containing primitive. The
exception is the edge VBO, because I couldn't think of a use-case
where clockwise_edges becomes independent of edge_points.

Cheers,

--
Bart

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> On Wed, May 20, 2009 at 11:41 PM, Timothy M. Shead <tshead@...> wrote:
>> Awesome!  I'll add this to the wiki in the meantime ...
>
> I've added the proposed key types as well, now. Mostly, items
> depending on multiple arrays refer to the containing primitive. The
> exception is the edge VBO, because I couldn't think of a use-case
> where clockwise_edges becomes independent of edge_points.

Looks good!  I guess the next question would be what the cache actually
looks like.  Conceptually the cache is a map, but this can still
play-out in many ways ... at opposite extremes, the cache can store
cached data by-value or by-pointer, with pros-and-cons for each.  In the
former case, there are multiple caches, each with a strongly-typed key
and value.  In the latter, there is one cache with a void* key (since
primitives and arrays have no base-class in common), and maybe some
cached-data base-class pointer for the value.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Tue, May 26, 2009 at 8:03 AM, Timothy M. Shead <tshead@...> wrote:

> Bart Janssens wrote:
>> On Wed, May 20, 2009 at 11:41 PM, Timothy M. Shead <tshead@...> wrote:
>>> Awesome!  I'll add this to the wiki in the meantime ...
>>
>> I've added the proposed key types as well, now. Mostly, items
>> depending on multiple arrays refer to the containing primitive. The
>> exception is the edge VBO, because I couldn't think of a use-case
>> where clockwise_edges becomes independent of edge_points.
>
> Looks good!  I guess the next question would be what the cache actually
> looks like.  Conceptually the cache is a map, but this can still
> play-out in many ways ... at opposite extremes, the cache can store
> cached data by-value or by-pointer, with pros-and-cons for each.  In the
> former case, there are multiple caches, each with a strongly-typed key
> and value.  In the latter, there is one cache with a void* key (since
> primitives and arrays have no base-class in common), and maybe some
> cached-data base-class pointer for the value.

I'll write up a detailed proposal, but in the meantime, while trying
to fix a bug in the SDS painter, I hit a glitch in the handling of the
different levels for SDS caches. This is needlessly complex in the
current implementation, so I need to figure out how this could be
simplified for the new cache. One line of thought is to incorporate
the level number in the key (i.e. a pair of a uint and a primitive
pointer).

Cheers,

--
Bart

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Tue, May 26, 2009 at 8:03 AM, Timothy M. Shead <tshead@...> wrote:
>> Bart Janssens wrote:
>>> On Wed, May 20, 2009 at 11:41 PM, Timothy M. Shead <tshead@...> wrote:
>>>> Awesome!  I'll add this to the wiki in the meantime ...
>>> I've added the proposed key types as well, now. Mostly, items
>>> depending on multiple arrays refer to the containing primitive. The
>>> exception is the edge VBO, because I couldn't think of a use-case
>>> where clockwise_edges becomes independent of edge_points.
>> Looks good!  I guess the next question would be what the cache actually
>> looks like.  Conceptually the cache is a map, but this can still
>> play-out in many ways ... at opposite extremes, the cache can store
>> cached data by-value or by-pointer, with pros-and-cons for each.  In the
>> former case, there are multiple caches, each with a strongly-typed key
>> and value.  In the latter, there is one cache with a void* key (since
>> primitives and arrays have no base-class in common), and maybe some
>> cached-data base-class pointer for the value.
>
> I'll write up a detailed proposal, but in the meantime, while trying
> to fix a bug in the SDS painter, I hit a glitch in the handling of the
> different levels for SDS caches. This is needlessly complex in the
> current implementation, so I need to figure out how this could be
> simplified for the new cache. One line of thought is to incorporate
> the level number in the key (i.e. a pair of a uint and a primitive
> pointer).

So, this increasingly points to a world where the cache is an
associative container templated on key and value types, which is where I
was leaning anyway - anything else would have involved some kind of
downcasting of value pointers.  It introduces some complexity by leading
to multiple caches (one per key/value type), but I think that's manageable.

BTW, as background I'm currently working on generic selections (which go
hand-in-hand with generic primitives).  I notice there's some breakage
in the OpenGL painters where I've eliminated k3d::mesh_selection in
favor of the (new, generic) k3d::selection::set.  Is selection data
something that is getting cached too?

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Wed, May 27, 2009 at 7:11 AM, Timothy M. Shead <tshead@...> wrote:
> So, this increasingly points to a world where the cache is an
> associative container templated on key and value types, which is where I
> was leaning anyway - anything else would have involved some kind of
> downcasting of value pointers.  It introduces some complexity by leading
> to multiple caches (one per key/value type), but I think that's manageable.

Yes, I agree, and this was in fact already so in the old
implementation, only I never used the option to vary the key type and
stuck with the mesh address. I've updated the proposal with an
interface for the cache manager, and a proposal for the cached data
base class. With the latter, I see no way around adding a
"set_input_mesh" method in order to make the mesh data available to
the update slot. This means things will fail if the "client" does not
call set_input_mesh before getting the value. This is countered by the
fact that the only client is the cache manager.

> BTW, as background I'm currently working on generic selections (which go
> hand-in-hand with generic primitives).  I notice there's some breakage
> in the OpenGL painters where I've eliminated k3d::mesh_selection in
> favor of the (new, generic) k3d::selection::set.  Is selection data
> something that is getting cached too?

Yes, I forgot about that. It's added to the table on the wiki now. The
purpose is to store blocks of selection records, very similar to the
records in the SDK, so these can be painted in one call in the VBO
case and in the SDS painters. It is not used in the default GL
polyhedron painters.

Cheers,

--
Bart

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Wed, May 27, 2009 at 7:11 AM, Timothy M. Shead <tshead@...> wrote:
>> So, this increasingly points to a world where the cache is an
>> associative container templated on key and value types, which is where I
>> was leaning anyway - anything else would have involved some kind of
>> downcasting of value pointers.  It introduces some complexity by leading
>> to multiple caches (one per key/value type), but I think that's manageable.
>
> Yes, I agree, and this was in fact already so in the old
> implementation, only I never used the option to vary the key type and
> stuck with the mesh address. I've updated the proposal with an
> interface for the cache manager, and a proposal for the cached data
> base class. With the latter, I see no way around adding a
> "set_input_mesh" method in order to make the mesh data available to
> the update slot. This means things will fail if the "client" does not
> call set_input_mesh before getting the value. This is countered by the
> fact that the only client is the cache manager.
>
>> BTW, as background I'm currently working on generic selections (which go
>> hand-in-hand with generic primitives).  I notice there's some breakage
>> in the OpenGL painters where I've eliminated k3d::mesh_selection in
>> favor of the (new, generic) k3d::selection::set.  Is selection data
>> something that is getting cached too?
>
> Yes, I forgot about that. It's added to the table on the wiki now. The
> purpose is to store blocks of selection records, very similar to the
> records in the SDK, so these can be painted in one call in the VBO
> case and in the SDS painters. It is not used in the default GL
> polyhedron painters.

I didn't get a chance to look this over yet, but I'll be checking it out
tomorrow.

Cheers!
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, May 28, 2009 at 8:14 AM, Timothy M. Shead <tshead@...> wrote:

> Bart Janssens wrote:
>> On Wed, May 27, 2009 at 7:11 AM, Timothy M. Shead <tshead@...> wrote:
>>> So, this increasingly points to a world where the cache is an
>>> associative container templated on key and value types, which is where I
>>> was leaning anyway - anything else would have involved some kind of
>>> downcasting of value pointers.  It introduces some complexity by leading
>>> to multiple caches (one per key/value type), but I think that's manageable.
>>
>> Yes, I agree, and this was in fact already so in the old
>> implementation, only I never used the option to vary the key type and
>> stuck with the mesh address. I've updated the proposal with an
>> interface for the cache manager, and a proposal for the cached data
>> base class. With the latter, I see no way around adding a
>> "set_input_mesh" method in order to make the mesh data available to
>> the update slot. This means things will fail if the "client" does not
>> call set_input_mesh before getting the value. This is countered by the
>> fact that the only client is the cache manager.

> I didn't get a chance to look this over yet, but I'll be checking it out
> tomorrow.

Great! That gave me the time to look things over one more time, and
get rid of the set_input_mesh method by simply making the mesh an
argument for the value() method.

Cheers,

--
Bart

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, May 28, 2009 at 8:14 AM, Timothy M. Shead <tshead@...> wrote:
> I didn't get a chance to look this over yet, but I'll be checking it out
> tomorrow.

I just realized there still may be a major flaw with the design.
Getting the correct key in mesh_changed requires access to the mesh
contents, which in turn would trigger a pipeline execution. I actually
ran into this before, which is why in the current implementation
mesh_instance caches a pointer to the mesh and ensures this pointer
never changes. To solve this in the new design, I'm thinking along
these lines:
- eliminate the mesh_changed function from the painter
- eliminate the public update methods from cached data and the cache manager
- when data is created upon the first call to paint_mesh, have the
cached data connect to the changed signal of the source property,
using hint mapping.

Not only does this solve the problem of premature pipeline execution,
but it also uses the signal system to pass along the hints, rather
than the manual calls to mesh_changed() and update(). All the signal
handling and connecting can be implemented in the cached data base
class, so actual cache implementations never need to worry about this.

In order to get access to the change signal, passing an imesh_source
instead of a mesh to paint_mesh seems like the most obvious way.

If you think this goes in the right direction, I'll update the wiki page.

Cheers,

--
Bart

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Thu, May 28, 2009 at 8:14 AM, Timothy M. Shead <tshead@...> wrote:
>> I didn't get a chance to look this over yet, but I'll be checking it out
>> tomorrow.
>
> I just realized there still may be a major flaw with the design.
> Getting the correct key in mesh_changed requires access to the mesh
> contents, which in turn would trigger a pipeline execution. I actually
> ran into this before, which is why in the current implementation
> mesh_instance caches a pointer to the mesh and ensures this pointer
> never changes. To solve this in the new design, I'm thinking along
> these lines:
> - eliminate the mesh_changed function from the painter
> - eliminate the public update methods from cached data and the cache manager
> - when data is created upon the first call to paint_mesh, have the
> cached data connect to the changed signal of the source property,
> using hint mapping.
>
> Not only does this solve the problem of premature pipeline execution,
> but it also uses the signal system to pass along the hints, rather
> than the manual calls to mesh_changed() and update(). All the signal
> handling and connecting can be implemented in the cached data base
> class, so actual cache implementations never need to worry about this.
>
> In order to get access to the change signal, passing an imesh_source
> instead of a mesh to paint_mesh seems like the most obvious way.
>
> If you think this goes in the right direction, I'll update the wiki page.

A few things come to mind:

* Given the right set of hints, the original problem (trying to execute
the pipeline during an update) goes away on its own ... for example, a
hint could contain a pointer to the mesh that's changing, or the
primitive, or even the array ... all that information can be cached by
the receiver (that's what pointer_demand_storage does).

* Given the above, I'm strongly against having mesh painters take
imesh_source as input.  It would be a strange choice of parameter, and
forces painters to become experts on nodes, whereas today they have a
laser-like focus on one thing: painting meshes.

* In general, it doesn't make sense for MeshPainterLinks to take an
arbitrary mesh / mesh source as input, since they'd lack a transformation.

* The notion of being able to eliminate ipainter::mesh_changed is
appealing at first glance, might have to sleep on it.  In general, the
cache needs to be an optional optimization that painters can use/not use
based on the whim of the developer.

Cheers,
Tim


[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sat, Jun 6, 2009 at 5:28 AM, Timothy M. Shead<tshead@...> wrote:
> * Given the right set of hints, the original problem (trying to execute
> the pipeline during an update) goes away on its own ... for example, a
> hint could contain a pointer to the mesh that's changing, or the
> primitive, or even the array ... all that information can be cached by
> the receiver (that's what pointer_demand_storage does).

Unfortunately, this would not work. I looked at the tweak_points
(still in the development module, I should fix that) code to see if
this could be done, but even to tweak_points the pointer value of the
points array is unknown at the time the hint is emitted. The call to
points.writable() only happens during execution, and only then the
value of the key (points array address in this case) is known.

> * Given the above, I'm strongly against having mesh painters take
> imesh_source as input.  It would be a strange choice of parameter, and
> forces painters to become experts on nodes, whereas today they have a
> laser-like focus on one thing: painting meshes.

True, it's not as clean as passing an actual mesh, but an imesh_source
still strongly indicates we're talking about a mesh, and getting the
mesh itself is just one well-known API call.

> * In general, it doesn't make sense for MeshPainterLinks to take an
> arbitrary mesh / mesh source as input, since they'd lack a transformation.

Yes, I don't have strong feelings about this, but I thought it might
be useful in case someone wants to see an intermediate pipeline step
without instantiating it.

> * The notion of being able to eliminate ipainter::mesh_changed is
> appealing at first glance, might have to sleep on it.  In general, the
> cache needs to be an optional optimization that painters can use/not use
> based on the whim of the developer.

Eliminating mesh_changed more strongly emphasizes the optional nature
of the cache, since the method is only used in a situation with
caches. Either way, the supplied mesh argument can never be an
up-to-date mesh, since getting that needs a pipeline execution. The
decision to use a cache is taken entirely in the paint_mesh and
select_mesh methods, by calling get_cached_data.

Cheers,

--
Bart

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Sat, Jun 6, 2009 at 5:28 AM, Timothy M. Shead<tshead@...> wrote:
>> * Given the right set of hints, the original problem (trying to execute
>> the pipeline during an update) goes away on its own ... for example, a
>> hint could contain a pointer to the mesh that's changing, or the
>> primitive, or even the array ... all that information can be cached by
>> the receiver (that's what pointer_demand_storage does).
>
> Unfortunately, this would not work. I looked at the tweak_points
> (still in the development module, I should fix that) code to see if
> this could be done, but even to tweak_points the pointer value of the
> points array is unknown at the time the hint is emitted. The call to
> points.writable() only happens during execution, and only then the
> value of the key (points array address in this case) is known.

Agreed, but on some level this approach doesn't really change the
underlying problem, it just means that we're using the node as the key
because it's stable, instead of something more appropriate.  I'd like to
explore figuring-out what the "something more appropriate" might be
before falling-back on this approach.

So in a nutshell: the NewTweakPoints modifier needs to emit the
appropriate hint whenever the new points array changes.  The main
problem is that the output mesh might not exist yet.  Even if the output
mesh exists, the new points array might not exist.  Everything has to
happen without executing.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sun, Jun 7, 2009 at 4:56 PM, Timothy M. Shead<tshead@...> wrote:
> Agreed, but on some level this approach doesn't really change the
> underlying problem, it just means that we're using the node as the key
> because it's stable, instead of something more appropriate.  I'd like to
> explore figuring-out what the "something more appropriate" might be
> before falling-back on this approach.

No! I didn't make myself clear enough: they part about keys remains
unchanged from what is on the wiki page, i.e. array pointers or
primitive pointers. The change is simply the removal of mesh_changed,
and having the cached data connect to the mesh's changed signal
directly. All cache initialization and reading now happens in the
paint_mesh/select_mesh methods, which is the point where the pipeline
is executed and all data is known. As an added benefit, all hint
passing now happens through the standard hint mapping system, with no
more need for the mesh_changed method.

What is left to decide is: "How do we pass the change signal to the
cached data?". Using imesh_source as argument for paint/select_mesh is
one possibility, retaining the mesh argument but adding the change
signal as extra argument is another.

Cheers,

--
Bart

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Sun, Jun 7, 2009 at 4:56 PM, Timothy M. Shead<tshead@...> wrote:
>> Agreed, but on some level this approach doesn't really change the
>> underlying problem, it just means that we're using the node as the key
>> because it's stable, instead of something more appropriate.  I'd like to
>> explore figuring-out what the "something more appropriate" might be
>> before falling-back on this approach.
>
> No! I didn't make myself clear enough: they part about keys remains
> unchanged from what is on the wiki page, i.e. array pointers or
> primitive pointers. The change is simply the removal of mesh_changed,
> and having the cached data connect to the mesh's changed signal
> directly. All cache initialization and reading now happens in the
> paint_mesh/select_mesh methods, which is the point where the pipeline
> is executed and all data is known. As an added benefit, all hint
> passing now happens through the standard hint mapping system, with no
> more need for the mesh_changed method.
>
> What is left to decide is: "How do we pass the change signal to the
> cached data?". Using imesh_source as argument for paint/select_mesh is
> one possibility, retaining the mesh argument but adding the change
> signal as extra argument is another.

Fair enough - your second suggestion here sounds like a winner.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Mon, Jun 8, 2009 at 7:18 AM, Timothy M. Shead<tshead@...> wrote:
>> What is left to decide is: "How do we pass the change signal to the
>> cached data?". Using imesh_source as argument for paint/select_mesh is
>> one possibility, retaining the mesh argument but adding the change
>> signal as extra argument is another.
>
> Fair enough - your second suggestion here sounds like a winner.

OK, I've updated the wiki to reflect the changes. It looks to me like
this is ready to be implemented, and it should be a big improvement
over the way it works right now.

Cheers,

--
Bart

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

> On Mon, Jun 8, 2009 at 7:18 AM, Timothy M. Shead<tshead@...> wrote:
>>> What is left to decide is: "How do we pass the change signal to the
>>> cached data?". Using imesh_source as argument for paint/select_mesh is
>>> one possibility, retaining the mesh argument but adding the change
>>> signal as extra argument is another.
>>
>> Fair enough - your second suggestion here sounds like a winner.
>
> OK, I've updated the wiki to reflect the changes. It looks to me like
> this is ready to be implemented, and it should be a big improvement
> over the way it works right now.

There are still some issues to address, in no particular order:

* Let's give cache_manager a better name, say "painter_cache", and make it
more consistent with other associative containers.

* Not sure whether you intended to make "cached_data" a base-class or just
an example; I'd prefer that it just be an example - individual cache types
should process the hints that they understand, rather than having a bunch
of callbacks in a base class.

* The current set of geometry-related hints was developed a long time ago
and in the absence of real world experience; let's create a concrete list
of hints that are based on our list of cached data and experience with
filters such as TweakPoints.  In general, I expect the current set of
hints - and the data included with individual hints - to grow.

* Looking at TweakPoints, I see some properties that make very little
sense to me; my expectation is that TweakPoints would have a single
property containing a list of vertex indices and coordinates.  What are
the other properties doing?  Let's have a thorough understanding of how
TweakPoints should work, and the hints involved, before implementing
anything.

Cheers,
Tim


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, Jun 11, 2009 at 3:14 PM, Timothy M. Shead <tshead@...> wrote:
> * Let's give cache_manager a better name, say "painter_cache", and make it
> more consistent with other associative containers.

The name is changed, but can you elaborate on what you mean with "more
consistent with other associative containers"? Retrieving data
requires two additional arguments, aside from the key, so having
something like operator[] seems difficult.

> * Not sure whether you intended to make "cached_data" a base-class or just
> an example; I'd prefer that it just be an example - individual cache types
> should process the hints that they understand, rather than having a bunch
> of callbacks in a base class.

I had thought of this as a base class, as is done with the bitmap
modifiers in the SDK. But we can re-evaluate this once the list of
hints is updated. The advantage is that individual cache writers don't
need to worry about the hint-mapping in the constructors.

> * The current set of geometry-related hints was developed a long time ago
> and in the absence of real world experience; let's create a concrete list
> of hints that are based on our list of cached data and experience with
> filters such as TweakPoints.  In general, I expect the current set of
> hints - and the data included with individual hints - to grow.

OK, I'll give this some more thought.

> * Looking at TweakPoints, I see some properties that make very little
> sense to me; my expectation is that TweakPoints would have a single
> property containing a list of vertex indices and coordinates.  What are
> the other properties doing?  Let's have a thorough understanding of how
> TweakPoints should work, and the hints involved, before implementing
> anything.

I've described the current design and a proposal for an update at
http://www.k-3d.org/wiki/User:Barche/TweakPoints

Cheers,

--
Bart

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> On Thu, Jun 11, 2009 at 3:14 PM, Timothy M. Shead <tshead@...> wrote:
>> * Let's give cache_manager a better name, say "painter_cache", and make it
>> more consistent with other associative containers.
>
> The name is changed, but can you elaborate on what you mean with "more
> consistent with other associative containers"? Retrieving data
> requires two additional arguments, aside from the key, so having
> something like operator[] seems difficult.

What particularly caught my eye was that the key and value types were
switched around ...

>> * Not sure whether you intended to make "cached_data" a base-class or just
>> an example; I'd prefer that it just be an example - individual cache types
>> should process the hints that they understand, rather than having a bunch
>> of callbacks in a base class.
>
> I had thought of this as a base class, as is done with the bitmap
> modifiers in the SDK. But we can re-evaluate this once the list of
> hints is updated. The advantage is that individual cache writers don't
> need to worry about the hint-mapping in the constructors.

Cool.

>> * Looking at TweakPoints, I see some properties that make very little
>> sense to me; my expectation is that TweakPoints would have a single
>> property containing a list of vertex indices and coordinates.  What are
>> the other properties doing?  Let's have a thorough understanding of how
>> TweakPoints should work, and the hints involved, before implementing
>> anything.
>
> I've described the current design and a proposal for an update at
> http://www.k-3d.org/wiki/User:Barche/TweakPoints

Looks reasonable.  You might make it clear that the tweaks are an
ordered list of point values, not vectors - i.e. tweaks are not
cumulative.  That makes life much, much easier for a tool.

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Tue, Jun 23, 2009 at 7:57 AM, Timothy M. Shead <tshead@...> wrote:
> What particularly caught my eye was that the key and value types were
> switched around ...

OK, changed that for the class, but not for the convenience method,
since this way of doing it saves typing when getting cached data.

> > I had thought of this as a base class, as is done with the bitmap
> > modifiers in the SDK. But we can re-evaluate this once the list of
> > hints is updated. The advantage is that individual cache writers don't
> > need to worry about the hint-mapping in the constructors.

I've added a list

> >> * Looking at TweakPoints, I see some properties that make very little
> >> sense to me; my expectation is that TweakPoints would have a single
> >> property containing a list of vertex indices and coordinates.  What are
> >> the other properties doing?  Let's have a thorough understanding of how
> >> TweakPoints should work, and the hints involved, before implementing
> >> anything.
> >
> > I've described the current design and a proposal for an update at
> > http://www.k-3d.org/wiki/User:Barche/TweakPoints
>
> Looks reasonable.  You might make it clear that the tweaks are an
> ordered list of point values, not vectors - i.e. tweaks are not
> cumulative.  That makes life much, much easier for a tool.
>
> Cheers,
> Tim
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> K3d-development mailing list
> K3d-development@...
> https://lists.sourceforge.net/lists/listinfo/k3d-development
>

--
Bart Janssens

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development