Re: [osg-users] Off on a weeks holiday!

[Simon Loic]

Have fun!
Loïc


2009/7/3 FlySky 

>
> Enjoy:)
>
>
> 在2009-07-04，"Robert Osfield"  写道：
> >Hi All,
> >
> >I'm just heading offline to complete my packing for a week family
> >holiday on the beautiful Isle of Skye (part of the west coast of
> >Scoltand.)
> >
> >I hope you all have fun in my absence ;-)
> >Robert.
> >___
> >osg-users mailing list
> >osg-users@lists.openscenegraph.org
>
> >http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> --
> 200万种商品,最低价格,疯狂诱惑你
> ___
> 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] rendering many instances of big Geometries

[Simon Loic]

Thanks for your suggestions Robert.

I'm afraid we don't all have to time to write treaties on the topics
> of performance optimization - it's a huge topic.
>

Don't worry, I'm aware of that. Still I could give it a try and see if some
knowledgeable folks could find time. Yet I guess the conclusion is clearly :
they don't ;-).

OK, so traversals shouldn't be too slow then, so you shouldn't need to
> batch more coasely.  It might be that you might want to divide your
> scene graph up more for better culling performance, and a existing
> modest number of scene graph nodes will give you scope to do this.
>
> The data being shared and static makes things pretty easy.  100,000
> vertices will comfortable sit on the graphics card, and VBO's would be
> able to handle it.  The modest number of instances of this geometry
> would mean that the cost overhead of traversal and dispatch to OpenGL
> will be low so there is no need to resort to instances, it simply
> won't be required.
>

Ok, I'll try it


>
> The only thing you might want to look at is breaking up your
> geometries spatially to keep the vertex count a bit more modest and
> the geometry chunks smaller to aid view frustum culling.


In my case most of the geometries will be seen entirely. So I guess this
won't help a lot.


> If you
> expect to see a big percentage of your geometries on screen at one
> time and this breaks frame then you should consider using LOD's to
> manage scene complexity.
>

Yes LODs should be a solution. Though I'm working on a research project in
another field than graphics and I was looking forward something easier to
settle. Actually I tried at some point to simplify the geometries (using
osg::Simplifier) and used the results as low level LOD but it was destroying
the visual aspect of the geometries. Then I gave up this track.


>
> The other thing to look at is make your geometry efficient by using
> DrawElementsUShort/DrawElementUInt where possible, remove duplicate
> vertices's, tri-strip the geometry etc.
>

I'll see if I can do that.
Thanks a lot Robert.

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

Re: [osg-users] rendering many instances of big Geometries

[Simon Loic]

Thanks Robert for trying to  get into the problem.
I wanted to let it "opened" in order to get as many opinion/possible
oprimizations as possible.
To be truly honest I have a real problem with specific conditions.
Many instances refers to hundreds of them.
Large geometries are about 10 000 to 100 000 vertices.
All the instances have the same geometry (which is static), and the same
stateset.
cheers,
Loïc


On Fri, Jul 3, 2009 at 10:19 AM, Robert Osfield wrote:

> Hi Loic,
>
> Optimizing drawing lots of large geometries depends upon lots of
> factors, both hardware and software.  It really is a very open ended
> topic, so could you qualify what you mean by "lots" and "large" a bit
> more carefully, and also are the geometries all the same, same
> geometry/different state, different geometries/same state, different
> geometries and different state.
>
> I tend to see "lots" of nodes/geometries as being in the order of
> magnitude of 10,000+, and "large" geometries as being 100,000+
> vertices.  Modern graphics cards can comfortably do 1,000,000 vertices
> per frame at 60Hz, but only if you drive it efficiently - so using
> VBO's and batching the geometries efficiently (avoiding too small
> geometries).
>
> Culling, state sorting and lazy state updating are all crucial factors
> in getting good performance.  With such an open ended topic I can't
> really add much more, you'll need to explain much more specifically
> about the type of problem you are trying to solve and the amount of
> state, nodes and geometry that you are dealing with.
>
> Robert.
>
>
> On Fri, Jul 3, 2009 at 11:07 AM, Simon Loic wrote:
> > Hi all,
> > There was a thread recently about rendering many instances of spheres (I
> > didn't want to hijack the thread so I created a new one). Many methods
> were
> > proposed among which there were opengl pseudo instancing and the
> > draw_instanced  extension.
> > First I would like to know the main differences between these two (both
> in
> > the principle and in terms of efficiency).
> >
> > just for the record, I've read the Nvidia paper given by Christian,
> >
> http://download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/OpenGL/src/glsl_pseudo_instancing/docs/glsl_pseudo_instancing.pdf
> >  and it seems that the pseudo instancing methods will be worth only when
> > each instance contains few vertices (less than 50). This constraint won't
> > cause any trouble for a sphere, I guess.
> > Is it the same with the draw_instanced  extension?
> > And then what would be the best approach to render many instances of a
> big
> > geometry (eg thousands of vertices per instance)?
> > Last, are those instancing methods worth even if the geometry is static,
> or
> > is it more efficient to use DisplayList or VBO?
> >
> > I know there must not be general answers depending on many aspects (as
> the
> > Graphics card, the driver, etc.) but I am looking forward to get a bit of
> > your expertise in that matter.
> > Thanks in advance.
> >
> > Loïc
> >
> > PS: I'm not very skilled in openGL so don't hesitate to explain things
> that
> > seems very basic about all those concepts ( like instancing, VBO,
> > displayList). Hopefully this will be also useful for other osg newbies
> like
> > me.
> >
> > ___
> > 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] rendering many instances of big Geometries

[Simon Loic]

Hi all,
There was a thread recently about rendering many instances of spheres (I
didn't want to hijack the thread so I created a new one). Many methods were
proposed among which there were opengl pseudo instancing and the
draw_instanced  extension.
First I would like to know the main differences between these two (both in
the principle and in terms of efficiency).

just for the record, I've read the Nvidia paper given by Christian,
http://download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/OpenGL/src/glsl_pseudo_instancing/docs/glsl_pseudo_instancing.pdf
 and it seems that the pseudo instancing methods will be worth only when
each instance contains few vertices (less than 50). This constraint won't
cause any trouble for a sphere, I guess.
Is it the same with the draw_instanced  extension?
And then what would be the best approach to render many instances of a big
geometry (eg thousands of vertices per instance)?
Last, are those instancing methods worth even if the geometry is static, or
is it more efficient to use DisplayList or VBO?

I know there must not be general answers depending on many aspects (as the
Graphics card, the driver, etc.) but I am looking forward to get a bit of
your expertise in that matter.
Thanks in advance.

Loïc

PS: I'm not very skilled in openGL so don't hesitate to explain things that
seems very basic about all those concepts ( like instancing, VBO,
displayList). Hopefully this will be also useful for other osg newbies like
me.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VPB and CMake

[Simon Loic]

Hi, back to home and found the problem. I had another cmake installed which
was 2.6.0.
However when typing "which cmake" in a console I was getting the ubuntu
repositories version.
Everything is ok now.
thanks Robert.
Loïc Simon


On Mon, Jun 22, 2009 at 10:27 AM, Simon Loic  wrote:

> Hi Robert.
> I don't understand. I've just tried at work and the build goes well. I'll
> try to see what went wrong at home.
> Thanks
> Loïc Simon
>
>
>
> On Mon, Jun 22, 2009 at 9:41 AM, Robert Osfield 
> wrote:
>
>> HI Loic,
>>
>> Could you try removing your CMakeCache.txt file and then re-run
>> ./configure to see if the variables get set up correctly.
>>
>> Robert
>>
>> On Sun, Jun 21, 2009 at 6:52 PM, Simon Loic wrote:
>> > Hi Robert,
>> > I perfectly understand the aim of this test.
>> > Though I'm a bit perplexed as I have also cmake 2.6.2!! (installed from
>> > ubuntu repositories).
>> > Besides, I can't find any reference to tose variable in make cmake.
>> > Is there anyone in the same situation?? Any Idea?
>> > Loïc Simon
>> >
>> >
>> > On Sat, Jun 20, 2009 at 6:35 PM, Robert Osfield <
>> robert.osfi...@gmail.com>
>> > wrote:
>> >>
>> >> Hi Loic,
>> >>
>> >> Which version of CMake are you using?  These variables are pulled by
>> >> the FIND_PACKAGE() in my Cmake 2.6.2 version that I'm working against.
>> >>
>> >> The intention of this new code is enforce the OSG version that VPB
>> >> builds against, as it now requires the OSG-svn/trunk or up coming
>> >> OSG-2.9.5 release due to the use of the new osgDB::DatabaseRevisions
>> >> classes.
>> >>
>> >> Robert.
>> >>
>> >> On Sat, Jun 20, 2009 at 5:02 PM, Simon Loic
>> wrote:
>> >> > I've just checked out VPB trunk, and the CMakeModule FindOSG.cmake
>> seems
>> >> > buggy :
>> >> > line 117 (end others) VERSION_GREATER And VERSION_EQUAL don't seem
>> >> > defined
>> >> > and cmake is complaining about it.
>> >> > When I comment those line (I have the latest trunk of osg so I know
>> I'm
>> >> > good) the build goes right.
>> >> > Are VERSION_GREATER and VERSION_EQUAL to be deifined? If yes in what
>> >> > way?
>> >> > regards
>> >> > Loïc
>> >> >
>> >> > ___
>> >> > 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
>> >
>> >
>> > ___
>> > 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
>>
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VPB and CMake

[Simon Loic]

Hi Robert.
I don't understand. I've just tried at work and the build goes well. I'll
try to see what went wrong at home.
Thanks
Loïc Simon


On Mon, Jun 22, 2009 at 9:41 AM, Robert Osfield wrote:

> HI Loic,
>
> Could you try removing your CMakeCache.txt file and then re-run
> ./configure to see if the variables get set up correctly.
>
> Robert
>
> On Sun, Jun 21, 2009 at 6:52 PM, Simon Loic wrote:
> > Hi Robert,
> > I perfectly understand the aim of this test.
> > Though I'm a bit perplexed as I have also cmake 2.6.2!! (installed from
> > ubuntu repositories).
> > Besides, I can't find any reference to tose variable in make cmake.
> > Is there anyone in the same situation?? Any Idea?
> > Loïc Simon
> >
> >
> > On Sat, Jun 20, 2009 at 6:35 PM, Robert Osfield <
> robert.osfi...@gmail.com>
> > wrote:
> >>
> >> Hi Loic,
> >>
> >> Which version of CMake are you using?  These variables are pulled by
> >> the FIND_PACKAGE() in my Cmake 2.6.2 version that I'm working against.
> >>
> >> The intention of this new code is enforce the OSG version that VPB
> >> builds against, as it now requires the OSG-svn/trunk or up coming
> >> OSG-2.9.5 release due to the use of the new osgDB::DatabaseRevisions
> >> classes.
> >>
> >> Robert.
> >>
> >> On Sat, Jun 20, 2009 at 5:02 PM, Simon Loic
> wrote:
> >> > I've just checked out VPB trunk, and the CMakeModule FindOSG.cmake
> seems
> >> > buggy :
> >> > line 117 (end others) VERSION_GREATER And VERSION_EQUAL don't seem
> >> > defined
> >> > and cmake is complaining about it.
> >> > When I comment those line (I have the latest trunk of osg so I know
> I'm
> >> > good) the build goes right.
> >> > Are VERSION_GREATER and VERSION_EQUAL to be deifined? If yes in what
> >> > way?
> >> > regards
> >> > Loïc
> >> >
> >> > ___
> >> > 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
> >
> >
> > ___
> > 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VPB and CMake

[Simon Loic]

Hi Robert,
I perfectly understand the aim of this test.
Though I'm a bit perplexed as I have also cmake 2.6.2!! (installed from
ubuntu repositories).
Besides, I can't find any reference to tose variable in make cmake.
Is there anyone in the same situation?? Any Idea?
Loïc Simon


On Sat, Jun 20, 2009 at 6:35 PM, Robert Osfield wrote:

> Hi Loic,
>
> Which version of CMake are you using?  These variables are pulled by
> the FIND_PACKAGE() in my Cmake 2.6.2 version that I'm working against.
>
> The intention of this new code is enforce the OSG version that VPB
> builds against, as it now requires the OSG-svn/trunk or up coming
> OSG-2.9.5 release due to the use of the new osgDB::DatabaseRevisions
> classes.
>
> Robert.
>
> On Sat, Jun 20, 2009 at 5:02 PM, Simon Loic wrote:
> > I've just checked out VPB trunk, and the CMakeModule FindOSG.cmake seems
> > buggy :
> > line 117 (end others) VERSION_GREATER And VERSION_EQUAL don't seem
> defined
> > and cmake is complaining about it.
> > When I comment those line (I have the latest trunk of osg so I know I'm
> > good) the build goes right.
> > Are VERSION_GREATER and VERSION_EQUAL to be deifined? If yes in what way?
> > regards
> > Loïc
> >
> > ___
> > 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] VPB and CMake

[Simon Loic]

I've just checked out VPB trunk, and the CMakeModule FindOSG.cmake seems
buggy :
line 117 (end others) VERSION_GREATER And VERSION_EQUAL don't seem defined
and cmake is complaining about it.
When I comment those line (I have the latest trunk of osg so I know I'm
good) the build goes right.
Are VERSION_GREATER and VERSION_EQUAL to be deifined? If yes in what way?
regards
Loïc
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt osgviewer

[Simon Loic]

Hi,
More recently, Don Leich has proposed a new example on osg-submissions which
seems to be very good. Sadly, it seems that we were very few to have looked
into it and I'm far from being an expert in QT. Hence, it would be
interesting to have others feedback.
A link to the thread :
http://www.mail-archive.com/osg-submissi...@lists.openscenegraph.org/msg03649.html
regrads
Loïc Simon


On Tue, Jun 16, 2009 at 4:58 PM, Martin Beckett  wrote:

> See http://forum.openscenegraph.org/viewtopic.php?t=2517 for some links to
> Qt examples
> Cheers,
> Martin
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=14042#14042
>
>
>
>
>
> ___
> 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] FirstPersonManipulator

[Simon Loic]

Hi christian,
I'm glad to hear feedback on this manipulator. The problem you mention about
the home position is exactly those I have to face right now. Ideally the
camera should fall down to the terrain. Anyway I can send you the osg
example I set up so far (with the bug) and you see if you can do something.
Just tell me if you are interested.
Cheers

Loïc Simon


On Tue, Jun 2, 2009 at 2:54 PM, Christian Sam  wrote:

