Re: Node selection storage [was:] Bypassing MergeMesh [was:] Merge Mesh properties was: Property groups

[bART Janssens-2]

On Thu, Jun 19, 2008 at 8:22 AM, Timothy M. Shead <tshead@...> wrote:

> Joe Crawford wrote:
>> On Mon, Jun 9, 2008 at 5:00 PM, Timothy M. Shead <tshead@...
>> <mailto:tshead@...>> wrote:
>>
>>     >
>>     > Any more thoughts on
>>     http://www.k-3d.org/wiki/User:Barche/Node_Selection_Storage?
>>     >
>>     I know I'm being slightly contradictory here on the performance
>>     issue, but:
>>
>>     * I still think iselectable can be deprecated, I can't see any reason
>>     why node selections should be fuzzy (unlike gprim selections).  Unless
>>     Joe suggests otherwise.
>>
>>
>> Its probably not important now, but it would be cool if tools could
>> have soft selection at the object level.
> Just to clarify: we have soft selections at a component level, you're
> advocating that we also retain soft selections at a node level, is that
> correct?
>
> Assuming yes, this would mean that we need something other than an
> inode_collection_property for our hypothetical "document selection"
> storage node - which isn't a problem, just an observation.

I've updated http://www.k-3d.org/wiki/User:Barche/Node_Selection_Storage
to account for this. If it's cleared, I can move it to another module
(selection, I guess) and adapt the UI layer to use it. Will I also
need to add meta-data to the node? It will implement the
inode_selection interface, which could also be used to identify it.

Cheers,

--
Bart

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
> I've updated http://www.k-3d.org/wiki/User:Barche/Node_Selection_Storage
> to account for this. If it's cleared, I can move it to another module
> (selection, I guess) and adapt the UI layer to use it. Will I also
> need to add meta-data to the node? It will implement the
> inode_selection interface, which could also be used to identify it.
>  
Some observations:

* Not sure why there are separate properties for nodes and weights.  
Logically, this is a single property.
* inode_collection_property is the wrong type of property here - let it go.
* I assume m_select_node is for testing?  It isn't correct property
usage in the long-term.
* You quote numbers for lookup times.  How are you testing this?

Tim

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



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Tue, Jul 8, 2008 at 6:38 AM, Timothy M. Shead <tshead@...> wrote:

> Bart Janssens wrote:
>> I've updated http://www.k-3d.org/wiki/User:Barche/Node_Selection_Storage
>> to account for this. If it's cleared, I can move it to another module
>> (selection, I guess) and adapt the UI layer to use it. Will I also
>> need to add meta-data to the node? It will implement the
>> inode_selection interface, which could also be used to identify it.
>>
> Some observations:
>
> * Not sure why there are separate properties for nodes and weights.
> Logically, this is a single property.
> * inode_collection_property is the wrong type of property here - let it go.

I've updated the prototype to address this.

> * I assume m_select_node is for testing?  It isn't correct property
> usage in the long-term.

Of course! Though in the mean time, I've added one more ;)

> * You quote numbers for lookup times.  How are you testing this?

I've automated the test I did previously, and committed it to SVN. My
result is at
http://www.k-3d.org/cdash/testDetails.php?test=28944&build=680

Cheers,

--
Bart

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:
>> * You quote numbers for lookup times.  How are you testing this?
>>    
>
> I've automated the test I did previously, and committed it to SVN. My
> result is at
> http://www.k-3d.org/cdash/testDetails.php?test=28944&build=680
>  
This is a start, albeit not an entirely realistic number.  I was never
worried about the time to lookup a node in the map; my concern is the
time to lookup the NodeSelection instance itself - probably, we will
want to make this part of the render state.

Cheers,
Tim

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



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Wed, Jul 9, 2008 at 5:06 AM, Timothy M. Shead <tshead@...> wrote:
> This is a start, albeit not an entirely realistic number.  I was never
> worried about the time to lookup a node in the map; my concern is the
> time to lookup the NodeSelection instance itself - probably, we will
> want to make this part of the render state.

Ah, yes. Good point, that would take much longer than the map lookup I
test now. I've added a new proposal for this at
http://www.k-3d.org/wiki/User:Barche/Special_Nodes

I agree that making the node part of the render state is good, though,
but to get it there we might make use of the above method.

Regards,

--
Bart

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Wed, Jul 9, 2008 at 5:06 AM, Timothy M. Shead <tshead@...> wrote:
>  
>> This is a start, albeit not an entirely realistic number.  I was never
>> worried about the time to lookup a node in the map; my concern is the
>> time to lookup the NodeSelection instance itself - probably, we will
>> want to make this part of the render state.
>>    
>
> Ah, yes. Good point, that would take much longer than the map lookup I
> test now. I've added a new proposal for this at
> http://www.k-3d.org/wiki/User:Barche/Special_Nodes
>
> I agree that making the node part of the render state is good, though,
> but to get it there we might make use of the above method.
>  

