Hi Marcus,
On Mon, 2005-09-26 at 17:52 +0200, Marcus Lindblom wrote:
>
> For PolygonChunk, it's these methods/fields:
>
> void setCullFace ( const Int32 &value );
> void setFrontFace ( const Int32 &value );
> void setFrontMode ( const Int32 &value );
> void setBackMode ( const Int32 &value );
>
> That's the only one I've had problems with so far.
ok, fixed and committed.
> Since you opted for a Python binding instead of an language-agnostic
> script binding system,
I just expected it to be easier, I'll actually take any of those. ;)
> I wrote one myself, which currently is quite
> targeted towards our xml-scripting system (which is sort of like Apache
> Ant's, with some compability towards other products here). Once boost
> releases it's lang-binding library (based on boost::python) I'll try to
> move that way, and separate our xml from the reflection/binding stuff.
> Then it might be a strong candidate for OpenSG inclusion.
I'll have to read up on that. It sounds interesting.
> What I've done there is to wrap most of the OpenSG objects with some
> scripting stuff and automatic linking based on type (lots of
> dynamic_cast here). Basically, it's a lot of reflection and dynamic
> typing in C++. (And seriously, I wanted to do most of this in Java, but
> the world is not a nice place always.)
>
> The entire system is currently part of our very secret code base for our
> soon-to-be released commercial application, but perhaps I could part
> with the OpenSG-xml-stuff. :)
I would certainly be interested. :)
> Currently it's based on our own abstract
> xml-tree, so that will have to change first.
>
> Anyway, It's quite trivial actually, since it's based on
> boost::lexical_cast and the related istream-operators. Basically, you
> just map from name to field type to a parse function and invoke that on
> the string value. With some template code and a few trivial macros (to
> express "insert("foo", foo)" by INSERT(foo)) it's really a simple thing.
>
> For GLenum reading, I made my own type with it's istream/ostream
> operators, and copy-paste-search-replace'd from gl.h. Then I map
> osg::SFGLenum to my type (which has a GLenum conversion operator), just
> as I map osg::SFReal32 to float, etc.
>
> Questions? :)
Do you have any problems with performance? Doing everything via strings
sounds expensive. I probably wouldn't try to use that kind of interface
to create large geometries anyway, but it feels like there could be a
problem here.
But interesting in any case. If you can convince your boss that it would
be good to have other people hack away on that, I'd be interested to add
it. ;)
Yours
Dirk
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
