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

[Timothy M. Shead]

Bart Janssens wrote:

> On Wed, May 21, 2008 at 9:35 AM, Bart Janssens
> <bart.janssens@...> wrote:
>  
>> On 5/21/08, Timothy M. Shead <tshead@...> wrote:
>>    
>>> One item of concern is that the selection state of a node does affect
>>> how it is rendered, so we need to ensure that we aren't doing an
>>> expensive lookup at render-time.
>>>      
>> The selection weight is still stored in the nodes, so no lookup is
>> necessary. As an aside, I guess the iselectable interface should not
>> be marked as deprecated, as it's still used by nodes?
>>    
>
> 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.
* I'd rather not have selection-state in two places (the central list of
selections and the nodes themselves).
* If we put the selection state in a document plugin, it could be
serialized.
* The hypothetical selection-state plugin would be comparable to a
time-source, in that it has "special" significance to the UI.
* I'm liking the property-metadata concept so much that I could see
providing node-metadata that would address some of the problems of
having these sorts-of "special" nodes.

Cheers,
Tim


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Joe Crawford]

On Mon, Jun 9, 2008 at 5:00 PM, Timothy M. Shead <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.

This probably should really affect the main selection design though. It would be easy to have an extra attribute for "how strongly they were selected" that was separate from the real selection.

Sincerely,

Joe Crawford
___________________________________
Owner - Celestine Studios and Joetainment Enterprises
Cell: 604-866-3050
Email: joetainment@...
Web: http://celestinestudios.com
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

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.

Cheers,
Tim


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Joe Crawford]

On Wed, Jun 18, 2008 at 10:22 PM, 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?

Yes, basically to handle situations like this:

There's a whole bunch of cubes on a plane. You want to grab some and spread them out by moving them, you grab the farthest one to the right, and drag it away from the rest of the pile. The ones nearby move along with in somewhat, because of their soft selection. This way, its easy to spread them all out.
 
Its not very important right now, but it would seem like it could work pretty easily, so it would be nice to allow for that down the road.

Sincerely,

Joe Crawford
___________________________________
Owner - Celestine Studios and Joetainment Enterprises
Cell: 604-866-3050
Email: joetainment@...
Web: http://celestinestudios.com
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development