Ulrich Hertlein wrote:
> This sounds like a good solution, it keeps API compatibility but only
> stores one object instead of _userData/_descriptions in every
> Object/Node created.
This sounds good. I had forgotten that access to UserData was only through
the set/get
API. Perfect.
> So many b
Hi Robert, Chris, Paul,
On 1/12/09 10:45 AM, Robert Osfield wrote:
The existing style UserData and Descriptions could be stored in the
exactly the same way as they are now, only shifted into the
CompositeUserData structure. The additional new key based stored
could be added alongside these.
T
Hi Paul,
On Mon, Nov 30, 2009 at 8:23 PM, Paul Martz wrote:
> Chris 'Xenon' Hanson wrote:
>>
>> Isn't this breaking all existing code that uses UserData/Description
>> though?
>
> It's not as bad as you might think. If someone were to add CompositeUserData
> to OSG, they'd need to port all (inte
Hi Chris,
On Mon, Nov 30, 2009 at 5:59 PM, Chris 'Xenon' Hanson
wrote:
> Robert Osfield wrote:
> Isn't this breaking all existing code that uses UserData/Description though?
No, no user code need be change, you can hide all the internal
implementation details via the methods that access getUser
Paul Martz wrote:
> It's not as bad as you might think. If someone were to add
> CompositeUserData to OSG, they'd need to port all (internal) OSG code to
> use the new system. External apps that use UserData would not be
> compatible with the new system until their authors take the time to
> port,
Chris 'Xenon' Hanson wrote:
Isn't this breaking all existing code that uses UserData/Description though?
It's not as bad as you might think. If someone were to add
CompositeUserData to OSG, they'd need to port all (internal) OSG code to
use the new system. External apps that use UserData wo
Robert Osfield wrote:
> Description kinda bloat osg::Node already, I would like to reduce this
> bloat and stream line the base classes even more ;-)
> I would also like generalize UserData but... not use any more than the
> present pointer that we already have in place, don't forget we need to
> a
Hi Chris, Paul, Ulrich,
I won't dive in to much right now as I have enough other topics
swishing around in my skull to keep me occupied, but a few general
notes.
Description kinda bloat osg::Node already, I would like to reduce this
bloat and stream line the base classes even more ;-)
I would al
Paul Martz wrote:
> data. Unfortunately, that doesn't work with other OSG code that is not
> under my control.
> I'd be glad to implement something like this in osgWorks.googlecode.com,
> but it would have to ride on UserData rather than be a part of core OSG,
> which would put it in conflict with
Chris 'Xenon' Hanson wrote:
Mattias Helsing wrote:
Hi Chris,
Is there a reason to why you don't use setUserData(osg::Referenced*) ?
If you provide the proper read/write routines for your osg::Referenced
derived class it would also persist across .osg file writes/reads.
Because there's only o
Ulrich Hertlein wrote:
> Hi Chris,
> have you noticed the "Suggestion: Add components in nodes (aggregation)"
> thread from around 29/10/2009?
I had missed it, but it sounds very interesting.
> Of course this doesn't yet solve your problem with there being only one
> user-data field. The pro
Hi Chris,
have you noticed the "Suggestion: Add components in nodes (aggregation)" thread from
around 29/10/2009? It deals with something similar, namely to introduce something like a
osg::KeyValueMap (derived from osg::Referenced) that can be attached to osg::Objects as
user-data. (These co
Mattias Helsing wrote:
> Hi Chris,
> Is there a reason to why you don't use setUserData(osg::Referenced*) ?
> If you provide the proper read/write routines for your osg::Referenced
> derived class it would also persist across .osg file writes/reads.
Because there's only one UserData, and in my l
Hi Chris,
Is there a reason to why you don't use setUserData(osg::Referenced*) ?
If you provide the proper read/write routines for your osg::Referenced
derived class it would also persist across .osg file writes/reads.
Mattias
On Sun, Nov 29, 2009 at 11:10 PM, Chris 'Xenon' Hanson
wrote:
> I'm
I'm looking for a way to annotate nodes with numeric information at runtime.
The data
need not be stored during scenegraph writes, but I don't mind if it is. I've
used the
Description before for similar purposes, but you can't precisely and reversibly
store a
floating-point value in a string.
15 matches
Mail list logo