> Hi simon,
>
> i got it working, i added the osgGA namespace to the parameters of the
> function below. i had to remove the outer enclosing namespace declaration,
> because the compiler complained:
> virtual void init(const GUIEventAdapter& ,GUIActionAdapter&); -> virtual
> void init(const osgGA::GUIEventAdapter& ,osgGA::GUIActionAdapter&);
>
>
> i only tested it for a short time but the manipulator worked very smooth.
> there were only two problems i encouterd:
>
> in case of my terrain, the starting position is high above ground - i have
> to switch to free-mode, because when remaining in default-mode: "grounded"
> the camera position always resets back to initial start position after some
> time of falling down to ground. (console output, LOST IN SPACE), but never
> arriving it. i think i can fix this when providing individual
> setHomePosition values.
>
> the other issue is, that i sometimes fall through the terrain (tested in
> free-mode, can't try the other one, because when i'm finally onground and
> switch to grounded-mode, i restart high above the ground, with the problems
> described above). i' dont have much experience with manipulators, collisions
> detection, etc.,  but the cause for this could be that my osgdem generated
> terrain has different LODs regarding polygon resolution. maybe on the
> translations, the collision detection has problems with possible cracks in
> polygons?
>
> anyway this is a very good manipulator, keep up on it!
>
> Thank you!
>
> Cheers,
> Christian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13353#13353
>
>
>
>
>
> ___
> 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] FirstPersonManipulator

[Simon Loic]

Hi Christian,
You are right. Right now it is not really convenient to test this
manipulator. And as pointed by other fellows, it would be easier to have a
complete example. I'm working on it (but have encountered a few problems).

About the linking problem you had, I think that you didn't compile the
FirstPersonManipulator.cpp and link against it. If you want to only use an
include, you would have to embed the code of FPM.cpp inside the FPM.h and
make those functions inline.
cheers
Loïc Simon


On Sat, May 30, 2009 at 12:18 AM, Christian Sam  wrote:

