On 2/4/2011 5:28 AM, Sukender wrote:
Hi Ulrich, Robert, and all,
Ulrich, your idea seem briliant. When I was talking about overwrit[ing]
existing userData I thought about direct pointer access. Of course, if you
move userData to private, and give accessors for backward compatibility, then
On 4/02/11 3:21 , Sukender wrote:
Ulrich is right: you could move your data as a metadata. However I guess that
we should
not break existing code. (De)Serializers should NEVER overwrite existing
userData, they
should only be allowed to add metadata it userData points to a meta
container.
Hi Ulrich, Robert, and all,
Ulrich, your idea seem briliant. When I was talking about overwrit[ing]
existing userData I thought about direct pointer access. Of course, if you
move userData to private, and give accessors for backward compatibility, then
it's okay. That way, it would only break
On 3/02/11 3:47 , Bob Youmans wrote:
What will the users do, who current utilize the userData in the node for
their own
specialized purposes? Is this going to break our models?
I don't see a reason why user-data shouldn't be stored as another type of
meta-data.
So it should be fully
Hi Bob,
Ulrich is right: you could move your data as a metadata. However I guess that
we should not break existing code. (De)Serializers should NEVER overwrite
existing userData, they should only be allowed to add metadata it userData
points to a meta container. So if you already use userData,
I concur, in order to avoid disrupting existing users, metadata should
only be read/written to if UserData is empty or already contains a
metadata object. Possibly we could have an abstract metadata or
de/serializable interface so that users could retroactively support
their existing UserData
-users] Discussion: metadata readerwriters output
Hi Robert,
Hi Peter, Robert, and all
Thanks... but this is my first post... I've been happily watching the
discussion so I can't take any credit, apart for great patience ;-)
Ahah! This was an insidious way to get your attention! You fell
Subject: Re: [osg-users] Discussion: metadata readerwriters output
On 1/31/2011 9:00 AM, Sukender wrote:
Hi Paul,
Thanks for this explanation about identifying nodes. Actually we
also implemented a node identification using child index...
However I did not spot metadata related classes
Some kind of user data hooks are necessary, since the user is always
going to need a way to map the results of operations like
IntersectVisitor back to the application domain. The benefit of adding
a baseline metadata system as standard (as opposed to the current
do-what-ever-you-want situation
Hi Peter, Robert, and all
Thank you for your ideas. I think the metadata container put in userData is the
simplest way. And I fully agree there should be some minimal base classes to
support it in core OSG.
So... Who's for that solution? If so, any idea about implementation details, or
Hi Sukender,
On Tue, Feb 1, 2011 at 4:26 PM, Sukender suky0...@free.fr wrote:
Hi Peter, Robert, and all
Thanks... but this is my first post... I've been happily watching the
discussion so I can't take any credit, apart for great patience ;-)
Thank you for your ideas. I think the metadata
Hi Paul,
Thanks for this explanation about identifying nodes. Actually we also
implemented a node identification using child index...
However I did not spot metadata related classes in osgWorks. Well, ok, I just
had a very quick overview... Can you tell me where to look at?
Thanks.
Sukender
On 1/31/2011 9:00 AM, Sukender wrote:
Hi Paul,
Thanks for this explanation about identifying nodes. Actually we also
implemented a node identification using child index...
However I did not spot metadata related classes in osgWorks. Well, ok, I just
had a very quick overview... Can you tell
...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz
Sent: Monday, January 31, 2011 11:18 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Discussion: metadata readerwriters output
On 1/31/2011 9:00 AM, Sukender wrote:
Hi Paul,
Thanks for this explanation
Hi Sukender,
On 28/01/11 20:54 , Sukender wrote:
** Topic **
More generally, it is hard to store and pass not predifined variables
between main
program and plugins, or between OSG itself and the main program (I mean
adding some
type-safe user values to the graph).
This makes me think
Hi Robert, hi (SELECT name FROM OSG_USERS WHERE nameRobert Osfield;),
** Context **
I spotted the DAE plugin is able to return some values to the calling program
by writing in the plugin data (options-getPluginData()). But when writing,
this plugin data is... const! This thus requires an ugly
Hi Peter, Robert, all
Thanks for your ideas, Peter.
I really appreciate the proposal of having values in a separate structure with
weak references. But is this a singleton? If so, how would you handle the case
where you have to process things between two models (say you want to load two
files
If a specific node in a scene graph can be reliably identified, application data
can be stored separately from the scene graph. Unfortunately, OSG's mechanism
for identifying a node (the NodePath) is address-based, making it unsuitable for
this task, as addresses change from one app invocation
18 matches
Mail list logo
