Hi Peter,
On Thu, Jun 9, 2011 at 10:07 PM, Peter Amstutz
peter.amst...@tseboston.com wrote:
I understand the circular reference problem with setting
_userDataContainer to this, so overriding get/setUserDataContainer()
and ignoring _userDataContainer seems like a reasonable solution to me.
Hi Robert, hi all,
first, thank you for what you've done with this project! I must say i didn't
expect the meta data to be in before the 3.0 ...
Right now, Sukender is more or less dying under his heavy workload, so I
think he reads his emails but unfortunately doesn't have enough time to
Hi Grogoire,
On Fri, Jun 10, 2011 at 2:58 PM, Gregoire Tarizzo
gregoire.tari...@virtuelcity.com wrote:
As for me I have two main questions:
1. This first question is not directly linked with the meta feature it's
just that i'm still very new to OSG and even more to serialization. How are
we
Hi All,
I wasn't planning to revist the user data implementation this week,
but the weaknesses in design has been lurking at the back of my mind,
it just wasn't as clean as I'd have liked. With the feature freeze
for 3.0 happening at the end of next week I couldn't help but want to
get the
Hi Robert, once again, we all really appreciate your work on Open Scene
Graph and on picking up this feature in particular. I've reviewed the
new check in, comments below --
On 6/9/2011 9:33 AM, Robert Osfield wrote:
With the C pointer trick in the bag it became a simple refactor of the
Hi Peter,
On Thu, Jun 9, 2011 at 4:02 PM, Peter Amstutz
peter.amst...@tseboston.com wrote:
I noticed that DefaultUserDataContainer does not set the parent
_userDataContainer field to this, nor does it override
getUserDataContainer() / setUserDataContainer(). I suppose this allows
meta-data
On 6/9/2011 11:54 AM, Robert Osfield wrote:
I debated setting the UserDataContainer's _userDataContainer to itself but it
woudl create a circular reference so ceratinly a no go.
Potentially you could override the Object::s/getUserDataContainer
methods to return self
but would in itself
Hi Peter,
On Tue, Jun 7, 2011 at 9:51 PM, Peter Amstutz
peter.amst...@tseboston.com wrote:
Thank you for taking up this task. While not central to the mission of
graphics rendering, this feature will certainly make writing
applications around OSG a little bit easier for all of us.
My
Hi All,
After my first cut of the new osg::Object::UserData functionality I've
been pondering on how best to provide the ability to customize the
data storage container, if at all. Simplicity and performance are the
key reasons for not providing the ability to customize the data
storage
Hello Robert,
Thank you for taking up this task. While not central to the mission of
graphics rendering, this feature will certainly make writing
applications around OSG a little bit easier for all of us.
My proposal for putting get/setUserValue convenience methods directly
osg::Object was
Hi Robert,
I have now checked the changes into svn/trunk so would appreciate
feedback on build and runtime of these latest changes, fingers crossed
the template and macros used won't introduce any platform portability
issues.
My x86 build seemed to go fine, as you can see on cdash. My x64 one
Hi All,
After quite a few trials I have now got serialization working for the
new osg::Object user object support and the associated
osg::ValueObject. I believe what I have implemented is a reasonable
first stab at a basic user object scheme and should solve a range of
problems relating to
Hi Peter,
I'm open to suggestions on making the implementation more flexible,
however, any extra complexity has to be strongly justified - i.e. with
concrete usage case, so could you flesh out what you'd want to do with
the subclassing from UserDataContainer.
Another route for adding extra
Hi Robert, hi all,
Sorry for being silent these days... I just got back on the OSG development.
Well I've read your posts and I must admit I'm a bit disapointed because
proposed changes seem rather radical to me, and implies some features will be
dropped/reduced...
The backwards
Hi Sukender,
On Wed, Jun 1, 2011 at 2:00 PM, Sukender suky0...@free.fr wrote:
Well I've read your posts and I must admit I'm a bit disapointed because
proposed changes seem rather radical to me, and implies some features will be
dropped/reduced...
I'm striving to find a good balance between
Hi All,
On Tue, May 31, 2011 at 5:01 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Right now my main priority is working out how to provide the IO support
Yesterday afternoon and this morning I tried to get serializer support
working, and it now
works for osg::Object subclasss that provide
Hi All,
This morning I've been experimenting with extending the user data
support in the OSG, along the lines set out by Sukender. I've tried
to keep the class count down, and keep the user interface relatively
straight forward. Implementation wise I have gone for an
Hi Robert,
Just an observer of the thread ... I like what you've done so far, as I
think it has far more reaching applications (even outside of OSG). I've
put together something similar on a separate project that doesn't use
OSG. The biggest issue that I found was how to handle getting/setting
Hi Robert,
This is great! Being able to store meta-data in any osg::Object derived
class has been something we've wanted for a while now.
Regarding serialization, will your changes break loading of older models
that contained node descriptions? This is a big concern for us because we
have
Hi Chuck,
On Tue, May 31, 2011 at 4:44 PM, Chuck Cole charles.e.c...@nasa.gov wrote:
Just an observer of the thread ... I like what you've done so far, as I
think it has far more reaching applications (even outside of OSG). I've
put together something similar on a separate project that
Hi Farshid,
On Tue, May 31, 2011 at 5:01 PM, Farshid Lashkari fla...@gmail.com wrote:
Regarding serialization, will your changes break loading of older models
that contained node descriptions? This is a big concern for us because we
have hundreds of models that contain description strings.
I
Hi Robert,
That definitely sounds very sensible as it can get out of hand very
quickly. In fact, what you present as an example is exactly what I
ended up doing (i.e., implementing numerous methods such as
getVariableAsFloat, getVariableAsInteger, etc.). But I wasn't sure
which way you were
Hi Robert,
This looks pretty straightforward and I agree that less complexity is
good. However a would modify it slightly to support two related
features I have been lobbying for, which are the ability to share
UserDataContainers between osg::Objects, and the ability to subclass a
custom
Hi All,
Last Friday I dived in and did my first pass review of Sukender's work
on a meta data system for the OSG. Now that I've got the 2.9.15 dev
release out the door I've returned for a second look. My current
reaction is that it feels rather too complicated and with it a bit
awkward to
Hi DJ,
You're welcome! And thank you for exposing your thoughts.
Well, you're right, the problem has always been there. And of course,
removing the container will remove userData and descriptionList. However I
think that a developer removing the container MUST know what (s)he's doing. You
Hi Sergey,
Thank you for the links.
You're right when saying variant causes a lot of issues. I won't bring an
answer about Variant here, but just some points about the current design:
I must say I wondered about adding a support for basic types (conversion
from/to int/string/double...). The
Hello Sukender,
In response to your backward compatibility suggestions, I believe clear
documentation is the key, and I believe you all are off to a good start in
that regard.
Inlining the deprecated functions with appropriate comment is a good start
for clear documentation in the source code.
Hi Gregoire, Sukender, and everyone,
While writing this email, I have come to the conclusion that I/we do not
really have anything (more) to be concerned about with tying user data and
description list to the meta-data system. If you are interested in some of
the concerns I already had, and that
Hi D.J. , hi all,
First, thanks a lot to all, for your feedback and ideas. I’ve been following
with a lot of interest your ideas and propositions on this topic and it helped
us a lot. The v5 of the documentation will be out soon (likely monday), with
more detailed information and the latest
Hi Sukender and fellow interested parties,
I've finally had a chance to review your meta-data doc (version 4) to see
what you all have been designing, and how we might be able to use it in our
project.
Overall, I must say the design looks good. I really appreciate the effort
you have put into
Hi, all...
I just realized, if you write your proxy correctly, your original class
ValueT probably works just fine for more exotic types (when T is your
proxy class giving access to the underlying type), without my proposed
interface layer. In fact, for purposes of reference semantics, the
Hi all,
this meta system looks very interesting. I started to implement such a system
for osgVisual for data management, but it seems that your approach is much more
sophisticated and finally allows me to plug in my use cases quite easy.
I'm happy that such a framework is developed for OSG. I
Hi Peter, hi all,
We're working on impementing the meta-data system. We found that there was very
few feedback, and feel it's a bad sign of inacceptance of it... Anyone?
Peter, when you told about immutability, it was with a database backend in
mind, right? If so, I think it may be better not
Hi Sukender,
On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote:
We're working on impementing the meta-data system. We found that there was
very few feedback, and feel it's a bad sign of inacceptance of it... Anyone?
I don't have any comments beyond what others have added so
Keep up the good work :-)
Nice to read it, Robert! ;) And you're right, keep your mind resources for all
other important things here!
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Robert Osfield robert.osfi...@gmail.com a écrit :
Hi
Hi Sukender,
I, too, have been following this thread with interest. I have not had the
time or resources to go over your documentation, yet, but I hope to do so
soon.
In my current project, we have adapted the osg::Node::DescriptionList to
store some basic run time data at the node level. My
Thanks DJ.
I must say the conversion of our project to the new meta-data system is not
that instant... Hopefully the code is 99% backward compatible and the use of
userData and Description list still work as expected.
Sukender
PVLE - Lightweight cross-platform game engine -
On 4/27/2011 8:41 AM, D.J. Caldwell wrote:
Hi Sukender,
I, too, have been following this thread with interest. I have not had the
time or
resources to go over your documentation, yet, but I hope to do so soon.
Likewise, I'm interested, and I trust you know what you're doing. At the
Sorry about that, you sent out the previous email on the weekend and I
didn't have a chance to look at it; when Monday rolled around I had
forgotten about it.
Regarding the Value class, I think I understand the difference of
opinion a little better. Let me present both sides.
// Option A.
Hi Peter,
Your analysis seems fine. However, I must add a precision: In the current
design, there is a ValueBase class (actually an empty class derived from
Referenced). This way it's a bit easier dealing with values as the base class
is not templated. Well, not something enough to change your
Hi Sergey,
Thanks for the link. However I think the entity thing is far more high level
than just metas. Are you thinking about something specific metas should
support? If so, I would certainly try to insert the requirements.
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine -
I think the metadata system under discussion will be useful for
associating scene graph nodes with their owner entities. This is
necessary for various scene-graph oriented operations like picking,
custom culling, etc that need to refer back to your application domain
entities . You certainly
Hi Peter and Sergey,
Well for now serialization of userData is made blindly. I guess unsafe things
will be serialized the same way.
And yes, I guess metadata will be a base for more applications, but as long as
there is no hard requirement in the basement, I don't think about coding
things
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant to be
derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you mean you
preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes.
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Peter Amstutz
On 4/19/2011 5:49 AM, Sukender wrote:
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
You're right, that is confusing. Here's a better way to compare the
Immutable means cannot be changed. So I mean that the Value class
should not have a set method and all get methods should be const. E.g.
templateT
class Value {
private:
T v;
public:
Value(const T _v) : v(_v) { }
const T get() { return v; }
// type conversion operator, so you can
Hi JS,
About other serializers (Collada, FBX...), I guess it would be nice using the
OSG serialization (as you say), or a default/fallback one.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly
My initial impression is that this seems pretty well thought out, but a
little incomplete. Some comments:
- The ComponentContainer interface is lacking a way to iterate over all
values.
- The add/find/delete methods on ComponentContainer should take the
owner osg::Object as a parameter. This
Hi Peter,
- For serialization, storing simple value types is pretty
straightforward. The harder part is dealing with compound types
(structs/classes) and/or containers (map/vector). Perhaps there is a
way to leverage osgIntrospection?
I think the new serializers make it simple to make new
Hi Peter,
Well observed. We'll add methods to iterate and a pointer to object.
But we just spotted a flaw in our design: we wrote some virtual templated
methods (which is impossible of course)... Any idea on how to return a T* in
ComponentContainer::findFirstMeta()?
Sukender
PVLE -
Hi J-S,
Actually I hoped someone would help us on the serialization subject! And yes, I
guess new serializers may help. But what about formats supporting metas? It may
be helpful to add somewhere a callback/serializer/anything, which may be called
by plugins to convert from/to a string
Put the dynamic_castT inside the method.
On 4/15/2011 10:53 AM, Sukender wrote:
Hi Peter,
Well observed. We'll add methods to iterate and a pointer to object.
But we just spotted a flaw in our design: we wrote some virtual templated
methods (which is impossible of course)... Any idea on
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this will force you
to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight
Hi Sukender,
Actually I hoped someone would help us on the serialization subject! And yes, I
guess new serializers may help.
I think so, I haven't used them that much but from the description they
seem simple to use, and as long as the class you want to save is
serializable then when the
56 matches
Mail list logo