> Hi,
>
> i included the following lines in my applicationcode:
> #include "../include/FirstPersonManipulator.h"
> viewer.setCameraManipulator(new osgGA::FirstPersonManipulator);
>
> and got:
> 1>   Creating library D:\workspace\test-osg\sln\graz\Debug\graz.lib and
> object D:\workspace\test-osg\sln\graz\Debug\graz.exp
> 1>graz5.obj : warning LNK4217: locally defined symbol
> ??0firstpersonmanipula...@osgga@@q...@_n@Z (public: __thiscall
> osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)) imported in
> function _main
> 1>graz5.obj : warning LNK4217: locally defined symbol
> ?classn...@firstpersonmanipulator@osgGA@@UBEPBDXZ (public: virtual char
> const * __thiscall osgGA::FirstPersonManipulator::className(void)const )
> imported in function "[thunk]:public: virtual char const * __thiscall
> osgGA::FirstPersonManipulator::className`vtordisp{4294967292,0}' (void)const
> " (?classn...@firstpersonmanipulator@osgGA@@$4p...@a@BEPBDXZ)
> 1>graz5.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) protected: void __thiscall
> osgGA::FirstPersonManipulator::`vbase destructor'(void)"
> (__imp_??_dfirstpersonmanipula...@osgga@@IAEXXZ) referenced in function
> "protected: virtual void * __thiscall osgGA::FirstPersonManipulator::`scalar
> deleting destructor'(unsigned int)" (??_gfirstpersonmanipula...@osgga
> @@maep...@z)
> 1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for
> `osg::Object'}" (__imp_??_7firstpersonmanipula...@osgga@@6bobj...@osg@@@)
> referenced in function "public: __thiscall
> osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)"
> (??0firstpersonmanipula...@osgga@@q...@_n@Z)
> 1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for
> `osg::Drawable::EventCallback'}" (__imp_??_7firstpersonmanipula...@osgga
> @@6beventcallb...@drawable@osg@@@) referenced in function "public:
> __thiscall osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)"
> (??0firstpersonmanipula...@osgga@@q...@_n@Z)
> 1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) const osgGA::FirstPersonManipulator::`vftable'{for
> `osg::NodeCallback'}" (__imp_??_7firstpersonmanipula...@osgga
> @@6bnodecallb...@osg@@@) referenced in function "public: __thiscall
> osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)"
> (??0firstpersonmanipula...@osgga@@q...@_n@Z)
> 1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) const osgGA::FirstPersonManipulator::`vbtable'{for
> `osg::Drawable::EventCallback'}" (__imp_??_8firstpersonmanipula...@osgga
> @@7beventcallb...@drawable@osg@@@) referenced in function "public:
> __thiscall osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)"
> (??0firstpersonmanipula...@osgga@@q...@_n@Z)
> 1>FirstPersonManipulator.obj : error LNK2019: unresolved external symbol
> "__declspec(dllimport) const osgGA::FirstPersonManipulator::`vbtable'{for
> `osg::NodeCallback'}" (__imp_??_8firstpersonmanipula...@osgga
> @@7bnodecallb...@osg@@@) referenced in function "public: __thiscall
> osgGA::FirstPersonManipulator::FirstPersonManipulator(bool)"
> (??0firstpersonmanipula...@osgga@@q...@_n@Z)
> 1>D:\workspace\test-osg\sln\graz\Debug\graz.exe : fatal error LNK1120: 6
> unresolved externals
>
>
> is it possible to try this manipulator without building a new osgViewer?
>
>
> Thank you!
>
> Cheers,
> Christian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13200#13200
>
>
>
>
>
> ___
> 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] FirstPersonManipulator

[Simon Loic]

Maybe alejandro is right. I should post it as an complete example. Then it
will be more convenient to test it. I'll try to provide it soon.

On Tue, May 19, 2009 at 6:48 PM, Pierre Bourdin (gmail) <
pierre.bour...@imerir.com> wrote:

> Well it's just one line to add to osgviewer...
>
> keyswitchManipulator->addMatrixManipulator( '5', "FPS", new
> osgGA::FirstPersonManipulator() );
>
> Pierre.
>
> Le mardi 19 mai 2009 à 11:46 -0500, Alejandro Aguilar Sierra a écrit :
> > Yeah, it would be better to have a complete, working, example, to test
> > its basics.
> >
> > -- A.
> >
> >
> > On Tue, May 19, 2009 at 11:37 AM, Pierre Bourdin (gmail)
> >  wrote:
> > > I've just made an osgViewer with a FirstPersonManipulator...
> > >
> > > I've tested with a terrain...
> > >
> > > The Manipulator is shouting: "you are lost in space!"
> > >
> > > What kind of model you suggest to use it ?
> > >
> > > I had no time for a more complete test, so maybe I missed something
> > > obvious ?...?
> > >
> > > At least I can say it compiles on Linux Debian Testing with 2.8.1-rc5
> > > without any problem...
> > >
> > > Pierre.
> > >
> > > Le mardi 19 mai 2009 à 17:05 +0200, Simon Loic a écrit :
> > >> Hi,
> > >> I don't think it would make sense anyway to review a code where very
> > >> few people find interest. So I totally understand your position.
> > >> Anyway, from what I've seen on this ML, users are quite active and I
> > >> think they just didn't paid attention. So let's wait for feedback.
> > >> Cheers.
> > >> Loïc
> > >>
> > >> On Tue, May 19, 2009 at 4:56 PM, Robert Osfield
> > >>  wrote:
> > >> On Tue, May 19, 2009 at 3:43 PM, Simon Loic
> > >>  wrote:
> > >> > Hi Robert,
> > >> > I'm not sure if the code is clean enough to fulfill OSG
> > >> standards. Yet I was
> > >> > expecting some feedbacks about the manipulator (stability on
> > >> different
> > >> > machines, missing features, weird behaviours, ...) before to
> > >> release a
> > >> > submission.
> > >> >
> > >> > If you feel it's clean enough I guess you can check it in.
> > >> Yet, as we don't
> > >> > get any feedback, maybe it's not worth it.
> > >>
> > >>
> > >> I was hoping to have feedback from others before diving in
> > >> with a
> > >> review myself.  I have plenty on my plate so having to do all
> > >> the
> > >> review work myself is something I'd rather not do.
> > >>
> > >> Robert.
> > >>
> > >> ___
> > >> osg-users mailing list
> > >> osg-users@lists.openscenegraph.org
> > >>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Loïc Simon
> > >> ___
> > >> osg-users mailing list
> > >> osg-users@lists.openscenegraph.org
> > >>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > 
> > > Pierre BOURDIN
> > > I.M.E.R.I.R.
> > > Av. Pascot BP 90443
> > > 66004 PERPIGNAN
> > > tél: 04 68 56 84 95
> > > fax: 04 68 55 03 86
> > > email: bour...@imerir.com
> > > 
> > >
> > > ___
> > > osg-users mailing list
> > > osg-users@lists.openscenegraph.org
> > >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > >
> 
> Pierre BOURDIN
> I.M.E.R.I.R.
> Av. Pascot BP 90443
> 66004 PERPIGNAN
> tél: 04 68 56 84 95
> fax: 04 68 55 03 86
> email: bour...@imerir.com
> 
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] FirstPersonManipulator

[Simon Loic]

Hi,
I don't think it would make sense anyway to review a code where very few
people find interest. So I totally understand your position. Anyway, from
what I've seen on this ML, users are quite active and I think they just
didn't paid attention. So let's wait for feedback.
Cheers.
Loïc

On Tue, May 19, 2009 at 4:56 PM, Robert Osfield wrote:

> On Tue, May 19, 2009 at 3:43 PM, Simon Loic  wrote:
> > Hi Robert,
> > I'm not sure if the code is clean enough to fulfill OSG standards. Yet I
> was
> > expecting some feedbacks about the manipulator (stability on different
> > machines, missing features, weird behaviours, ...) before to release a
> > submission.
> >
> > If you feel it's clean enough I guess you can check it in. Yet, as we
> don't
> > get any feedback, maybe it's not worth it.
>
> I was hoping to have feedback from others before diving in with a
> review myself.  I have plenty on my plate so having to do all the
> review work myself is something I'd rather not do.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] FirstPersonManipulator

[Simon Loic]

Hi Robert,
I'm not sure if the code is clean enough to fulfill OSG standards. Yet I was
expecting some feedbacks about the manipulator (stability on different
machines, missing features, weird behaviours, ...) before to release a
submission.

If you feel it's clean enough I guess you can check it in. Yet, as we don't
get any feedback, maybe it's not worth it.

regards,
Loic

On Tue, May 19, 2009 at 4:09 PM, Robert Osfield wrote:

> HI All,
>
> Has anyone tested Loic's manipulator yet?
>
> Loic do you feel it's nearing being ready to merge with the svn/trunk
> of the OSG?
>
> Robert.
>
> On Fri, May 1, 2009 at 5:33 PM, Simon Loic  wrote:
> > Hi guys,
> >
> > I finally upload the FirstPersonManipulator.
> > This the renamed and modified version of previously called DoomLike
> > Manipulator.
> >
> > Hope kind users would not mind test it and make remarks or even better
> > recode the crappy parts of the current proposal :-).
> > Hope it will be of soe interest to someone.
> > Thanks a lot.
> >
> > --
> > Loïc Simon
> >
> > ___
> > 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
>



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

Re: [osg-users] Development of Qt support as part of osgViewer

[Simon Loic]

Hi Robert,
About David Guthries implementation, it was indeed posted on the osg-users
ml.
Here is a link to this thread :
http://forum.openscenegraph.org/viewtopic.php?p=11636#11636
Cheers,
Loïc

On Mon, May 18, 2009 at 4:03 PM, Robert Osfield wrote:

> Hi All,
>
> I'm mainly just tracking this thread trying to get a feel for what's
> working an what's not, and who might be able to help refine the right
> approach.  So for nothing concrete has jumped out..
>
> 2009/5/13 René Molenaar :
> > Have you seen David Guthries implementation (posted a few days ago), it
> uses
> > windowsystemwrapper to integrate osg/qt?
>
> No I haven't, was this posted on osg-users?  Did I miss it spinning
> past a 100 knots?
>
> I don't know if it's related, but one design aspect to osgViewer which
> was built in front the start is the
> osg::GraphicsContext::WindowSystemInterface which provides the
> abstraction away from the implementation.  This interface class was
> the potential of having multiple implementations, and for the
> implementations to be moved out into plugins, just like we have
> plugins for databases and wrappers right now.
>
> For ease of building and running OSG apps I didn't go for the full
> plugin approach from WindowSystemInterface, rather allowed
> implementations from X11, Win32, Carbon and Cocoa to be imbeded
> directly into the osgViewer.  This means you only have to link against
> osgViewer to get a viewer up on the screen, but it does mean that the
> library itself isn't as flexible w.r.t dynamically loading the
> implementations.  It wouldn't be a great deal of work to do this
> though.  Or perhaps we could still have the inbuilt implementations,
> but allow plugins to add extra ones.
>
> A plugin for Qt support would certainly be possible.  Potentially one
> could even compile the core osgViewer library without any default
> implementation and rely on such a plugin, or change the default
> implementation that one compiles against.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] OSG and QT example

[Simon Loic]

Hi David,

Just to answer your point, I would be personally interested in such an
integration.
So far I'm using the AdapterWidget of the ViewerQt example but I'm not fully
satisfied. Indeed it suffers a couple of problems as :
- the lack of multiple thread support
- a bad translation between QT keyboard events and OSG one.

I had a quick look to the code you pointed and both seems to be handled in
it (tell me if I'm wrong).

As for the QOSGWidget, I tried to embed it in a QtDesigner based GUI and I
must confess I couldn't make it. May be I dind't try hard enough. Yet if
someone could provide such an example (ie without the trick to avoid the moc
steps and so on), that would be hell of a tip.

Thanks



On Thu, May 7, 2009 at 8:43 PM, David Guthrie wrote:

> Hi,
>
> We wrote a QT/OSG integration that implements the windowing system
> interface for qt.
>
> It's in the delta3d dtQt library.  It seems like the sort of thing that
> should be part of OSG, we just haven't submitted it.  If there is interest,
> we can look at what the code should look like and where it should go...
>
> Look at
>
> https://delta3d.svn.sourceforge.net/svnroot/delta3d/trunk/delta3d/inc/dtQt
> https://delta3d.svn.sourceforge.net/svnroot/delta3d/trunk/delta3d/src/dtQt
>
> at the files
>
> osgadapterwidget.h
> osggraphicswindowqt.h
> qtguiwindowsystemwrapper.h
>
> osgadapterwidget.cpp
> osggraphicswindowqt.cpp
> qtguiwindowsystemwrapper.cpp
>
> Thank you!
> David Guthrie
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=11639#11639
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] About QT example!

[Simon Loic]

Hi YangXiao,
I've seen in some previous thread that if you want to make multiple
threading schema work, you have to use the QOSGWidget instead of the
AdapterWidget. Don't ask me why as I don't know anything about it.
Hope I could help.



On Mon, May 11, 2009 at 4:05 AM, YangXiao  wrote:

> Hi everyone
>  In QTOSG example,When i modify the thread model to
> osgViewer::Viewer::DrawThreadPerContext); I get a runtime error!
>
> class ViewerQT : public osgViewer::Viewer, public AdapterWidget
> {
> public:
>  ViewerQT(QWidget * parent = 0, const char * name = 0, const QGLWidget *
> shareWidget = 0, WindowFlags f = 0):
>AdapterWidget( parent, name, shareWidget, f )
>{
> getCamera()->setViewport(new osg::Viewport(0,0,width(),height()));
> getCamera()->setProjectionMatrixAsPerspective(30.0f,
> static_cast(width())/static_cast(height()), 1.0f, 1.0f);
> getCamera()->setGraphicsContext(getGraphicsWindow());
> setThreadingModel(osgViewer::Viewer::SingleThreaded);
> //setThreadingModel(osgViewer::Viewer::DrawThreadPerContext);  //here i
> modify
>   addEventHandler(new osgGA::StateSetManipulator );
> connect(&_timer, SIGNAL(timeout()), this, SLOT(updateGL()));
> _timer.start(10);
>}
>virtual void paintGL()
>{
> frame();
>}
> protected:
>  QTimer _timer;
> };
>
> Thanks YangXiao.
>
> --
> 好玩贺卡等你发，邮箱贺卡全新上线！
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] missing includes

[Simon Loic]

Hi,
Sorry I was not here this week-end. I indeed tried to compile osgearth
again, and apparently there is no problem. Maybe there wasn't at all as I'm
messing up between all the osg applications I built. Actually, I just built
VTP (the svn trunk version) and I can confirm this kind of problem with gcc
4.3.3.  In fact, the #include  is right in the concerned file
(TerrainSDK/vtdata/FilePath.cpp), but enclosed in a #ifdef VTUNIX directive
which seems not managed by the CMakeLists (or maybe I'm not using cmake in
the right way). I had to add the following line in the master CMakeLists.txt
to overcome this problem :
 add_definitions(-DVTUNIX)

Don't know if it's a good way though. Anyway, it is so difficult to make VTP
compile on my machine that I think I will just give up.


Thanks again for your help.

On Fri, May 8, 2009 at 4:36 PM, Jason Beverage wrote:

> Thanks Robert, that's good to hear!
>
> Jason
>
>
> On Fri, May 8, 2009 at 9:33 AM, Robert Osfield 
> wrote:
>
>> Hi Jason and Colin,
>>
>> I've just checked out the latest osgEarth and it compiles fine for my
>> under Kubuntu 9.04 (Jaunty) with g++ 4.3.3.
>>
>> Robert.
>>
>> On Fri, May 8, 2009 at 2:21 PM, Jason Beverage 
>> wrote:
>> > Hi Colin,
>> >
>> > Thanks for pointing that out, it looks like Jaunty does indeed default
>> to
>> > 4.3.  I'll play around with it this weekend and see if I can get
>> osgEarth
>> > compiling with 4.3.
>> >
>> > Thanks!
>> >
>> > Jason
>> >
>> > On Fri, May 8, 2009 at 4:19 AM, Colin Steinberg
>> >  wrote:
>> >>
>> >> Hi all,
>> >>
>> >> The gcc-team weeded out some includes in their headers for the 4.3
>> >> release.
>> >> If a program uses a cstdlib function, but does not include the header
>> file
>> >> because it was already pulled in by another c++ header, it will break
>> now.
>> >> I don't know which gcc version Jaunty defaults to, but if it is a 4.3
>> >> release, this would be the problem.
>> >>
>> >> Cheers,
>> >> Colin
>> >>
>> >> On Thu, May 7, 2009 at 10:40 PM, Jason Beverage <
>> jasonbever...@gmail.com>
>> >> wrote:
>> >> > Hi Simon,
>> >> >
>> >> > I try to build osgEarth pretty regularly on Ubuntu 8.10 and haven't
>> seen
>> >> > this error before.  Perhaps its something to do with Jaunty, I've not
>> >> > tried
>> >> > it yet.
>> >> >
>> >> > I'll try to give it a go when I get a chance, I've been wanting to
>> >> > update
>> >> > anyway:)
>> >> >
>> >> > Jason
>> >> >
>> >> > On Thu, May 7, 2009 at 4:23 AM, Simon Loic 
>> wrote:
>> >> >>
>> >> >> Hi Jason,
>> >> >> thanks for helping
>> >> >> I'm on a linux : kubuntu Jaunty.
>> >> >> To be totally honest in the first place I really doubted that the
>> code
>> >> >> I'm
>> >> >> talking about could compile on another linux. However, as this  code
>> >> >> (eg
>> >> >> VTP) must have been extensively tested I turned out to think that I
>> was
>> >> >> missing something.
>> >> >>
>> >> >> Thanks again.
>> >> >>
>> >> >> On Wed, May 6, 2009 at 11:24 PM, Jason Beverage
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Simon,
>> >> >>>
>> >> >>> What platform are you compiling on where you are seeing these
>> issues?
>> >> >>>
>> >> >>> Jason
>> >> >>>
>> >> >>> On Wed, May 6, 2009 at 3:47 PM, Simon Loic 
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Hello everyone,
>> >> >>>> It may certainly be a stupid question and not the right place to
>> ask.
>> >> >>>> Still I've been compiling a couple of osg based application : VTP,
>> >> >>>> osgEphemeris, osgearth. The fact is that for most of them I had to
>> >> >>>> add a
>> >> >>>> couple of #include directive to ma

Re: [osg-users] missing includes

[Simon Loic]

Hi Jason,
thanks for helping
I'm on a linux : kubuntu Jaunty.
To be totally honest in the first place I really doubted that the code I'm
talking about could compile on another linux. However, as this  code (eg
VTP) must have been extensively tested I turned out to think that I was
missing something.

Thanks again.

On Wed, May 6, 2009 at 11:24 PM, Jason Beverage wrote:

> Hi Simon,
>
> What platform are you compiling on where you are seeing these issues?
>
> Jason
>
> On Wed, May 6, 2009 at 3:47 PM, Simon Loic  wrote:
>
>> Hello everyone,
>> It may certainly be a stupid question and not the right place to ask.
>> Still I've been compiling a couple of osg based application : VTP,
>> osgEphemeris, osgearth. The fact is that for most of them I had to add a
>> couple of #include directive to make them compile. It's always some c++
>> wrapping of c headers like  or .
>> I don't understand if it is possible that those application compile
>> without problem on some computer. Which would mean that I have to tune some
>> environment variables or whatever.
>> Is this the case or should I report those missing directive to the
>> concerned developper?
>>
>> Thanks for any answer on this.
>>
>>
>> --
>> Loïc Simon
>>
>> ___
>> 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
>
>


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

[osg-users] missing includes

[Simon Loic]

Hello everyone,
It may certainly be a stupid question and not the right place to ask. Still
I've been compiling a couple of osg based application : VTP, osgEphemeris,
osgearth. The fact is that for most of them I had to add a couple of
#include directive to make them compile. It's always some c++ wrapping of c
headers like  or .
I don't understand if it is possible that those application compile without
problem on some computer. Which would mean that I have to tune some
environment variables or whatever.
Is this the case or should I report those missing directive to the concerned
developper?

Thanks for any answer on this.


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

Re: [osg-users] DoomLike manipulator

[Simon Loic]

I've started a new thread called FirstPersonManipulator with the files.

On Thu, Apr 23, 2009 at 1:50 PM, Simon Loic  wrote:

> Hi Richard,
> I wouldn't want to fool you with this collision stuff. The goal is simply
> to prevent the player (the camera) to cross through the walls of the scene,
> and in the meantime to stick to the ground in case of grounded mode.
> Something alike is already done in the DriveManipulator, using a
> LineSegmentIntersector. I wanted to improve it by modeling the player as a
> rectangle box, and use a PolytopeIntersector, but then I ran into a lot of
> trouble. So I think I will release a version with the LineSegmentIntersector
> first and when/if I find some time I will try again with the polytope one.
>
> --
> Loïc Simon
>
>
>
> On Thu, Apr 23, 2009 at 12:33 AM, Richard Baron Penman <
> richardbp+...@gmail.com > wrote:
>
>> 'collision handling' - oh wow!
>> I eagerly await.
>> Richard
>>
>>
>>
>> On Wed, Apr 22, 2009 at 7:59 AM, Simon Loic  wrote:
>>
>>> Hi,
>>> In fact I've struggled quite a while to handle collision in a way that
>>> apparently doesn't work, and finally I had to postpone coding on it for work
>>> reason.
>>> I'll try to post a version of this manipulator with simple collision
>>> tests soon , let's say by the week end.
>>>
>>>
>>>
>>> On Tue, Apr 21, 2009 at 3:51 AM, Richard Baron Penman <
>>> richardbp+...@gmail.com > wrote:
>>>
>>>> hi,
>>>>
>>>> I'm interested in using this manipulator. Have any updates been posted
>>>> or should I use the originally posted one?
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>> 2009/3/24 Simon Loic 
>>>>
>>>> In fact I didn't have enough time to finish this week-end. So It will be
>>>>> postponed to next week.
>>>>>
>>>>>
>>>>> On Fri, Mar 20, 2009 at 9:10 AM, Simon Loic wrote:
>>>>>
>>>>>> All right, I'll certainly finish during the week-end and post it on
>>>>>> osg-users for testing.
>>>>>>
>>>>>>
>>>>>> 2009/3/20 Robert Osfield 
>>>>>>
>>>>>>> Hi Loic,
>>>>>>>
>>>>>>> Great little discussion :-)
>>>>>>>
>>>>>>>  2009/3/19 Simon Loic 
>>>>>>>
>>>>>>>> Maybe when I will have finished to implement the GROUNDED/HORIZONTAL
>>>>>>>> mode you can give it a try and decide which  name best fits. In my 
>>>>>>>> concern I
>>>>>>>> clearly incline towars grounded as the implementation I was about to 
>>>>>>>> propose
>>>>>>>> allows step over small obstacles like stairs.
>>>>>>>>
>>>>>>>> If you have remarks on the implementation so far, go ahead...
>>>>>>>>
>>>>>>>> to sukender :
>>>>>>>> I didn't exacly get your remarks while I'm sure they are founded.
>>>>>>>> Anyway I think that when I wil have finished to code both mode, things 
>>>>>>>> will
>>>>>>>> become clearer for me and for you.
>>>>>>>>
>>>>>>>> Get you informed as soon as the manipulator is ready.
>>>>>>>>
>>>>>>>
>>>>>>> When you ready just post the changes to either osg-submissions if
>>>>>>> it's ready to merge, or to osg-users if you feel it still needs more
>>>>>>> discussion.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Robert,
>>>>>>>
>>>>>>> ___
>>>>>>> osg-users mailing list
>>>>>>> osg-users@lists.openscenegraph.org
>>>>>>>
>>>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Loïc Simon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Loïc Simon
>>>>>
>>>>> ___
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Loïc Simon
>>>
>>> ___
>>> 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
>>
>>
>
>
>


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

[osg-users] FirstPersonManipulator

[Simon Loic]

Hi guys,

I finally upload the FirstPersonManipulator.
This the renamed and modified version of previously called DoomLike
Manipulator.

Hope kind users would not mind test it and make remarks or even better
recode the crappy parts of the current proposal :-).
Hope it will be of soe interest to someone.
Thanks a lot.

-- 
Loïc Simon
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
 *
 * This library is open source and may be redistributed and/or modified under  
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 * 
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
 * OpenSceneGraph Public License for more details.
 */

#ifndef OSGGA_DOOM_LIKE_MANIPULATOR_DEF
#define OSGGA_DOOM_LIKE_MANIPULATOR_DEF 1

#include 

#include 
#include 
#include 

/**
   \class osgGA::FirstPersonManipulator
   \brief A FirstPerson manipulator driven with keybindings.

   The FirstPersonManipulator is better suited for applications that employ architectural walk-throughs.
   The camera control is fone via keyboard arrows concerning the position and via mouse draging concerning the orientation.
   There are two modes : the GROUNDED and the FREE one. In the free one the translation direction is exactly aligned with the view direction and thus can span the whole set of direction. In the other, the moving direction is constrained to remain horizontal while the view one remains unconstrained. Yet the position is adjusted to stick on the ground (ie upward move are still possible incase of non flat terrain). In both mode the up direction is perpendicular to the moving one.
   Unlike most of the other manipulators, the user controls directly the speed of the camera and not its acceleration.
   As a result, the user can achieve fast moves and yet change quickly the direction of the movement.

   The FirstPerson Manipulator allows the following movements with the listed
   Key combinations:
   \param SpaceBar Reset the view to the home position.
   \param Shift/SpaceBar   Reset the up vector to the vertical.
   \param UpArrow  Run forward.
   \param DownArrowRun backward.
   \param LeftArrowStep to the left.
   \param RightArrow   Step to the right.
   \param NumPad 0 Jump (only in grounded mode).
   \param Shift/UpArrowMove up (only in free mode).
   \param Shift/DownArrow  Move down (only in free mode).
   \param PageDown Switch between GROUNDED and FREE mode.
   \param DragMouseRotate the moving and looking direction.
*/

namespace osgGA {

class OSGGA_EXPORT FirstPersonManipulator : public osgGA::MatrixManipulator
{

public:
/** Default constructor */
FirstPersonManipulator(bool grounded = true);

/** return className
\return returns constant "FirstPerson"
*/
virtual const char* className() const;

/** Set the current position with a matrix 
\param matrix  A viewpoint matrix.
*/
virtual void setByMatrix( const osg::Matrixd &matrix ) ;

/** Set the current position with the inverse matrix
\param invmat The inverse of a viewpoint matrix
*/
virtual void setByInverseMatrix( const osg::Matrixd &invmat);

/** Get the current viewmatrix */
virtual osg::Matrixd getMatrix() const;

/** Get the current inverse view matrix */
virtual osg::Matrixd getInverseMatrix() const ;

/** Set the  subgraph this manipulator is driving the eye through.
\param node root of subgraph
*/
virtual void setNode(osg::Node* node);

/** Get the root node of the subgraph this manipulator is driving the eye through (const)*/
virtual const osg::Node* getNode() const;

/** Get the root node of the subgraph this manipulator is driving the eye through */
virtual osg::Node* getNode();

/** Computes the home position based on the extents and scale of the 
scene graph rooted at node */
virtual void computeHomePosition();

/** Sets the viewpoint matrix to the home position */
virtual void home(const osgGA::GUIEventAdapter&, osgGA::GUIActionAdapter&) ;
void home(double);

virtual void init(const GUIEventAdapter& ,GUIActionAdapter&);

/** Handles incoming osgGA events */
bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter &aa);

/** Reports Usage parameters to the application */
void getUsage(osg::ApplicationUsage& usage) const;

/** Report the current position as LookAt vectors */
void getCurrentPositionAsLookAt( osg::Ve

Re: [osg-users] DoomLike manipulator

[Simon Loic]

Hi Richard,
I wouldn't want to fool you with this collision stuff. The goal is simply to
prevent the player (the camera) to cross through the walls of the scene, and
in the meantime to stick to the ground in case of grounded mode.
Something alike is already done in the DriveManipulator, using a
LineSegmentIntersector. I wanted to improve it by modeling the player as a
rectangle box, and use a PolytopeIntersector, but then I ran into a lot of
trouble. So I think I will release a version with the LineSegmentIntersector
first and when/if I find some time I will try again with the polytope one.

-- 
Loïc Simon


On Thu, Apr 23, 2009 at 12:33 AM, Richard Baron Penman <
richardbp+...@gmail.com > wrote:

> 'collision handling' - oh wow!
> I eagerly await.
> Richard
>
>
>
> On Wed, Apr 22, 2009 at 7:59 AM, Simon Loic  wrote:
>
>> Hi,
>> In fact I've struggled quite a while to handle collision in a way that
>> apparently doesn't work, and finally I had to postpone coding on it for work
>> reason.
>> I'll try to post a version of this manipulator with simple collision tests
>> soon , let's say by the week end.
>>
>>
>>
>> On Tue, Apr 21, 2009 at 3:51 AM, Richard Baron Penman <
>> richardbp+...@gmail.com > wrote:
>>
>>> hi,
>>>
>>> I'm interested in using this manipulator. Have any updates been posted or
>>> should I use the originally posted one?
>>>
>>> Richard
>>>
>>>
>>>
>>> 2009/3/24 Simon Loic 
>>>
>>> In fact I didn't have enough time to finish this week-end. So It will be
>>>> postponed to next week.
>>>>
>>>>
>>>> On Fri, Mar 20, 2009 at 9:10 AM, Simon Loic wrote:
>>>>
>>>>> All right, I'll certainly finish during the week-end and post it on
>>>>> osg-users for testing.
>>>>>
>>>>>
>>>>> 2009/3/20 Robert Osfield 
>>>>>
>>>>>> Hi Loic,
>>>>>>
>>>>>> Great little discussion :-)
>>>>>>
>>>>>>  2009/3/19 Simon Loic 
>>>>>>
>>>>>>> Maybe when I will have finished to implement the GROUNDED/HORIZONTAL
>>>>>>> mode you can give it a try and decide which  name best fits. In my 
>>>>>>> concern I
>>>>>>> clearly incline towars grounded as the implementation I was about to 
>>>>>>> propose
>>>>>>> allows step over small obstacles like stairs.
>>>>>>>
>>>>>>> If you have remarks on the implementation so far, go ahead...
>>>>>>>
>>>>>>> to sukender :
>>>>>>> I didn't exacly get your remarks while I'm sure they are founded.
>>>>>>> Anyway I think that when I wil have finished to code both mode, things 
>>>>>>> will
>>>>>>> become clearer for me and for you.
>>>>>>>
>>>>>>> Get you informed as soon as the manipulator is ready.
>>>>>>>
>>>>>>
>>>>>> When you ready just post the changes to either osg-submissions if it's
>>>>>> ready to merge, or to osg-users if you feel it still needs more 
>>>>>> discussion.
>>>>>>
>>>>>> Cheers,
>>>>>> Robert,
>>>>>>
>>>>>> ___
>>>>>> osg-users mailing list
>>>>>> osg-users@lists.openscenegraph.org
>>>>>>
>>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Loïc Simon
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Loïc Simon
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>>
>> --
>> Loïc Simon
>>
>> ___
>> 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
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DoomLike manipulator

[Simon Loic]

Hi,
In fact I've struggled quite a while to handle collision in a way that
apparently doesn't work, and finally I had to postpone coding on it for work
reason.
I'll try to post a version of this manipulator with simple collision tests
soon , let's say by the week end.


On Tue, Apr 21, 2009 at 3:51 AM, Richard Baron Penman <
richardbp+...@gmail.com > wrote:

> hi,
>
> I'm interested in using this manipulator. Have any updates been posted or
> should I use the originally posted one?
>
> Richard
>
>
>
> 2009/3/24 Simon Loic 
>
> In fact I didn't have enough time to finish this week-end. So It will be
>> postponed to next week.
>>
>>
>> On Fri, Mar 20, 2009 at 9:10 AM, Simon Loic  wrote:
>>
>>> All right, I'll certainly finish during the week-end and post it on
>>> osg-users for testing.
>>>
>>>
>>> 2009/3/20 Robert Osfield 
>>>
>>>> Hi Loic,
>>>>
>>>> Great little discussion :-)
>>>>
>>>>  2009/3/19 Simon Loic 
>>>>
>>>>> Maybe when I will have finished to implement the GROUNDED/HORIZONTAL
>>>>> mode you can give it a try and decide which  name best fits. In my 
>>>>> concern I
>>>>> clearly incline towars grounded as the implementation I was about to 
>>>>> propose
>>>>> allows step over small obstacles like stairs.
>>>>>
>>>>> If you have remarks on the implementation so far, go ahead...
>>>>>
>>>>> to sukender :
>>>>> I didn't exacly get your remarks while I'm sure they are founded.
>>>>> Anyway I think that when I wil have finished to code both mode, things 
>>>>> will
>>>>> become clearer for me and for you.
>>>>>
>>>>> Get you informed as soon as the manipulator is ready.
>>>>>
>>>>
>>>> When you ready just post the changes to either osg-submissions if it's
>>>> ready to merge, or to osg-users if you feel it still needs more discussion.
>>>>
>>>> Cheers,
>>>> Robert,
>>>>
>>>> ___
>>>> osg-users mailing list
>>>> osg-users@lists.openscenegraph.org
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Loïc Simon
>>>
>>
>>
>>
>> --
>> Loïc Simon
>>
>> ___
>> 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
>
>


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

Re: [osg-users] DoomLike manipulator

[Simon Loic]

In fact I didn't have enough time to finish this week-end. So It will be
postponed to next week.

On Fri, Mar 20, 2009 at 9:10 AM, Simon Loic  wrote:

> All right, I'll certainly finish during the week-end and post it on
> osg-users for testing.
>
>
> 2009/3/20 Robert Osfield 
>
>> Hi Loic,
>>
>> Great little discussion :-)
>>
>> 2009/3/19 Simon Loic 
>>
>>> Maybe when I will have finished to implement the GROUNDED/HORIZONTAL mode
>>> you can give it a try and decide which  name best fits. In my concern I
>>> clearly incline towars grounded as the implementation I was about to propose
>>> allows step over small obstacles like stairs.
>>>
>>> If you have remarks on the implementation so far, go ahead...
>>>
>>> to sukender :
>>> I didn't exacly get your remarks while I'm sure they are founded. Anyway
>>> I think that when I wil have finished to code both mode, things will become
>>> clearer for me and for you.
>>>
>>> Get you informed as soon as the manipulator is ready.
>>>
>>
>> When you ready just post the changes to either osg-submissions if it's
>> ready to merge, or to osg-users if you feel it still needs more discussion.
>>
>> Cheers,
>> Robert,
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> --
> Loïc Simon
>



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

Re: [osg-users] DoomLike manipulator

[Simon Loic]

All right, I'll certainly finish during the week-end and post it on
osg-users for testing.


2009/3/20 Robert Osfield 

> Hi Loic,
>
> Great little discussion :-)
>
> 2009/3/19 Simon Loic 
>
>> Maybe when I will have finished to implement the GROUNDED/HORIZONTAL mode
>> you can give it a try and decide which  name best fits. In my concern I
>> clearly incline towars grounded as the implementation I was about to propose
>> allows step over small obstacles like stairs.
>>
>> If you have remarks on the implementation so far, go ahead...
>>
>> to sukender :
>> I didn't exacly get your remarks while I'm sure they are founded. Anyway I
>> think that when I wil have finished to code both mode, things will become
>> clearer for me and for you.
>>
>> Get you informed as soon as the manipulator is ready.
>>
>
> When you ready just post the changes to either osg-submissions if it's
> ready to merge, or to osg-users if you feel it still needs more discussion.
>
> Cheers,
> Robert,
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] DoomLike manipulator

[Simon Loic]

Maybe when I will have finished to implement the GROUNDED/HORIZONTAL mode
you can give it a try and decide which  name best fits. In my concern I
clearly incline towars grounded as the implementation I was about to propose
allows step over small obstacles like stairs.

If you have remarks on the implementation so far, go ahead...

to sukender :
I didn't exacly get your remarks while I'm sure they are founded. Anyway I
think that when I wil have finished to code both mode, things will become
clearer for me and for you.

Get you informed as soon as the manipulator is ready.


> Havig both modes sounds a good idea. In that case,
"FirstPersonManipulator" seems fine for me. Just be sure to:
> - allow the user to set which vector is considered to be "up"
> - allow the user to set the minimum angle between "dir" and "up" (or else
you got rounding errors that
> cause ugly artifacts). Based on experiments, I personnaly used 0.008
(radians; as you can see in the
> source code I told about), but it may depend on how your camera is set.

On Thu, Mar 19, 2009 at 9:42 PM, Jason Daly  wrote:

> Sukender wrote:
>
>> And about the modes, I would prefer "FREE" and "HORIZONTAL" :)
>>
>>
>
> My preference would be "GROUNDED" (as in, you stay on the ground) rather
> than "HORIZONTAL."  To me "HORIZONTAL" kind of implies one-dimensional
> motion.
>
> I'm indifferent on "FREE" vs. "GENERAL."
>
> --"J"
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] DoomLike manipulator

[Simon Loic]

Glad to see that this manipulator generates interest.
Concerning the name, the manipulator is designed as explained in the header
:

"""
 The camera control is done via keyboard arrows concerning the position and
via mouse draging concerning the orientation.
There are two modes : the horizontal and the free. In the free one the
translation direction is exactly aligned with the view direction and thus
can span the whole set of direction. In the other, the moving direction is
constrained to remain horizontal. Note : horizontal mode is not implemented
yet!!
"""
Taking into account what you said, Sukender, we should call it
FirstPesonManipulator and call the two modes GENERAL and DOOMLIKE.
What do you think about this?

On Thu, Mar 19, 2009 at 7:12 PM, Michael Platings
wrote:

> AFAIK you play as a human in Descent ;)
>
> Essentially it's to give the effect of walking/running, so how about
> "WalkManipulator"?
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org [mailto:
> osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sukender
> Sent: 19 March 2009 17:57
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] DoomLike manipulator
>
> Hi all,
>
> IMHO, "FirstPersonManipulator" should suit any "first person cameras" ; and
> a "doom-like" one is only a subset of a FPS manipulator. Think about
> "Descent" game, where you could go in any direction in space (no gravity to
> say where is the "up" direction). Doom-like has a fixed "up" vector that may
> not suit any use of a FPS view. I personally chose "Human*" prefix for
> Doom-like view (Hence "HumanManipulator" or "HumanViewManipulator").
>
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
>
> Le Thu, 19 Mar 2009 17:37:25 +0100, Robert Osfield <
> robert.osfi...@gmail.com> a écrit:
>
> > HI Loic,
> >
> > The manipulator certainly isn't pointless - as the fact that others
> > have written something similar shows it's a common need, so getting
> > something like it checked into the core OSG makes sense.  I would
> > suggest finding a more generic name rather than DoomLikeManipulator.
> > Perhaps FirstPersonManipulator?  I'm open to suggestions.
> >
> > Robert.
> >
> > 2009/3/19 Simon Loic 
> >
> >> Thanks guys,
> >> indeed the wasd manipulator does pretty much the same things as  mine.
> >> Although I'm not interested in changing my manipulator. I was just
> >> pointing out that this kind of manipulators are missing in the osg
> >> core. Basically if the wasd manipulator had been integrated in osgGA,
> >> I wouldn't have coded an equivalent from scratch.
> >> So I was expecting some motivated comments on the manipulator I
> >> propose, before to go through osg-submissions. Anyway if for any
> >> reason you think that this is pointless, I'll just forget about it.
> >>
> >>
> >>
> >> 2009/3/19 David Spilling 
> >>
> >>> Hi,
> >>>
> >>> FYI, there was a posting of a (presumably similar) WASD type
> >>> manipulater by Viggo Løvli back in August 08 - seach the archives
> >>> for "How to write a camera manipulator..."
> >>>
> >>> David
> >>>
> >>>
> >>> ___
> >>> osg-users mailing list
> >>> osg-users@lists.openscenegraph.org
> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegrap
> >>> h.org
> >>>
> >>>
> >>
> >>
> >> --
> >> Loïc Simon
> >>
> >> ___
> >> 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
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email__
>
> __
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] DoomLike manipulator

[Simon Loic]

Thanks guys,
indeed the wasd manipulator does pretty much the same things as  mine.
Although I'm not interested in changing my manipulator. I was just pointing
out that this kind of manipulators are missing in the osg core. Basically if
the wasd manipulator had been integrated in osgGA, I wouldn't have coded an
equivalent from scratch.
So I was expecting some motivated comments on the manipulator I propose,
before to go through osg-submissions. Anyway if for any reason you think
that this is pointless, I'll just forget about it.



2009/3/19 David Spilling 

> Hi,
>
> FYI, there was a posting of a (presumably similar) WASD type manipulater by
> Viggo Løvli back in August 08 - seach the archives for "How to write a
> camera manipulator..."
>
> David
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

[osg-users] DoomLike manipulator

[Simon Loic]

Hi guys,
I was looking for an osg manipulator fitted for walkthrough in architectural
environments. I found that the best ones were UFO, Drive and Flight. Though,
I was not really convinced by any of them as there is no direct control on
the speed but only on the acceleration. Thus, it is hard to change quickly
the direction of the movement.

Based on the UFO maipulator, I've implemented a manipulator closer to the
ones used in 3rd person games. I think it's documented enough and coded in a
simple way and so easy to review. So if some of you find it  promising and
useful, we could improve it and eventually submit it, so as to integrate it
in the osg Core.

Waiting for your suggestions.

Note: you may need to edit DoomLikeManipulator.cpp:16 #include
"../inc/DoomLikeManipulator.h" to get it compile.

-- 
Loïc Simon
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
 *
 * This library is open source and may be redistributed and/or modified under  
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 * 
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
 * OpenSceneGraph Public License for more details.
*/

#ifndef OSGGA_DOOM_LIKE_MANIPULATOR_DEF
#define OSGGA_DOOM_LIKE_MANIPULATOR_DEF 1

#include 

#include 
#include 
#include 

/**
  \class osgGA::DoomLikeManipulator
  \brief A DoomLike manipulator driven with keybindings.

  The DoomLikeManipulator is better suited for applications that employ architectural walk-throughs.
  The camera control is fone via keyboard arrows concerning the position and via mouse draging concerning the orientation.
  There are two modes : the horizontal and the free. In the free one the translation direction is exactly aligned with the view direction and thus can span the whole set of direction. In the other, the moving direction is constrained to remain horizontal. Note : horizontal mode is not implemented yet!!
  Unlike most of the other manipulators, the user controls directly the speed of the camera and not its acceleration.
  As a result, the user can achieve fast moves and yet change quickly the direction of the movement.

  The DoomLike Manipulator allows the following movements with the listed
  Key combinations:
\param SpaceBar Reset the view to the home position.
\param Shift/SpaceBar   Reset the up vector to the vertical.
\param UpArrow  Run forward.
\param DownArrowRun backward.
\param LeftArrowStep to the left.
\param RightArrow   Step to the right.
\param Shift/UpArrowMove up.
\param Shift/DownArrow  Move down.
\param Shift/Enter  Switch between horizontal and free mode.
\param DragMouseRotate the moving and looking direction.
*/

namespace osgGA {

class OSGGA_EXPORT DoomLikeManipulator : public osgGA::MatrixManipulator
{

public:
/** Default constructor */
DoomLikeManipulator();

/** return className
  \return returns constant "DoomLike"
  */
virtual const char* className() const;

/** Set the current position with a matrix 
  \param matrix  A viewpoint matrix.
 */
virtual void setByMatrix( const osg::Matrixd &matrix ) ;

/** Set the current position with the inverse matrix
  \param invmat The inverse of a viewpoint matrix
  */
virtual void setByInverseMatrix( const osg::Matrixd &invmat);

/** Get the current viewmatrix */
virtual osg::Matrixd getMatrix() const;

/** Get the current inverse view matrix */
virtual osg::Matrixd getInverseMatrix() const ;

/** Set the  subgraph this manipulator is driving the eye through.
\param node root of subgraph
 */
virtual void setNode(osg::Node* node);

/** Get the root node of the subgraph this manipulator is driving the eye through (const)*/
virtual const osg::Node* getNode() const;

/** Get the root node of the subgraph this manipulator is driving the eye through */
virtual osg::Node* getNode();

/** Computes the home position based on the extents and scale of the 
scene graph rooted at node */
virtual void computeHomePosition();

/** Sets the viewpoint matrix to the home position */
virtual void home(const osgGA::GUIEventAdapter&, osgGA::GUIActionAdapter&) ;
void home(double);

virtual void init(const GUIEventAdapter& ,GUIActionAdapter&);

/** Handles incoming osgGA events */
bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter &aa);

/** Reports Usage parameters to the application */

Re: [osg-users] Keyboard event

[Simon Loic]

My bad, I didn't see that a thread was already launched and treated this
problem : cf [osg-users] osg+QT MODKEY How to
It was due to the conversion of QT events into osg ones.
I've been through the thread and find work around but I'm not convinced it
is good for long term.

2009/3/17 Robert Osfield 

> HI Loic,
>
> What happens when you run the osgkeyboard example?
>
> I've just tried it and it detects the page up and page down without
> problems.  I'm working with Kubuntu 8.10.
>
> Robert.
>
> 2009/3/17 Simon Loic 
>
>> Hi,
>>
>> I faced the following problem with the osgGA::GUIEventAdapter::getKey().
>> When ever I press an arrow key or PageUp or PageDown it returns 0 instead
>> of the right key id.
>>
>> I noticed this behaviour on both windows and linux machines.
>>
>> Don't know if it makes a difference but I tried both  with my local
>> keyboard layout (french) and the US one.
>>
>> Has anyone noticed the same thing? Is there a workaround?
>>
>> --
>> Loïc Simon
>>
>> ___
>> 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
>
>


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

[osg-users] Keyboard event

[Simon Loic]

Hi,

I faced the following problem with the osgGA::GUIEventAdapter::getKey().
When ever I press an arrow key or PageUp or PageDown it returns 0 instead of
the right key id.

I noticed this behaviour on both windows and linux machines.

Don't know if it makes a difference but I tried both  with my local keyboard
layout (french) and the US one.

Has anyone noticed the same thing? Is there a workaround?

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

Re: [osg-users] FBO and WGL_ARB_render_texture

[Simon Loic]

hi Robert,
I get the same version string:
OpenGL version string: 2.1.2 NVIDIA 177.82
Yet I most probably have a less recent Graphics Card than you :
I have a NVidia Quadro FX 550
Do you think this is the reason?
Why doesn't it occur every time?

On Wed, Feb 25, 2009 at 9:20 PM, Robert Osfield wrote:

> Hi Loic,
>
> I've just done a testing of using --hdr in osgprerender (--fbo is the
> default where supported) and it works fine.  I'm using Kubuntu 8.10 +
> Geforce 8800GTS.
>
> glxinfo outputs lots of stuff including the version info:
>
> OpenGL version string: 2.1.2 NVIDIA 177.82
>
> Check which version you are using, as it does sounds like you are
> encountering a bug.  I'd also be worth checking what glxinfo reports
> as being supported - make sure it support HDR + FBO's.
> WGL_render_texture isn't required for FBO, and do export
> OSG_NOTIFY_LEVEL=DEBUG on my system doesn't produce any checks.
>
> The fact that your system is reporting this (benign) warning suggest
> to me that RenderStage::runCameraSetUp() has failed to set up an FBO
> render target, and is fallback back to using pbuffer.  I don't think
> pbuffer can support HDR.
>
> Robert.
> - Show quoted text -
>
>
> On Wed, Feb 25, 2009 at 6:39 PM, Simon Loic  wrote:
> > hi all,
> > I have some probelms when using FBO.
> > I have an Nvidia Quadro Fx 550, on an ubuntu 8.10 distribution
> >
> > when doing
> > osgprerender  --hdr --fbo  cow.osg
> >
> > Sometimes I get the following output:
> >
> >>> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
> >
> > With OSG_NOTIFY_LEVEL=DEBUG i get:
> >
> >>> WGL_ARB_render_texture is not supported.
> >
> > I find it strange that WGL_render_texture has to be supported as I
> thought
> > it was a Windows only extension.
> > Does this means that FBO can not be used on linux?
> >
> > I don't know why I get this message sometimes but not every time.
> >
> > BTW In my osg application I am doing FBO based screenshot, and I have the
> > same behaviour:
> > sometimes it works perfectly and dometimes I get this message and I get a
> > black image.
> >
> > Thanks guys
> >
> >
> > --
> > Loïc Simon
> >
> > ___
> > 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
>



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

[osg-users] FBO and WGL_ARB_render_texture

[Simon Loic]

hi all,
I have some probelms when using FBO.
I have an Nvidia Quadro Fx 550, on an ubuntu 8.10 distribution

when doing
osgprerender  --hdr --fbo  cow.osg

Sometimes I get the following output:

>> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd

With OSG_NOTIFY_LEVEL=DEBUG i get:

>> WGL_ARB_render_texture is not supported.

I find it strange that WGL_render_texture has to be supported as I thought
it was a Windows only extension.
Does this means that FBO can not be used on linux?

I don't know why I get this message sometimes but not every time.

BTW In my osg application I am doing FBO based screenshot, and I have the
same behaviour:
sometimes it works perfectly and dometimes I get this message and I get a
black image.

Thanks guys


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

Re: [osg-users] PositionAttituteTransform vs MatrixTransform

[Simon Loic]

And what about performance? Is there any difference for the culling
traversal for example?
Thanks

On Mon, Feb 16, 2009 at 10:19 PM, Paul Melis  wrote:

> Cory Riddell wrote:
> > Are these functionally equivalent? They seem like different ways of
> > accomplishing the same thing. True?
> >
> MatrixTransform is more general, in that you can specify any 4x4 matrix
> as your transform, specifically a matrix that can be a combination of
> simpler transforms (e.g. translate, scale, rotate, scale, translate,
> scale, rotate, etc). PAT's only provide a fixed sequence of
> transformation operations.
>
> Paul
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Cull time doubled?

[Simon Loic]

Hi all, I hope I'm not hijacking too much this thread. I just  wanted the
same kind of behaviour as Alex hoping it could help so let me know if I
should start a new thread.

Robert,
I checked for the Atomic Build and I got the same
include/OpenThreads/Config as yours.
Meanwhile when a switch the Threading model (pressing m) I don't see any
notable improvement.

I also tried to optimize my scene graph using the osgUtil::Optimizer with
different options. An I don' t get neither an improvement. I tryed the
following options :
-- 
osgUtil::Optimizer::FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS
(to rule the problem of PAT you mentionned previously)
-- osgUtil::Optimizer::STATIC_OBJECT_DETECTION
-- osgUtil::Optimizer::SPATIALIZE_GROUPS ( to get an octree structure)
-- osgUtil::Optimizer::SHARE_DUPLICATE_STATE (to handle duplicated
statesets)
-- osgUtil::Optimizer::COPY_SHARED_NODES

Here are my stats. Tell me if you think they are not normal considering that
my CG is not a brand new one but  a NVidia Quadro Fx 550 and the complexity
of the 3D scene.
Frame Rate : 8.5
Threading model: SingleThreaded
Event/Update/Cull/Draw/GPU:0.1/0.06/30/23/115
Vertices: 4.5M
Drawable:1382
Matrices:1382
triangle strips: 2.5M
polygons: 3k

This are thes stats I get in my own osg app. Note that the Threadingmodel is
SingleThreaded because so far I get a segmentation fault when switching it
in this app. But this is not the case in osgViewer.

Here are the stats for the same model in osgviewer:
Frame Rate : 7.5
Threading model: DrawThreadPerContext
Event/Update/Cull/Draw/GPU:0.1/0.06/42/86/117
Vertices: 4.5M
Drawable:1382
Matrices:1382
triangle strips: 2.5M
polygons: 3k

By the way I've also tried using small feature culling. I know it's enabled
by default but there is a parameter which I don'tknow the default value :
SmallFeatureCullingPixelSize. What would be a reasonable value for it.


On Thu, Feb 12, 2009 at 10:25 AM, Robert Osfield
wrote:

> Hi Alex,
>
> You would be best served in your investigation by attaching the
> osgViewer::StatsHandler to your viewer.  See the osgviewer.cpp example
> code to see how.  This event handler will give you some pretty useful
> on screen stats.
>
> With the DrawThreadPerContext threading model what you should get is
> the update + cull overlapping with the previous draw dispatch/gpu.
> What I have see is that if the processor is overly contended then the
> the cull and draw times go down.  Processor affinity is set by
> osgViewer which should avoid this contention.
>
> The other thing to look at is the DataVariance, in 2.x it's by default
> using a value UNSPECIFIED, which means you haven't set it yet.  For
> your StateSet and Drawables you make sure that if they don't contain
> any dynamic data that they are set to STATIC, and if they contain
> dynamic data make sure it's set to DYNAMIC.   The more STATIC you have
> the more the frames will be able to overlap. The Optimizer has a
> visitor that can help set the DataVaraince to either STATIC or
> DYNAMIC, but will only override it if the value is currently
> UNSPECIFIED.
>
> Robert.
>
> On Thu, Feb 12, 2009 at 12:17 AM, Pecoraro, Alexander N
>  wrote:
> > Hi again,
> >
> >>> Might I suggest you examine the actual frame rates you get once again
> > now that the atomic ref counts are in place.
> >
> > Here are some performance metrics that I get when running with atomic
> > reference counting in OSG 2.6 (these don't correspond to the numbers in
> > my previous email, which were from osgviewer, whereas these numbers come
> > from my OSG based application, which is doing a little more work than
> > osgviewer during the update stage - the scene graph is the same as
> > before, but the viewpoint is different):
> >
> > OSG 2.6 Frame Rate/Update/Cull/Draw/GPU: 29/1/21/34/25
> > OSG 1.2 Frame Rate/Update/Cull/Draw/GPU: 27/1/ 9/27/25
> >
> > I can get a faster frame rate in 2.6 because the frame rate is tied to
> > the draw time only (due to DrawThreadPerContext functionality), whereas
> > in 1.2 the cull and draw time are the biggest contributors to the frame
> > rate.
> >
> > If I could somehow get my 2.6 draw time to be the same as the 1.2 draw
> > time then I could get my frame rate up to 36 - 37.
> >
> >>> One does need to make sure that your scene graph is set up with
> > STATIC + DYNAMIC DataVariance correctly to allow the frames to overlap
> > the most without endangering thread safety.
> >
> > I was actually wondering about this. Is the fact that my cull and draw
> > times improve to 16 and 31 when I run single threaded in 2.6 possibly
> > indicative of my data variance settings preventing me from obtaining
> > optimal frame overlap?
> >
> > Is the basic rule for setting the data variance on a node is if any of
> > the values on the Node is going to change at any time during runtime
> > then it should be set to DYNAMIC?
> >
> > Thanks.
> >
> > Alex
> >
> > -Original Message-
> > From: osg-users-boun...@lists.openscenegraph.org

Re: [osg-users] Cull time doubled?

[Simon Loic]

One thing I would like to try before balancing the scene graph is to use
osgUtil::Optimizer in order to diagnose the problem of my scene graph. Do
you think this make sense? If yes can someone explain me quickly the effect
of the different optimizer options or just point me to a document which does
so.

Thanks a lot.

On Tue, Feb 10, 2009 at 10:46 PM, Simon Loic  wrote:

> I'm quite interesting in getting my scenegraph  more balanced scenegraph. I
> will take the time to think about it (and probably ask for help then).
>
> Concerning the  _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS I didn't get how to
> generate the include/OpenThreads/Config file. Anyway, I don't get neither
> how it can come into play as I'm profiling with the SingleThreaded option
> and the results are too bad.
>
> regards,
>
>
> On Tue, Feb 10, 2009 at 5:32 PM, Robert Osfield 
> wrote:
>
>> Hi Simon,
>>
>> Like Alex I recommend that you have a look at whether your build is
>> using atomic ref counts.
>>
>> Second up, your explanation of your scene graphs suggest to me that is
>> very poorly balanced.  You cull/draw times are all very long, even for
>> complex scenes I would expect cull and draw times 1/10th of these.
>>
>> Lots of PAT's all under a single Group node is really badly balanced -
>> you should try to create a quad tree structure as this improves cull
>> performance significantly as how subgraphs containing thousands of
>> nodes can be culled in a single op.  Also see if you can use an design
>> that doesn't rely heavily of PAT's, as each transform in your scene
>> requires the view frustum to be transformed into the local coords of
>> the PAT, which is relative expensive operation.
>>
>> Robert.
>>
>> On Tue, Feb 10, 2009 at 8:50 AM, Simon Loic  wrote:
>> > I think I have a problem similar to Alex one.
>> > The stats I get follow :
>> >
>> > MultiThreaded/SingleThreaded
>> > Cull Time:  40/33
>> > Draw Time:  55/52
>> > GPU Time:   85/85
>> >
>> > I also attached a callgrind output (you can use kcachegrind to analyse
>> it)
>> > where it seems that the osgUtil::SceneView::cull() costs 70% of
>> > osgViewer::Renderer::cull_draw() while osgUtil::SceneView::draw() counts
>> for
>> > only 30% !! However I'm not  much aware with the way osgViewer works,
>> yet I
>> > find this result weird in comparison with the stats results.
>> >
>> > In my case I have a scene graph composed of many nodes (i don't think I
>> can
>> > post the .osg which is 16MB). The strucuture is not complex : I have a
>> > shadow scene as root with as child a group (the real root of the graph
>> some
>> > how). Then the root is connected to plenty of PositionAttitudeTransfoms
>> > having each one a child which is a geode.
>> >
>> > In fact the geode are quite complex polygonal meshes. So I would expect
>> that
>> > the draw part is more costly than the draw part.
>> > I hope this can  help to see what is wrong for Alex and for me.
>> >
>> >
>> > On Tue, Feb 10, 2009 at 7:54 AM, J.P. Delport 
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Mathias Fröhlich wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Monday 09 February 2009 23:54, Pecoraro, Alexander N wrote:
>> >>>>
>> >>>> On Linux this translated to "-O3 -DNDEBUG" (at least that's what
>> >>>> cmake-gui says is defined for the CMAKE_CXX_FLAGS_RELEASE variable).
>> >>>
>> >>> May be I know cmake to little, but the only way to really make sure I
>> got
>> >>> cmake correct was to set CMAKE_VERBOSE_MAKEFILE=TRUE and see how the
>> build
>> >>> scripts really call the compiler.
>> >>
>> >> you can also run make  VERBOSE=1
>> >> on the normal cmake generated Makefile.
>> >>
>> >> jp
>> >>
>> >>>
>> >>> Robert,
>> >>> I know that it is a matter of taste if one sets this flag. But may be
>> it
>> >>> will help people to catch unoptimized builds due to the possible
>> >>> intransparency of cmakes compile flags handling. So should that be on
>> by
>> >>> default?
>> >>>
>> >>> Greetings
>> >>>
>> >>> Mathias
>> >>>
>> >>
>> >> --

Re: [osg-users] Cull time doubled?

[Simon Loic]

I'm quite interesting in getting my scenegraph  more balanced scenegraph. I
will take the time to think about it (and probably ask for help then).

Concerning the  _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS I didn't get how to
generate the include/OpenThreads/Config file. Anyway, I don't get neither
how it can come into play as I'm profiling with the SingleThreaded option
and the results are too bad.

regards,

On Tue, Feb 10, 2009 at 5:32 PM, Robert Osfield wrote:

> Hi Simon,
>
> Like Alex I recommend that you have a look at whether your build is
> using atomic ref counts.
>
> Second up, your explanation of your scene graphs suggest to me that is
> very poorly balanced.  You cull/draw times are all very long, even for
> complex scenes I would expect cull and draw times 1/10th of these.
>
> Lots of PAT's all under a single Group node is really badly balanced -
> you should try to create a quad tree structure as this improves cull
> performance significantly as how subgraphs containing thousands of
> nodes can be culled in a single op.  Also see if you can use an design
> that doesn't rely heavily of PAT's, as each transform in your scene
> requires the view frustum to be transformed into the local coords of
> the PAT, which is relative expensive operation.
>
> Robert.
>
> On Tue, Feb 10, 2009 at 8:50 AM, Simon Loic  wrote:
> > I think I have a problem similar to Alex one.
> > The stats I get follow :
> >
> > MultiThreaded/SingleThreaded
> > Cull Time:  40/33
> > Draw Time:  55/52
> > GPU Time:   85/85
> >
> > I also attached a callgrind output (you can use kcachegrind to analyse
> it)
> > where it seems that the osgUtil::SceneView::cull() costs 70% of
> > osgViewer::Renderer::cull_draw() while osgUtil::SceneView::draw() counts
> for
> > only 30% !! However I'm not  much aware with the way osgViewer works, yet
> I
> > find this result weird in comparison with the stats results.
> >
> > In my case I have a scene graph composed of many nodes (i don't think I
> can
> > post the .osg which is 16MB). The strucuture is not complex : I have a
> > shadow scene as root with as child a group (the real root of the graph
> some
> > how). Then the root is connected to plenty of PositionAttitudeTransfoms
> > having each one a child which is a geode.
> >
> > In fact the geode are quite complex polygonal meshes. So I would expect
> that
> > the draw part is more costly than the draw part.
> > I hope this can  help to see what is wrong for Alex and for me.
> >
> >
> > On Tue, Feb 10, 2009 at 7:54 AM, J.P. Delport 
> wrote:
> >>
> >> Hi,
> >>
> >> Mathias Fröhlich wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Monday 09 February 2009 23:54, Pecoraro, Alexander N wrote:
> >>>>
> >>>> On Linux this translated to "-O3 -DNDEBUG" (at least that's what
> >>>> cmake-gui says is defined for the CMAKE_CXX_FLAGS_RELEASE variable).
> >>>
> >>> May be I know cmake to little, but the only way to really make sure I
> got
> >>> cmake correct was to set CMAKE_VERBOSE_MAKEFILE=TRUE and see how the
> build
> >>> scripts really call the compiler.
> >>
> >> you can also run make  VERBOSE=1
> >> on the normal cmake generated Makefile.
> >>
> >> jp
> >>
> >>>
> >>> Robert,
> >>> I know that it is a matter of taste if one sets this flag. But may be
> it
> >>> will help people to catch unoptimized builds due to the possible
> >>> intransparency of cmakes compile flags handling. So should that be on
> by
> >>> default?
> >>>
> >>> Greetings
> >>>
> >>> Mathias
> >>>
> >>
> >> --
> >> This message is subject to the CSIR's copyright terms and conditions,
> >> e-mail legal notice, and implemented Open Document Format (ODF)
> standard.
> >> The full disclaimer details can be found at
> >> http://www.csir.co.za/disclaimer.html.
> >>
> >> This message has been scanned for viruses and dangerous content by
> >> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
> >> Computers for their support.
> >>
> >> ___
> >> osg-users mailing list
> >> osg-users@lists.openscenegraph.org
> >>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> >
> > --
> > Loïc Simon
> >
> > ___
> > 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
>



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

Re: [osg-users] Histroy Buffer Implementation / Suggestion

[Simon Loic]

Thanks for the tip Adrian but so far I'am facing problems with PSSM .
I get the following output :

RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
Warning: FrameBufferObject: could not create the FBO
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0
Warning: FrameBufferObject: could not create the FBO
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0
FRAGMENT glCompileShader "" FAILED
glLinkProgram "" FAILED

I don't know why. I have tested FBO support with osgprerender --hdr --fbo
cow.osg and it works.

On Mon, Feb 2, 2009 at 9:31 AM, Adrian Egli OpenSceneGraph (3D) <
3dh...@gmail.com> wrote:

> Hello all
>
> You should use lispsm or pssm shadow : even for terrain this gives nice
> looking shadows (with pssm you can limit the max far distance, use this say
> 250m, and you will get nice shadows) but once we have the latest idea
> implemented, the shadow quality gets much better, this would be of sure
> true, but may the performance will
> be very bad. so i am looking for high performance and robust technic.
>
> I don't really like to implement this with osgPPU, because of the problem
> robert told (see submission discussion) not tha osgPPU is bad, but it would
> better be nicely integrated into osg and osgShadow, not only for osgShadow
> and its quality the histroy buffer could have high impact, also for others
> shaders.
>
> Then for the default shader in openscenegraph may we should think to
> redesign them, because actually we have shaders in shadow, ... , but each of
> the re-writes the very basics, may we could think about of GLSL shader
> modules, code modules then we can put them together, this would be greate. i
> have some idea how this could be solved. but i have to think about more of
> this idea.
>
> /adrian
>
> 2009/2/1 Simon Loic 
>
> It would be very interested to see the resulting shadows of this method in
>> osg. I'am currently using the basic shadow technic and the rendering is so
>> aliased! Maybe I'am not using it in the right way.
>>
>>
>> On Fri, Jan 30, 2009 at 4:44 PM, Art Tevs  wrote:
>>
>>> Hi Adrian,
>>>
>>> for all 2D effects there exists already a pipeline with couple of
>>> examples (gauss blurr, depth of field, hdr and so on), however you maybe
>>> have heard about it already. Take a look into osgPPU.
>>>
>>> I took a small look into the paper and saw that the main method is just
>>> to combine N previous images in some sense together to achieve nice results.
>>> As you said, using the history buffer. Using pure osg components, one could
>>> for example setup N cameras with corresponding textures and switch them
>>> framewise. Then current rendering camera use the input of other N-1 cameras
>>> to produce its new output. Using osgPPU, I would suggest to implement new
>>> class UnitHistoryBuffer, which will do this trick, by collecting the inputs
>>> in some buffer, e.g. 3D texture or 2D texture array. Output of this unit can
>>> then be combined with current rendering camera in the way as described in
>>> the paper. This shouldn't be a big trick, yeah, maybe I can do this for the
>>> upcoming v0.4 release ;)
>>>
>>> I am wonder if one could use this technique for some sreen space effects,
>>> not only for motionblur, but also for optical flow detection or something
>>> similar ??? Maybe for something like hybrid ray tracing approach, where some
>>> kind of heuristic function could use this information to retrace only
>>> neccessary rays.
>>>
>>> cheers,
>>> art
>>>
>>> --
>>> Read this topic online here:
>>> http://osgforum.tevs.eu/viewtopic.php?p=5545#5545
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>>
>>
>> --
>> Loïc Simon
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> --
> 
> Adrian Egli
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] CPU usage

[Simon Loic]

Hi Adrian,
 Even with --SingleThreaded option one core is used at 100%.
Tell me if I should do other tests.

On Mon, Feb 2, 2009 at 9:25 AM, Adrian Egli OpenSceneGraph (3D) <
3dh...@gmail.com> wrote:

> Greate news (or bad news) that means we have not a windows issue. what
> happens when you switch to singelthreaded ?
>
> /adrian
>
> 2009/2/1 Simon Loic 
>
> Hi,
>> in my case when I am runing osgviewer on a ubuntu distribution with 4
>> cores I get 25% of cpu, which means that one of my cores is over used. One
>> of my colleagues have exactly the same behavior. Thus I don't think this is
>> windows related only.
>>
>>
>> On Sun, Feb 1, 2009 at 2:55 PM, Glenn Waldron  wrote:
>>
>>> Adrian,
>>>
>>> I have observed an intermittent problem on Windows in which osgviewer
>>> starts up using a high CPU %, but then cycling through the threading
>>> modes with 'm' makes the problem go away - even when you return to the
>>> mode in which you started. I never did figure out why.
>>>
>>> Just a data point...
>>>
>>>
>>> Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
>>> +1.703.652.4791
>>>
>>>
>>>
>>> On Sun, Feb 1, 2009 at 7:45 AM, Adrian Egli OpenSceneGraph (3D)
>>> <3dh...@gmail.com> wrote:
>>> > Hi Cory,
>>> >
>>> > I am working with Windows Vista dual core system. I get 50% CPU usage
>>> when i
>>> > am running osgviewer cow.osg if i start
>>> > osgviewer cow.osg --SingleThreaded i have no longer 50% CPU usage , now
>>> i
>>> > have about 0.5-3% CPU usage !
>>> >
>>> > i am very busy at the moment, but may tomorrow i will debug the OSG
>>> core,
>>> > may there is a bug inside or a thread running at max.
>>> > or robert has some idea,where i can start with debugging. may it's a
>>> windows
>>> > vista bug
>>> >
>>> > adrian
>>> >
>>> >
>>> > 2009/2/1 Robert Osfield 
>>> >>
>>> >> Hi Cory,
>>> >>
>>> >> I'll have to defer to others on the situation under Windows when doing
>>> >> remote desktop.  My guess is that it's likely to be a driver issue.
>>> >>
>>> >> Robert.
>>> >>
>>> >> On Sat, Jan 31, 2009 at 3:27 PM, Cory Riddell 
>>> wrote:
>>> >> > I'm not sure about vysync. I'll look that up and check it.
>>> >> >
>>> >> > I thought about the possibility of it being a debug build and I
>>> don't
>>> >> > think
>>> >> > that's it. In my bin directory I have osgviewer.exe at 25,600 bytes
>>> and
>>> >> > osgviewerd.exe at 81,920 bytes. Both executables give me the same
>>> CPU
>>> >> > pegging behavior (as observed by SysInternals Process Explorer).
>>> >> >
>>> >> > My command line is "osgviewer.exe --window 100 100 200 200
>>> cessna.osg".
>>> >> > My
>>> >> > video card is an ATI FireGL V7700 and the drivers are up to date.
>>> >> >
>>> >> > Ah- I just noticed something-- an error message:
>>> >> > Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() -
>>> >> > wglChoosePixelFormatARB extension not found, trying GDI. Reason: The
>>> >> > specified procedure could not be found.
>>> >> >
>>> >> > I'm running over remote desktop right now, so perhaps that's
>>> related. I
>>> >> > don't recall seeing this error message before.
>>> >> >
>>> >> > Cory
>>> >> >
>>> >> > On Sat, Jan 31, 2009 at 3:54 AM, Robert Osfield
>>> >> > 
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Cory,
>>> >> >>
>>> >> >> It's not normal to have this high level of CPU usage for this
>>> model,
>>> >> >> the expceptions to this would be:
>>> >> >>
>>> >> >>You have vysync switched off, so the app is racing as fast it
>>> can
>>> >> >> to dispatch frames
>>> >> >>You've compiled the OSG with debug build.
>>> >> >

Re: [osg-users] Histroy Buffer Implementation / Suggestion

[Simon Loic]

It would be very interested to see the resulting shadows of this method in
osg. I'am currently using the basic shadow technic and the rendering is so
aliased! Maybe I'am not using it in the right way.

On Fri, Jan 30, 2009 at 4:44 PM, Art Tevs  wrote:

> Hi Adrian,
>
> for all 2D effects there exists already a pipeline with couple of examples
> (gauss blurr, depth of field, hdr and so on), however you maybe have heard
> about it already. Take a look into osgPPU.
>
> I took a small look into the paper and saw that the main method is just to
> combine N previous images in some sense together to achieve nice results. As
> you said, using the history buffer. Using pure osg components, one could for
> example setup N cameras with corresponding textures and switch them
> framewise. Then current rendering camera use the input of other N-1 cameras
> to produce its new output. Using osgPPU, I would suggest to implement new
> class UnitHistoryBuffer, which will do this trick, by collecting the inputs
> in some buffer, e.g. 3D texture or 2D texture array. Output of this unit can
> then be combined with current rendering camera in the way as described in
> the paper. This shouldn't be a big trick, yeah, maybe I can do this for the
> upcoming v0.4 release ;)
>
> I am wonder if one could use this technique for some sreen space effects,
> not only for motionblur, but also for optical flow detection or something
> similar ??? Maybe for something like hybrid ray tracing approach, where some
> kind of heuristic function could use this information to retrace only
> neccessary rays.
>
> cheers,
> art
>
> --
> Read this topic online here:
> http://osgforum.tevs.eu/viewtopic.php?p=5545#5545
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] CPU usage

[Simon Loic]

Hi,
in my case when I am runing osgviewer on a ubuntu distribution with 4 cores
I get 25% of cpu, which means that one of my cores is over used. One of my
colleagues have exactly the same behavior. Thus I don't think this is
windows related only.

On Sun, Feb 1, 2009 at 2:55 PM, Glenn Waldron  wrote:

> Adrian,
>
> I have observed an intermittent problem on Windows in which osgviewer
> starts up using a high CPU %, but then cycling through the threading
> modes with 'm' makes the problem go away - even when you return to the
> mode in which you started. I never did figure out why.
>
> Just a data point...
>
>
> Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
> +1.703.652.4791
>
>
>
> On Sun, Feb 1, 2009 at 7:45 AM, Adrian Egli OpenSceneGraph (3D)
> <3dh...@gmail.com> wrote:
> > Hi Cory,
> >
> > I am working with Windows Vista dual core system. I get 50% CPU usage
> when i
> > am running osgviewer cow.osg if i start
> > osgviewer cow.osg --SingleThreaded i have no longer 50% CPU usage , now i
> > have about 0.5-3% CPU usage !
> >
> > i am very busy at the moment, but may tomorrow i will debug the OSG core,
> > may there is a bug inside or a thread running at max.
> > or robert has some idea,where i can start with debugging. may it's a
> windows
> > vista bug
> >
> > adrian
> >
> >
> > 2009/2/1 Robert Osfield 
> >>
> >> Hi Cory,
> >>
> >> I'll have to defer to others on the situation under Windows when doing
> >> remote desktop.  My guess is that it's likely to be a driver issue.
> >>
> >> Robert.
> >>
> >> On Sat, Jan 31, 2009 at 3:27 PM, Cory Riddell 
> wrote:
> >> > I'm not sure about vysync. I'll look that up and check it.
> >> >
> >> > I thought about the possibility of it being a debug build and I don't
> >> > think
> >> > that's it. In my bin directory I have osgviewer.exe at 25,600 bytes
> and
> >> > osgviewerd.exe at 81,920 bytes. Both executables give me the same CPU
> >> > pegging behavior (as observed by SysInternals Process Explorer).
> >> >
> >> > My command line is "osgviewer.exe --window 100 100 200 200
> cessna.osg".
> >> > My
> >> > video card is an ATI FireGL V7700 and the drivers are up to date.
> >> >
> >> > Ah- I just noticed something-- an error message:
> >> > Windows Error #127: [Screen #0] ChooseMatchingPixelFormat() -
> >> > wglChoosePixelFormatARB extension not found, trying GDI. Reason: The
> >> > specified procedure could not be found.
> >> >
> >> > I'm running over remote desktop right now, so perhaps that's related.
> I
> >> > don't recall seeing this error message before.
> >> >
> >> > Cory
> >> >
> >> > On Sat, Jan 31, 2009 at 3:54 AM, Robert Osfield
> >> > 
> >> > wrote:
> >> >>
> >> >> Hi Cory,
> >> >>
> >> >> It's not normal to have this high level of CPU usage for this model,
> >> >> the expceptions to this would be:
> >> >>
> >> >>You have vysync switched off, so the app is racing as fast it can
> >> >> to dispatch frames
> >> >>You've compiled the OSG with debug build.
> >> >>
> >> >> Robert.
> >> >>
> >> >> On Fri, Jan 30, 2009 at 8:36 PM, Cory Riddell 
> >> >> wrote:
> >> >> > When I run the osg viewer app and load just about any osg file
> (like
> >> >> > cesna.osg), my CPU usage is a constant 23% - 30%. This is with no
> >> >> > interaction, it is basically using an entire CPU core. Fortunatelly
> I
> >> >> > have a
> >> >> > 4 core machine, so it hasn't been a problem so far, but I'm
> wondering
> >> >> > what
> >> >> > this means for single core machines (which most of our customers
> >> >> > have).
> >> >> >
> >> >> > Is this typical?
> >> >> >
> >> >> > Cory
> >> >> >
> >> >> > ___
> >> >> > 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
> >> >
> >> >
> >> > ___
> >> > 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
> >
> >
> >
> > --
> > 
> > Adrian Egli
> >
> > ___
> > 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-

Re: [osg-users] High resolution screencast

[Simon Loic]

Hi Jeremy,
I have a Nvidia Card, so thanks for your tip? Yet I don't undertand what
it's supposed to do exactly.

On Fri, Jan 9, 2009 at 9:43 PM, Jeremy Moles wrote:

> On Fri, 2009-01-09 at 19:33 +0100, Simon Loic wrote:
> > Ok forget about it it was a problem of -fPic flag in the compilation
> > of some libraries.
> > The next step is to make osg framerate constant in order to get smooth
> > videos. If I undertood well what was said before this consists in
> > rewriting the Mainloop of the viewer. I'll try this soon.
>
> It's much easier if you're using an NVidia card! :) Here are two bash
> functions I wrote to help:
>
> # Run an OpenGL application with antialiasing.
> function __fsaa() {
>if [ -z "${*}" ]; then
>echo -e "usage: fsaa NUM CMDLINE\n"
>echo -e "\t0 = FSAA disabled"
>echo -e "\t1 = 2x Bilinear Multisampling"
>echo -e "\t2 = 2x Quincunx Multisampling"
>echo -e "\t3 = FSAA disabled"
>echo -e "\t4 = 4x Bilinear Multisampling"
>echo -e "\t5 = 4x Gaussian Multisampling"
>echo -e "\t6 = 2x Bilinear Multisampling 4x SS"
>echo -e "\t7 = 4x Bilinear Multisampling 4x SS"
>echo -e "\t8 = 4x Bilinear Multisampling 2x SS\n"
>
>return 1
>
>else
>local MODE="${1}"
>
>shift 1
>
>eval "__GL_FSAA_MODE=${MODE} ${*}"
>fi
> }
>
> # Run an OpenGL application with vsync enabled.
> function __glsync() {
>eval "__GL_SYNC_TO_VBLANK=1 ${*}"
> }
>
> ...
>
> Once you've added these to your bashrc, you can do something like this:
>
># __glsync osgviewer
>
> ...or...
>
># __fsaa 4 __glsync osgviewer
>
> The general idea is to export the __GL_* variables properly. :)
>
> > Thanks once again.
> >
> > On Thu, Jan 8, 2009 at 10:56 AM, Simon Loic 
> > wrote:
> > Hi, I'm back at work and I can give you the details.
> >
> > The first problem I had was at compile time. I think it was
> > linked with conflicting definitions. Here is the error
> > message.
> >
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > /bin/mkdir -p bc/gl
> > perl ./gengl/gengl.perl --mode=alias "/usr/include/GL/gl.h"
> > "/usr/include/GL/glx.h" "/usr/include/GL/glext.h"
> > "/usr/include/GL/glxext.h"  > bc/gl/alias.bc
> > glFramebufferTextureLayerEXT is defined in both
> > GL_NV_geometry_program4 and GL_EXT_texture_array
> > at ./gengl/gengl.perl line 436,  line 10154.
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> > To solve it I did something quite ugly : I commented the
> > mentioned line 436 of gengl/gengl.perl. After that  It
> > compiles but I looking forward a better fix.
> >
> > The second problem I get is the more important. The bugle
> > filterset associated with screen capture is not recognised.
> > I get the following warning :
> >
> >
> > >>>  warning: ignoring unknown filter-set screenshot
> >
> > BTW, Im using the following command :
> >
> > >>> BUGLE_CHAIN=video LD_PRELOAD=libbugle.so my_application
> >
> > with the following chain:
> >
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > # Captures a video file.
> > chain video
> > {
> > # Press C-V to start and to stop recording. By removing
> > the "inactive"
> > # tag, recording will start immediately.
> > filterset screenshot C-V inactive
> > {
> > video "yes"
> > filename "bugle.avi"
> >
> > # You can in theory use any codec supported by ffmpeg
> > codec "mpeg4"
> >
> > # Roughly DVD size, although no high quality options
> > are set
> >

Re: [osg-users] High resolution screencast

[Simon Loic]

Ok forget about it it was a problem of -fPic flag in the compilation of some
libraries.
The next step is to make osg framerate constant in order to get smooth
videos. If I undertood well what was said before this consists in
rewriting the Mainloop of the viewer. I'll try this soon.

Thanks once again.

On Thu, Jan 8, 2009 at 10:56 AM, Simon Loic  wrote:

> Hi, I'm back at work and I can give you the details.
>
> The first problem I had was at compile time. I think it was linked with
> conflicting definitions. Here is the error message.
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> /bin/mkdir -p bc/gl
> perl ./gengl/gengl.perl --mode=alias "/usr/include/GL/gl.h"
> "/usr/include/GL/glx.h" "/usr/include/GL/glext.h"
> "/usr/include/GL/glxext.h"  > bc/gl/alias.bc
> glFramebufferTextureLayerEXT is defined in both GL_NV_geometry_program4 and
> GL_EXT_texture_array at ./gengl/gengl.perl line 436,  line 10154.
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> To solve it I did something quite ugly : I commented the mentioned line 436
> of gengl/gengl.perl. After that  It compiles but I looking forward a better
> fix.
>
> The second problem I get is the more important. The bugle filterset
> associated with screen capture is not recognised.
> I get the following warning :
>
>
> >>>  warning: ignoring unknown filter-set screenshot
>
> BTW, Im using the following command :
>
> >>> BUGLE_CHAIN=video LD_PRELOAD=libbugle.so my_application
>
> with the following chain:
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> # Captures a video file.
> chain video
> {
> # Press C-V to start and to stop recording. By removing the "inactive"
> # tag, recording will start immediately.
> filterset screenshot C-V inactive
> {
> video "yes"
> filename "bugle.avi"
>
> # You can in theory use any codec supported by ffmpeg
> codec "mpeg4"
>
> # Roughly DVD size, although no high quality options are set
> bitrate "750"
>
> # By default, a frame is captured every 30th of a second, with
> # frames skipped or duplicated as necessary. Uncomment this
> # line to instead capture every frame exactly once to the
> # output.
> # allframes "yes"
>
> # Control the encoding latency. A higher latency may give
> # better throughput, at the expense of more memory.
> # lag "1"
> }
> }
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> Just so you know, here is the recap of the configure script call (it may
> help):
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> Configuration:
> libavcodec: yes
> readline: yes
> GUI: yes (with OpenGL)
> X event interception: yes
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> Thanks very much.
>
>
> On Wed, Jan 7, 2009 at 11:38 PM, Simon Loic  wrote:
>
>> I tried it but I encountered few problems. I will send you the detailed
>> tomorrow. Still thanks for the tip.
>>
>>
>> On Tue, Jan 6, 2009 at 5:40 PM, Jeremy Moles wrote:
>>
>>> Not trying to hijack this thread--and I can't really read it all for now
>>> because I'm still fighting off lots of complications from a recent oral
>>> surgery--but what you want is called "bugle." I used it to make all of
>>> the old osgWidget and osgPango videos and it works like a charm.
>>>
>>> What it does is LD_PRELOAD's glSwap() or whatever and replaces it with a
>>> version that shimmies off data to ffmpeg for encoding. Simple, clean,
>>> and easy for basic usage.
>>>
>>> On Thu, 2008-12-18 at 20:38 +0100, Simon Loic wrote:
>>> > Hi,
>>> >
>>> > I apology in advance if this thread have been heavily answered before
>>> > (if so just tell where I can find the solution). Still I would like to
>>> > know the different alternative (the good ones) to record a video of my
>>> > scene.
>

Re: [osg-users] Exportable file formats

[Simon Loic]

I did a fresh update of OSG. And it seems that things have changed since my
last update. Anyway the dae plugin doesn't seem reliable yet. I submitted a
bug description on the osg-submission ml.

regards,
Loic.

On Thu, Jan 8, 2009 at 1:15 PM, J.P. Delport  wrote:

> Hi,
>
> "osgconv --formats" spits out lots of stuff, I'm not sure how to parse it
> though.
>
> jp
>
>
> Morné Pistorius wrote:
>
>> Hi guys,
>>
>> I am trying to figure out which of the osg plugins support
>> writing/exporting.  Is there a list of supported formats or a way to
>> query osg to find out which plugins support exporting?  I will be
>> happy if I can just get a handful - from comments read on the list, I
>> think these are all supported:
>>
>> osg
>> ive
>> obj
>> flt
>> collada (dae)
>>
>> Thanks,
>> Morne
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
> Computers for their support.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Exportable file formats

[Simon Loic]

Hi, I didn't try all of them but I'm quite sure that not all are well
handled.
It's quite sure that osg and ive are ok as they are native format.
Concerning obj In my config the texture are missing after exporting.
And for collada, I think that there many inconsistencies between the
implementation of this pluggin and the collada specification . For example I
submitted with a friend a bug fix related to the angles unit :
This unit was not even the same when reading and when writing collada... So
if you were exporting a model to collada and then reload it in osg you could
find a completely different model (as soon as rotations were involved).
I know that this bug fix was accepted but I have the feeling that something
is still wrong. I didn't have time so far to diagnose the problem but look
what I found. If I save my scene to collada and then I load it in blender I
dont have the same scene (cf inOSG.jpg and in blender.jpg)

May be the blender plugin is troublesome and not the one of OSG I don't
know. I will try to update osg to the las trunk commit and see if things get
better.

Loic



On Thu, Jan 8, 2009 at 11:10 AM, Morné Pistorius <
mpistorius@googlemail.com> wrote:

> Hi guys,
>
> I am trying to figure out which of the osg plugins support
> writing/exporting.  Is there a list of supported formats or a way to
> query osg to find out which plugins support exporting?  I will be
> happy if I can just get a handful - from comments read on the list, I
> think these are all supported:
>
> osg
> ive
> obj
> flt
> collada (dae)
>
> Thanks,
> Morne
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] High resolution screencast

[Simon Loic]

Hi, I'm back at work and I can give you the details.

The first problem I had was at compile time. I think it was linked with
conflicting definitions. Here is the error message.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
/bin/mkdir -p bc/gl
perl ./gengl/gengl.perl --mode=alias "/usr/include/GL/gl.h"
"/usr/include/GL/glx.h" "/usr/include/GL/glext.h"
"/usr/include/GL/glxext.h"  > bc/gl/alias.bc
glFramebufferTextureLayerEXT is defined in both GL_NV_geometry_program4 and
GL_EXT_texture_array at ./gengl/gengl.perl line 436,  line 10154.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

To solve it I did something quite ugly : I commented the mentioned line 436
of gengl/gengl.perl. After that  It compiles but I looking forward a better
fix.

The second problem I get is the more important. The bugle filterset
associated with screen capture is not recognised.
I get the following warning :


>>>  warning: ignoring unknown filter-set screenshot

BTW, Im using the following command :

>>> BUGLE_CHAIN=video LD_PRELOAD=libbugle.so my_application

with the following chain:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
# Captures a video file.
chain video
{
# Press C-V to start and to stop recording. By removing the "inactive"
# tag, recording will start immediately.
filterset screenshot C-V inactive
{
video "yes"
filename "bugle.avi"

# You can in theory use any codec supported by ffmpeg
codec "mpeg4"

# Roughly DVD size, although no high quality options are set
bitrate "750"

# By default, a frame is captured every 30th of a second, with
# frames skipped or duplicated as necessary. Uncomment this
# line to instead capture every frame exactly once to the
# output.
# allframes "yes"

# Control the encoding latency. A higher latency may give
# better throughput, at the expense of more memory.
# lag "1"
}
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Just so you know, here is the recap of the configure script call (it may
help):

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Configuration:
libavcodec: yes
readline: yes
GUI: yes (with OpenGL)
X event interception: yes
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Thanks very much.

On Wed, Jan 7, 2009 at 11:38 PM, Simon Loic  wrote:

> I tried it but I encountered few problems. I will send you the detailed
> tomorrow. Still thanks for the tip.
>
>
> On Tue, Jan 6, 2009 at 5:40 PM, Jeremy Moles wrote:
>
>> Not trying to hijack this thread--and I can't really read it all for now
>> because I'm still fighting off lots of complications from a recent oral
>> surgery--but what you want is called "bugle." I used it to make all of
>> the old osgWidget and osgPango videos and it works like a charm.
>>
>> What it does is LD_PRELOAD's glSwap() or whatever and replaces it with a
>> version that shimmies off data to ffmpeg for encoding. Simple, clean,
>> and easy for basic usage.
>>
>> On Thu, 2008-12-18 at 20:38 +0100, Simon Loic wrote:
>> > Hi,
>> >
>> > I apology in advance if this thread have been heavily answered before
>> > (if so just tell where I can find the solution). Still I would like to
>> > know the different alternative (the good ones) to record a video of my
>> > scene.
>> > So far I was using an external tool for screenCast (called istanbul).
>> > But I'm not satisfied by this because when my scene is very complex,
>> > my osg based application is lagging and this leads to a poor quality
>> > of th video.
>> >
>> > I'm especially interested if there is a way to create an
>> > RecordCameraPathHandler to record a path, and then instead of saving
>> > it as a .path file compute the video in a batch mode. By batch mode I
>> > mean that the creation of the video doesn't need to be real time. In
>> > that way I could hopefully control the lag effects and eventually the
>> > resolution of the video.
>> >
>> > Sincerely,
>> >
>> > --
>> > Loïc Simon
>> > ___
>> > 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
>>
>
>
>
> --
> Loïc Simon
>



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

Re: [osg-users] High resolution screencast

[Simon Loic]

I tried it but I encountered few problems. I will send you the detailed
tomorrow. Still thanks for the tip.

On Tue, Jan 6, 2009 at 5:40 PM, Jeremy Moles wrote:

> Not trying to hijack this thread--and I can't really read it all for now
> because I'm still fighting off lots of complications from a recent oral
> surgery--but what you want is called "bugle." I used it to make all of
> the old osgWidget and osgPango videos and it works like a charm.
>
> What it does is LD_PRELOAD's glSwap() or whatever and replaces it with a
> version that shimmies off data to ffmpeg for encoding. Simple, clean,
> and easy for basic usage.
>
> On Thu, 2008-12-18 at 20:38 +0100, Simon Loic wrote:
> > Hi,
> >
> > I apology in advance if this thread have been heavily answered before
> > (if so just tell where I can find the solution). Still I would like to
> > know the different alternative (the good ones) to record a video of my
> > scene.
> > So far I was using an external tool for screenCast (called istanbul).
> > But I'm not satisfied by this because when my scene is very complex,
> > my osg based application is lagging and this leads to a poor quality
> > of th video.
> >
> > I'm especially interested if there is a way to create an
> > RecordCameraPathHandler to record a path, and then instead of saving
> > it as a .path file compute the video in a batch mode. By batch mode I
> > mean that the creation of the video doesn't need to be real time. In
> > that way I could hopefully control the lag effects and eventually the
> > resolution of the video.
> >
> > Sincerely,
> >
> > --
> > Loïc Simon
> > ___
> > 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
>



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

Re: [osg-users] High resolution screencast

[Simon Loic]

Thanks to all of you. I'll give a try to the screencapture example.

On Sun, Dec 21, 2008 at 12:27 PM, Robert Osfield
wrote:

> Hi Guys,
>
> I haven't really followed this thread as it had plenty of discussion
> already.  In my speed reading I have seen mention of the
> osgscreencapture example that has an option for opening a pbuffer for
> taking a snapshot.  This particular example is setup to demonstrate
> streaming imagery from the graphics card, rather than taking just a
> single frame, but the ideas are similar.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] High resolution screencast

[Simon Loic]

Thanks Jean-Sebastien,
Your reply is very helpful. I don't have the time to day to implement it but
I will try during the next week.
Of course I'm interested by your new ScreenCaptureHandler class. BTW do you
think that with this approach it's possible to have a capture resolution
different from the one of the screen?
I will give a look to ffmpeg too.




On Fri, Dec 19, 2008 at 4:40 PM, Jean-Sébastien Guay <
jean-sebastien.g...@cm-labs.com> wrote:

> Hello Simon,
>
>  Second, I tried some times ago to do an offscreen rendering but If you
>> know an easy way in osg to do it I'm interested (I think there are ways
>> based on osg::Camera::DrawCallBack).
>>
>
> There is now (since OSG 2.6) an osgViewer::ScreenCaptureHandler which you
> can use. Unfortunately it only responds to key presses right now, but you
> can subclass it like this to get it to capture programmatically:
>
>class OurScreenCaptureHandler :
>public osgViewer::ScreenCaptureHandler
>{
>public:
>OurScreenCaptureHandler(CaptureOperation* defaultOperation = 0)
>   : osgViewer::ScreenCaptureHandler(defaultOperation)
>{
>}
>
>/** Capture the given viewer's views on the next frame. */
>virtual void captureNextFrame(osgViewer::ViewerBase& viewer)
>{
>addCallbackToViewer(viewer);
>}
>};
>
> Then in your frame loop, you can just call
>
>screenCaptureHandler->captureNextFrame(viewer);
>
> (note: I'll be sending a new version of ScreenCaptureHandler which includes
> this method soon, I had to do it for our framework recently, so it will
> probably be included in OSG after that, no need to subclass)
>
>  Eventually, do you know some good (easy to handle) API for compressing
>> video?
>>
>
> Once you have images of each frame, you can just use ffmpeg to compress the
> sequence into a video. See the ffmpeg man page or web page for more
> information.
>
> Hope this helps,
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-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
>



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

Re: [osg-users] High resolution screencast

[Simon Loic]

Hi, thanks guys for your help,

Ümit:
I'm indeed using Ubuntu...
I don't see how using an external camera can help. In fact the lags are not
due to istanbul but to the complexity of the scene : even without
screencasting my graphic card is not able to render at a sufficient frame
rate.

Sukender:
Your proposal seems to fit what I wanna do. Though I need some more help
about some points.

First, a point you didn't referred to in your pseudo code : How will I move
around the scene? Are you thinking of traversing along an osg::AnimationPath
like I proposed? If so, do you have any Idea of how to do this?

Second, I tried some times ago to do an offscreen rendering but If you know
an easy way in osg to do it I'm interested (I think there are ways based on
osg::Camera::DrawCallBack).

Eventually, do you know some good (easy to handle) API for compressing
video?

Thanks a lot for your support.

On Thu, Dec 18, 2008 at 11:00 PM, Sukender  wrote:

> Hi Simon,
>
> I got a solution for you, which is not an out-of-the-box one and requires a
> little coding, but I already did a similar thing to capture the output of an
> OpenGL/SDL app and it worked properly:
>
> You may tweak the main loop and control yourself the simulation time of the
> scene graph. That way, you could render and capture a constant frame-rate
> video (25fps for example). The video rendering is then not realtime: if your
> PC is fast, the redering will last less than the video, but the video itslef
> would always have a constant frame rate. Here is my solution in pseudo-code:
> while( !viewer.done() ) {
>videoTime += 1/25.f;  // Advance 1/25th of second
>viewer.frame(videoTime);  // ... and tell the scene graph
>Capture the rendered image
>If you have an API for compressing video, send the captured image to it.
> Else save it to disk for manual encoding.
> }
>
> Hope it helps.
>
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
>
> Le Thu, 18 Dec 2008 20:38:12 +0100, Simon Loic  a
> écrit:
>
> > Hi,
> >
> > I apology in advance if this thread have been heavily answered before (if
> so
> > just tell where I can find the solution). Still I would like to know the
> > different alternative (the good ones) to record a video of my scene.
> > So far I was using an external tool for screenCast (called istanbul). But
> > I'm not satisfied by this because when my scene is very complex, my osg
> > based application is lagging and this leads to a poor quality of th
> video.
> >
> > I'm especially interested if there is a way to create an
> > RecordCameraPathHandler to record a path, and then instead of saving it
> as a
> > .path file compute the video in a batch mode. By batch mode I mean that
> the
> > creation of the video doesn't need to be real time. In that way I could
> > hopefully control the lag effects and eventually the resolution of the
> > video.
> >
> > Sincerely,
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

[osg-users] High resolution screencast

[Simon Loic]

Hi,

I apology in advance if this thread have been heavily answered before (if so
just tell where I can find the solution). Still I would like to know the
different alternative (the good ones) to record a video of my scene.
So far I was using an external tool for screenCast (called istanbul). But
I'm not satisfied by this because when my scene is very complex, my osg
based application is lagging and this leads to a poor quality of th video.

I'm especially interested if there is a way to create an
RecordCameraPathHandler to record a path, and then instead of saving it as a
.path file compute the video in a batch mode. By batch mode I mean that the
creation of the video doesn't need to be real time. In that way I could
hopefully control the lag effects and eventually the resolution of the
video.

Sincerely,

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

Re: [osg-users] Rendering bug?

[Simon Loic]

Hi,

sorry for the late feedback. I tried to use GL_REPLACE and it seems that the
problem is solved.
Thanks very much jp.



On Mon, Dec 8, 2008 at 12:42 PM, J.P. Delport <[EMAIL PROTECTED]> wrote:

> Hi Loïc,
>
> textures do not always exist completely on their own. I have been bitten by
> GL_MODULATE myself a few times where my textures were darker than I
> expected.
>
> Have a look at this:
> http://www.opengl.org/resources/faq/technical/texture.htm
>
> 21.030 Why doesn't lighting work when I turn on texture mapping?
>
> So you could try:
> 1) As Robert suggested, add a colorarray and make it all white.
> 2) If you don't need colorarray, add a default color for whole geom.
> 3) Investigate other texture modes, eg GL_DECAL or GL_REPLACE.
>
> jp
>
> Simon Loic wrote:
>
>> I apologize in advance if I'm saying something silly, but the geometries
>> concerned have a texture attached. Should they still have a colorarray
>> defined? What should be this colorArray then?
>>
>> Thanks a lot Robert.
>>
>> PS: Just so you know, my first name is Loïc.
>>
>> On Mon, Dec 8, 2008 at 11:33 AM, Robert Osfield <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>Hi Simon,
>>
>>Not all your geometries contain colour arrays, so they are randomly
>>picking up their colour from what ever geometry that had colour arrays
>>was last applied.   Add the missing colour arrays and everything will
>>work fine.
>>
>>Robert.
>>
>>On Mon, Dec 8, 2008 at 10:13 AM, Simon Loic <[EMAIL PROTECTED]
>><mailto:[EMAIL PROTECTED]>> wrote:
>> > Hi,
>> >
>> > I'm working with osg to design an application for realistic
>>representation
>> > of buildings.
>> > I've been through some weird behavior at rendering and I don't
>>know how to
>> > fix it.
>> > My scene (which represent a building) is composed of several
>>subparts. The
>> > problem is that identical subparts are not rendered the same.
>>Apparently
>> > when partially rendered (because they get partially out of the
>>window)
>> > subparts seem to get darker. Take care I'm not sure of the hint
>>I'm giving
>> > here.
>> > I've attached to this mail one video showing the problem and the
>>osg file
>> > that I render.
>> > Could you please try to replicate the behavior shown in the
>>video, using the
>> > provided file.
>> > If you have any idea of what could lead to this, I will
>>aprreciate a lot.
>> > Thank you very much.
>> > regards,
>> >
>> >
>> >
>> > --
>> > Loïc Simon
>> >
>> > ___
>> > osg-users mailing list
>> > osg-users@lists.openscenegraph.org
>><mailto:osg-users@lists.openscenegraph.org>
>> >
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> >
>>___
>>osg-users mailing list
>>osg-users@lists.openscenegraph.org
>><mailto:osg-users@lists.openscenegraph.org>
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>>
>>
>> --
>> Loïc Simon
>>
>>
>> 
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
> Computers for their support.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] Rendering bug?

[Simon Loic]

I apologize in advance if I'm saying something silly, but the geometries
concerned have a texture attached. Should they still have a colorarray
defined? What should be this colorArray then?

Thanks a lot Robert.

PS: Just so you know, my first name is Loïc.

On Mon, Dec 8, 2008 at 11:33 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Hi Simon,
>
> Not all your geometries contain colour arrays, so they are randomly
> picking up their colour from what ever geometry that had colour arrays
> was last applied.   Add the missing colour arrays and everything will
> work fine.
>
> Robert.
>
> On Mon, Dec 8, 2008 at 10:13 AM, Simon Loic <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I'm working with osg to design an application for realistic
> representation
> > of buildings.
> > I've been through some weird behavior at rendering and I don't know how
> to
> > fix it.
> > My scene (which represent a building) is composed of several subparts.
> The
> > problem is that identical subparts are not rendered the same. Apparently
> > when partially rendered (because they get partially out of the window)
> > subparts seem to get darker. Take care I'm not sure of the hint I'm
> giving
> > here.
> > I've attached to this mail one video showing the problem and the osg file
> > that I render.
> > Could you please try to replicate the behavior shown in the video, using
> the
> > provided file.
> > If you have any idea of what could lead to this, I will aprreciate a lot.
> > Thank you very much.
> > regards,
> >
> >
> >
> > --
> > Loïc Simon
> >
> > ___
> > 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
>



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

Re: [osg-users] Texture mapping and scaling

[Simon Loic]

Thank you so much Robert that was exactly what I needed!!
I'm a little bit ashamed of my poor knowledge of OpenGL.
Regards

On Tue, Nov 18, 2008 at 4:29 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> Hi Simon,
>
> The normal way to manage this situation is to simple update the
> geometry and tex coords as required.  Now if you are wanting to
> stricty use transforms to scale your geometry then you'll need to
> something similar for your tex coords and luckily that is an OpenGL
> feature for doing scaling - the texture matrix.  To access this just
> use the osg::TexMat state attribute, use a similar scale as you are
> using for your transform.  You can attach a StateSet with a TexMat to
> the same Transform that you are using for scaling.  The one caveat is
> that it'll apply to whole subgraph you are decorate the TexMat with so
> you might need to think about localising multiple TexMat for different
> surfaces.
>
> Robert.
>
> On Tue, Nov 18, 2008 at 3:13 PM, Simon Loic <[EMAIL PROTECTED]> wrote:
> > Hi all,
> > I have a particular problem that I got no idea how to solve it. Here it
> is:
> >
> > When I am scaling a drawable ( using a transform node ) the texture
> attached
> > to it is stretched. Obviously this behaviour is totally convenient for
> many
> > applications. Though, I am working on architecture and this behaviour is
> > really troublesome. You can imagine for example that the Drawable
> represent
> > a rectangle piece of wall and the texture contains a brick pattern of
> > dimension 1 meter over 1 meter.  Then if I scale the Drawable to have 10m
>  x
> > 15 m the Texture will stretched to fit this size.
> >
> > To my mind the only way to achieve what I want is to compute new texture
> > coordinates from the ones of the Drawable and 2 scaling parameters (let's
> > say sX and sY).
> > Even if this is not theoretically difficult I don't have a sufficient
> > knowledge of OSG to tell if it's already possible without embedding osg
> with
> > a new feature, or otherwise how to optimally extend osg to support this
> kind
> > of behaviour.
> >
> > If anyone understand what I'm trying to do, I will be so grateful for
> your
> > help
> > regards.
> >
> > --
> > Loïc Simon
> >
> > ___
> > 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
>



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

[osg-users] Texture mapping and scaling

[Simon Loic]

Hi all,
I have a particular problem that I got no idea how to solve it. Here it is:

When I am scaling a drawable ( using a transform node ) the texture attached
to it is stretched. Obviously this behaviour is totally convenient for many
applications. Though, I am working on architecture and this behaviour is
really troublesome. You can imagine for example that the Drawable represent
a rectangle piece of wall and the texture contains a brick pattern of
dimension 1 meter over 1 meter.  Then if I scale the Drawable to have 10m  x
15 m the Texture will stretched to fit this size.

To my mind the only way to achieve what I want is to compute new texture
coordinates from the ones of the Drawable and 2 scaling parameters (let's
say sX and sY).
Even if this is not theoretically difficult I don't have a sufficient
knowledge of OSG to tell if it's already possible without embedding osg with
a new feature, or otherwise how to optimally extend osg to support this kind
of behaviour.

If anyone understand what I'm trying to do, I will be so grateful for your
help
regards.

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