To clarify, I was suggesting that the *selection state* for a node be
stored in the render state.  That makes looking-up the selection state
the responsibility of a render-engine, which would be fine.  The
render-engine would have an inode* property where it keeps track of the
NodeSelection instance, and this property would be set by the UI layer
when a render-engine is created.  The nice thing about this approach is
that it is efficient, doesn't introduce any new interfaces or interface
methods, doesn't require any special serialization code, and allows for
special-cases in a simple and intuitive way - if you want to have a
viewport that doesn't highlight selected objects, just go to the Node
Property Panel for the render engine and set the "Node Selection"
property to "None".

Cheers,
Tim

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



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, Jul 10, 2008 at 7:27 AM, Timothy M. Shead <tshead@...> wrote:

> To clarify, I was suggesting that the *selection state* for a node be
> stored in the render state.  That makes looking-up the selection state
> the responsibility of a render-engine, which would be fine.  The
> render-engine would have an inode* property where it keeps track of the
> NodeSelection instance, and this property would be set by the UI layer
> when a render-engine is created.  The nice thing about this approach is
> that it is efficient, doesn't introduce any new interfaces or interface
> methods, doesn't require any special serialization code, and allows for
> special-cases in a simple and intuitive way - if you want to have a
> viewport that doesn't highlight selected objects, just go to the Node
> Property Panel for the render engine and set the "Node Selection"
> property to "None".

OK, agreed!

However, I still think having a central node to keep track of certain
often-referred nodes, such as the default painter, node selection,
time source, ... makes sense. We would only need one way to find that
node, then. This would make finding i.e. a default painter in scripts
much easier. Or is the current name-based lookup meant to be replaced
by node metadata?

Cheers,

--
Bart

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Thu, Jul 10, 2008 at 7:27 AM, Timothy M. Shead <tshead@...> wrote:
>  
>> To clarify, I was suggesting that the *selection state* for a node be
>> stored in the render state.  That makes looking-up the selection state
>> the responsibility of a render-engine, which would be fine.  The
>> render-engine would have an inode* property where it keeps track of the
>> NodeSelection instance, and this property would be set by the UI layer
>> when a render-engine is created.  The nice thing about this approach is
>> that it is efficient, doesn't introduce any new interfaces or interface
>> methods, doesn't require any special serialization code, and allows for
>> special-cases in a simple and intuitive way - if you want to have a
>> viewport that doesn't highlight selected objects, just go to the Node
>> Property Panel for the render engine and set the "Node Selection"
>> property to "None".
>>    
>
> However, I still think having a central node to keep track of certain
> often-referred nodes, such as the default painter, node selection,
> time source, ... makes sense. We would only need one way to find that
> node, then. This would make finding i.e. a default painter in scripts
> much easier. Or is the current name-based lookup meant to be replaced
> by node metadata?
>  

What is the difference between looking-up special-object "foo", and
looking-up special-object "bar", which has a reference to special-object
"foo"?

Not that there aren't lots of counterexamples in the current code, but I
see benefits to moving in the direction of "Parameterize From Above" ... see

http://accu.org/index.php/journals/1432

Cheers,
Tim

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



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, Jul 10, 2008 at 7:27 AM, Timothy M. Shead <tshead@...> wrote:

> To clarify, I was suggesting that the *selection state* for a node be
> stored in the render state.  That makes looking-up the selection state
> the responsibility of a render-engine, which would be fine.  The
> render-engine would have an inode* property where it keeps track of the
> NodeSelection instance, and this property would be set by the UI layer
> when a render-engine is created.  The nice thing about this approach is
> that it is efficient, doesn't introduce any new interfaces or interface
> methods, doesn't require any special serialization code, and allows for
> special-cases in a simple and intuitive way - if you want to have a
> viewport that doesn't highlight selected objects, just go to the Node
> Property Panel for the render engine and set the "Node Selection"
> property to "None".

I've added a "Migration" section to
http://www.k-3d.org/wiki/User:Barche/Node_Selection_Storage with a
rough outline of the steps needed to implement this. Is it OK like
that?

Cheers,

--
Bart

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Thu, Jul 10, 2008 at 7:27 AM, Timothy M. Shead <tshead@...> wrote:
>  
>> To clarify, I was suggesting that the *selection state* for a node be
>> stored in the render state.  That makes looking-up the selection state
>> the responsibility of a render-engine, which would be fine.  The
>> render-engine would have an inode* property where it keeps track of the
>> NodeSelection instance, and this property would be set by the UI layer
>> when a render-engine is created.  The nice thing about this approach is
>> that it is efficient, doesn't introduce any new interfaces or interface
>> methods, doesn't require any special serialization code, and allows for
>> special-cases in a simple and intuitive way - if you want to have a
>> viewport that doesn't highlight selected objects, just go to the Node
>> Property Panel for the render engine and set the "Node Selection"
>> property to "None".
>>    
>
> I've added a "Migration" section to
> http://www.k-3d.org/wiki/User:Barche/Node_Selection_Storage with a
> rough outline of the steps needed to implement this. Is it OK like
> that?
>  

Seems reasonable.

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