date:20101201

Re: [osg-users] osgDB::writeNodeFile and node types without wrappers/serializers

2010-12-01 Thread Robert Osfield

Hi J-S,

The serializers uses the library name and the class name to look up
the wrappers to read and write the objects.  If the library name and
class name are different from osg and Group then it won't invoke the
Group wrappers.  To have .osg support for them you'll need to provide
a wrapper, or modify the names so that they aren't modified locally.

Robert.

On Tue, Nov 30, 2010 at 8:06 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
 Hello all,

 I noticed when doing osgDB::writeNodeFile to .osg file with an
 osgOcean::OceanScene in the graph, the written graph stops at that node,
 i.e. that node and all its children (it is a subclass of osg::Group) are not
 in the file.

 I would think that even if no wrapper / serializer exists for this node
 type, it should be writable as its base class type (osg::Group)... Is this
 not what's supposed to happen?

 Initially, the OceanScene class didn't use the META_Node(library, class)
 macro, and I thought that was why it couldn't be saved even as its base
 class type (or any node type). But I changed the header to use the macro,
 and it still isn't written.

 I know the best thing would be to provide a serializer / osgdb_osgOcean
 plugin to be able to write and read the exact type and its members from .osg
 files (and other types). But what is the minimum I need to do so that at
 least, the writeNodeFile() traversal will traverse it as an osg::Group and
 write its children?

 Is there a way to write a callback that would be called for unknown node
 types, and from which I could static_castosg::Group* and then traverse
 that, which would resolve the base class type correctly?

 I even checked the OceanScene::traverse() method, and it is written as:

 void OceanScene::traverse( osg::NodeVisitor nv )
 {
    if( nv.getVisitorType() == osg::NodeVisitor::UPDATE_VISITOR )
    {
        //...
    }
    else if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
    {
        //...
    }
    else
        osg::Group::traverse(nv);
 }

 So I would have thought that would let the writeNodeFile() do its work as if
 it were an osg::Group...

 Thanks in advance,

 J-S
 --
 __
 Jean-Sebastien Guay    jean-sebastien.g...@cm-labs.com
                               http://www.cm-labs.com/
                        http://whitestar02.webhop.org/
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How can I change the colour of the model?

2010-12-01 Thread Robert Osfield

Hi Duan,

On Tue, Nov 30, 2010 at 3:55 PM, Duan Linghao linghaod...@gmail.com wrote:
 I'm not so familiar with that,I want to have a single colour for the whole 
 model.Someone told me to use setState,but I have no idea how to use that.Can 
 you say it more specificly,I'm a beginner on OSG.Thanks a lot!

Are you a beginner at OpenGL as well?  Are you familiar with
glMaterial?  The osg::Material StateAttribute is a wrapper around
this, and provide the ability to set the colour of objects.  You can
attach a Material to a StateSet and attach the StateSet at the top
node of your subgraph.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgDB::writeNodeFile and node types without wrappers/serializers

2010-12-01 Thread Wang Rui

Hi J-S,

The dotosg wrapper / serializer recognizes classes from there class
names. These should be defined with the className() method (or
META_Node macro) and the writing processor in osgDB will try to find a
wrapper corresponding to the name. If found, the node will be written
to files; otherwise the unknown node and its subgraph will be skipped.
It can't decide if the OceanScene is derived from osg::Group without a
name-wrapper map recorded in the Registry object.

The ive plugin is not limited in this way, because it implements
read()/write() virtual functions for all common scene elements, but it
must have all the libraries as dependencies and is hard to extend.

Adding and implementing read()/write() virtual methods for all OSG
classes may be better for serialization IO, but it will certainly
cause changes to almost all source files and be completely a pain for
future debugging and compatibility tests.

Do you mind if I could have time to help finish the serializers of the
osgOcean project someday? :-)

Cheers,

Wang Rui


