Hi Chris,
On Mon, Nov 30, 2009 at 5:59 PM, Chris 'Xenon' Hanson
xe...@alphapixel.com 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
Hi Paul,
On Mon, Nov 30, 2009 at 8:23 PM, Paul Martz pma...@skew-matrix.com 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
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.
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
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
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
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 any
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
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
aim
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.
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
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
12 matches
Mail list logo