2010/12/1 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com:
 Hello all,

 I noticed when doing osgDB::writeNodeFile to .osg file with an
 osgOcean::OceanScene in the graph, the written graph stops at that node,
 i.e. that node and all its children (it is a subclass of osg::Group) are not
 in the file.

 I would think that even if no wrapper / serializer exists for this node
 type, it should be writable as its base class type (osg::Group)... Is this
 not what's supposed to happen?

 Initially, the OceanScene class didn't use the META_Node(library, class)
 macro, and I thought that was why it couldn't be saved even as its base
 class type (or any node type). But I changed the header to use the macro,
 and it still isn't written.

 I know the best thing would be to provide a serializer / osgdb_osgOcean
 plugin to be able to write and read the exact type and its members from .osg
 files (and other types). But what is the minimum I need to do so that at
 least, the writeNodeFile() traversal will traverse it as an osg::Group and
 write its children?

 Is there a way to write a callback that would be called for unknown node
 types, and from which I could static_castosg::Group* and then traverse
 that, which would resolve the base class type correctly?

 I even checked the OceanScene::traverse() method, and it is written as:

 void OceanScene::traverse( osg::NodeVisitor nv )
 {
    if( nv.getVisitorType() == osg::NodeVisitor::UPDATE_VISITOR )
    {
        //...
    }
    else if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
    {
        //...
    }
    else
        osg::Group::traverse(nv);
 }

 So I would have thought that would let the writeNodeFile() do its work as if
 it were an osg::Group...

 Thanks in advance,

 J-S
 --
 __
 Jean-Sebastien Guay    jean-sebastien.g...@cm-labs.com
                               http://www.cm-labs.com/
                        http://whitestar02.webhop.org/
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [vpb] How to debug VPB step by step

2010-12-01 Thread Robert Osfield

Hi Wang,

On Wed, Dec 1, 2010 at 1:58 AM, wang junchao wangjuncha...@126.com wrote:
 Thank you for your reply. But maybe I didn't make myself understood. As you 
 know, reading source code is a very complex and boring work.

If you a programmer reading source is the single most important
activity you'll ever do.  Yes it's complex, but that's our lot.  If we
wanted an easy life we'd stack shelves at the local shop ;-)

So my question is that : can I input a commandline like osgdem -t -.. d.. - o 
output.ive and trace the execution of the program step by step like the 
Visual Studio's debug mode ?

I haven't used VisualStudio for a decade but I'd guess it still allows
you to specify command line options when running apps.  You should
look at the docs of VisualStudio as this really isn't an OSG/VPB
question.

As a general note I'd add that the OSG/VPB build system names debug
builds of libs and executables with a d postfix, so you'd use osgdemd
when debugging.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Hidden Viewer

2010-12-01 Thread Oliver Neumann

Hi Juan,

Thanks for your insight,

As Robert already answered, it should be possible.
The best explanation that I have for your problem is that some thread
fails to do wglMakeCurrent (after that call fails anything that follows
is just garbage) beacuse another thread is holding the context
(according to
http://www.opengl.org/sdk/docs/man/xhtml/glXMakeCurrent.xml, that's a
programming error in GLX, so I guess the same applies in WGL). All
OpenGL calls from that thread are going to fail after that.

If the sample code that I sent you also complains with the error message:
PixelBufferWin32::makeCurrentImplementation, wglMakeCurrent error: Die
angeforderte Ressource wird bereits verwendet
then, there is a threading error somewhere. However I can't spot it the
code I sent you and I'm afraid that's beyond my knowledge of OSG's guts.
Robert may be more insightful here.

You can try commenting the line that changes the threading model and
replacing frame() by run() to see if it also fails.

It results in the same error if I comment out the setThreadingModel call, no
matter if I use frame() or run(). Btw, I'm using osg v2.8.3.
I compile Juan's code using the official libraries from
http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-2.8.3/binaries/Windows/VisualStudio8/
and as Robert said, it's working thread safe in a standard graphics window.

If Robert is still reading this thread, is this a known issue with a solution
or do I have to write a bug report?

Greetings,
Oliver

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34291#34291

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Hidden Viewer

2010-12-01 Thread Robert Osfield

Hi Oliver,

On Wed, Dec 1, 2010 at 8:57 AM, Oliver Neumann z0...@yahoo.com wrote:
It results in the same error if I comment out the setThreadingModel call, no
matter if I use frame() or run(). Btw, I'm using osg v2.8.3.
I compile Juan's code using the official libraries from
http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-2.8.3/binaries/Windows/VisualStudio8/
and as Robert said, it's working thread safe in a standard graphics window.

I would suggest that perhaps it might appear to be working safe with a
standard graphics window, but could still be thread unsafe, you just
haven't hit the problem timing.

If Robert is still reading this thread, is this a known issue with a solution
or do I have to write a bug report?

Well the problem is most likely in the way you are using the OSG, or
perhaps using an OpenGL driver that doesn't support pbuffers, if you
want to write a bug report for your own app for you own purposes then
fine. As things stand it doesn't sound likely that it's an OSG bug.

If you really do think you've come across an OSG bug then the thing to
do is to write a small example, or modify one of the existing OSG
examples to reproduce the problem then post this. Then others can
test the problem out first hand. It could still be a bug in the what
you are trying to do, but others will be able to spot this and point
you at the problem.

71 matches

Mail list logo