Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[J.P. Delport]

Hi Brian,

Brian R Hill wrote:

So, if you wanted to add things to be done before image copy, it
should be part of the camera's subgraph.


I guess I could do this. Create a custom drawable that call the 3rd party
function. The difficulty will be guaranteeing it's the absolutely last
thing drawn. The postdraw makes this easy.


There is a new SortMode in RenderBin called TRAVERSAL_ORDER that might 
be able to help with this.


jp


--
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

Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released

[Peter Clemenko III]

Hi,

recently got a chance to test it again, same thing



[Image: http://i16.photobucket.com/albums/b15/Th3Flyboy/screenies/gv.jpg ]

[Image: http://i16.photobucket.com/albums/b15/Th3Flyboy/screenies/sv.jpg ]

error message 


> CMake Warning (dev) at D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 (SET):
>   Syntax error in cmake code at
> 
> D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1
> 
>   when parsing string
> 
> C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe
> 
>   Invalid escape sequence \P
> 
>   Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
>   "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>   command to set the policy and suppress this warning.
> Call Stack (most recent call first):
>   
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> CMake Warning (dev) at D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 (SET):
>   Syntax error in cmake code at
> 
> D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1
> 
>   when parsing string
> 
> C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe
> 
>   Invalid escape sequence \P
> 
>   Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
>   "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>   command to set the policy and suppress this warning.
> Call Stack (most recent call first):
>   
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> Check for working C compiler: C:\Program Files\Microsoft Visual Studio 
> 9.0\VC\bin\cl.exe
> CMake Warning (dev) at D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 (SET):
>   Syntax error in cmake code at
> 
> D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1
> 
>   when parsing string
> 
> C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe
> 
>   Invalid escape sequence \P
> 
>   Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
>   "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>   command to set the policy and suppress this warning.
> Call Stack (most recent call first):
>   CMakeLists.txt:2 (PROJECT)
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> Check for working C compiler: C:\Program Files\Microsoft Visual Studio 
> 9.0\VC\bin\cl.exe -- works
> Detecting C compiler ABI info
> CMake Warning (dev) at D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1 (SET):
>   Syntax error in cmake code at
> 
> D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCCompiler.cmake:1
> 
>   when parsing string
> 
> C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe
> 
>   Invalid escape sequence \P
> 
>   Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
>   "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>   command to set the policy and suppress this warning.
> Call Stack (most recent call first):
>   CMakeLists.txt:2 (PROJECT)
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> Detecting C compiler ABI info - done
> Check for working CXX compiler: C:\Program Files\Microsoft Visual Studio 
> 9.0\VC\bin\cl.exe
> CMake Warning (dev) at D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 (SET):
>   Syntax error in cmake code at
> 
> D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1
> 
>   when parsing string
> 
> C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe
> 
>   Invalid escape sequence \P
> 
>   Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
>   "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>   command to set the policy and suppress this warning.
> Call Stack (most recent call first):
>   CMakeLists.txt:2 (PROJECT)
> This warning is for project developers.  Use -Wno-dev to suppress it.
> 
> Check for working CXX compiler: C:\Program Files\Microsoft Visual Studio 
> 9.0\VC\bin\cl.exe -- works
> Detecting CXX compiler ABI info
> CMake Warning (dev) at D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1 (SET):
>   Syntax error in cmake code at
> 
> D:/csp/devpack/Devpack 32 
> flybuild/osgOcean/build/CMakeFiles/CMakeCXXCompiler.cmake:1
> 
>   when parsing string
> 
> C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.exe
> 
>   Invalid escape sequence \P
> 
>   Policy CMP0010 is not set: Bad variable reference syntax is an error.  Run
>   "cmake --help-policy CMP0010" for policy details.  Use the cmake_policy
>   command to set the policy and suppress this warning.
> Call Stack (most recent

Re: [osg-users] Billboard problem

[Markus Husseini]

Ok thx now it works

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





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

Re: [osg-users] Visual Studio 2005

[Cory Riddell]

Hi Michael,

Have you generated the solution file with cmake yet?

Cory

Michael W. Hall wrote:
> Since I am having issues with my linux box, I am tinkering with OSG in
> Visual Studio 2005.  I am not having much luck.  I was wondering if
> anyone can point me to some good example code for VS 2005.
>
> I am wanting to do C++/CLR.
>
> Thanks for any help.
>
> ___
> 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] OSGDem Question

[Chris 'Xenon' Hanson]

spike inin wrote:
> Hi,
> Is there a way I can acquaint OSGDem not to do that or at atomic accomplish 
> that atramentous accomplishments transparent, so I can seamlessly bury the 
> map I created over a lower resolution map of the world.

  That didn't make much sense.

  OSGDem already supports laying small high-res DEM insets on top of 
lower-resolution data
(potentially of the whole world).

> Cheers,

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Importance Of Node Path List In Database Pager

[Kawicki, Ryan H]

Robert,

I was just curious to see if anything was committed to the 2.9.x / 2.10 
baselines for this.  I know that you stated that you already had code in place 
to fix this issue.  Thanks.

Ryan H. Kawicki
The Boeing Company
Training Systems & Services
Software Engineer

-Original Message-
From: Kawicki, Ryan H 
Sent: Friday, July 24, 2009 10:44 AM
To: OpenSceneGraph Users
Subject: [osg-users] FW: Importance Of Node Path List In Database Pager


 
> Have you implemented a fix yet? If not I'll try to get to it while I'm still 
> around this week/early next week.

Unfortunately, we have not come up with a fix.  If you like, I could come up 
with a solution and submit it, but I would hate to duplicate work if you 
already have it on disk somewhere.  I will be out most of next week and would 
not be able to get to it until sometime the following week.

Thanks for the continue support.

Ryan H. Kawicki
The Boeing Company
Training Systems & Services
Software Engineer

-Original Message-
From: Robert Osfield [mailto:robert.osfi...@gmail.com]
Sent: Friday, July 24, 2009 9:20 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Importance Of Node Path List In Database Pager

Hi Ryan,

On Fri, Jul 24, 2009 at 3:01 PM, Kawicki, Ryan H 
wrote:
> Would it be possible to store this information as a DatabaseRequest attribute?

Curious, I thought I had already made such a change to DatabasePager - to move 
the NodePath acquisition  to the DatabaseRequest set up, but now reviewing it 
this code isn't in svn/trunk.  Weird.  Perhaps I thought about implementing it 
and then got distracted or perhaps I did the experiment but not checked it 
in.

Such a change would be appropriate - adding a RedNodePath to DatabaseRequest 
and set it inside the DatabasePager::requestNodeFile().  Unfortunately such a 
change would break the ABI for 2.8.x so would have to be merged with just the 
svn/trunk and the 2.9.x/2.10 series.

>The node path should be computed during the cull traversal.  The problem here 
>is that there is the possibility for a parent iterator to become invalidated 
>when this operation traverses up the scene graph.
>
> Sorry about the confusion on the line number.  I am referencing OSG 2.8.1.

Thanks, I now understand the issue at hand.  One I have previous thought about, 
but alas wrapped up this work...

Have you implemented a fix yet? If not I'll try to get to it while I'm still 
around this week/early next week.

Robert.
___
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] Billboard problem

[Tony Horrobin]

Hi,

Have your textures got an alpha channel?  Try setting the alpha of the black 
region to zero and set an alpha function of GEQUAL and a reference value of 0.05

So, declare a member variable:

Code:

osg::ref_ptr< osg::AlphaFunc > m_refAlpha;



Then:

Code:

m_refAlpha = new osg::AlphaFunc();
m_refAlpha->setFunction( osg::AlphaFunc::GEQUAL, 0.05f );
m_refStateSet->setAttributeAndModes( m_refAlpha.get(), osg::StateAttribute::ON 
);



The billboard tutorial shows this.

Cheers,

Tony
[/code]

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





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

Re: [osg-users] OSG and shaders

[Paul Speed]

And it deserves saying, if you can get your hands on an OpenGL Orange 
Book you'll be that many more steps ahead.  I thought it was really good 
at explaining things in depth while also being easily navigated to drill 
in on target areas.


I had complex shaders up and running in a few days with that book... I 
have had some embedded-style coding experience before, though.


-Paul

Maxime BOUCHER wrote:

Well,

 I'm doing an internship too.

At the beginning I didn't know osg at all, neither shaders.
There are still an extraordinary amount of things I ignore about OSG (my 
advice: when you try to do or understand something, take a look at how it's 
done in OpenGL).
Shaders aren't as hard to use as OSG, I discovered about one month ago and I 
can now write some modests but nice effects.

The essential is to read code and tutorials.
Don't try to go fast, it's the best way to misunderstand what you manipulate 
and to write bad code, failing your internship. You have 6 months, you can 
waste it OR spend 2 months to understand osg and shaders and then writting good 
code, masterizing your internship.

Thus, first read a few osg tutorials (to understand how textures are mapped for 
example, it seems you don't), I think the 4 or 5 firsts should be enough.
After, try to understand what is a shader (I guess you don't really).
Then try to understand the shader tutorials from typhoonlabs, or this 
(http://www.siteduzero.com/tutoriel-3-8879-communiquer-avec-l-application-attributs-et-uniforms.html?bcsi-ac-20A76BC15DBD50F6=194870AE0303lbVE9ryZWUuZzrBgMzY7DS6IPWi9BwMAAMDCRwEQDgAAINVbBwA=),
 it's in french.
I advice to look at osgshader example ONLY to understand (or copy the code) how 
to load and activate a shader, it's 5 lines.

Don't take me for moralistic, I did these errors.

Good luck and take your time, it's the best way to success.

Cheers,
Maxime

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





___
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] RenderStage::draw order of copyTexture and PostDrawCallback

[Thrall, Bryan]

Thrall, Bryan wrote on Wednesday, August 05, 2009 3:22 PM:
> Brian R Hill wrote on Wednesday, August 05, 2009 3:05 PM:
>>> I think this is the common case and I always understood postdraw to
>>> mean that the camera is done with rendering/drawing.
>> 
>> I've always thought of it as the "last chance to draw something",
>> essentially a hook into the drawing phase to integrate things that don't
>> fit well in the scenegraph architecture.
>> 
>>> So, if you wanted to add things to be done before image copy, it
>>> should be part of the camera's subgraph.
>> 
>> I guess I could do this. Create a custom drawable that call the 3rd party
>> function. The difficulty will be guaranteeing it's the absolutely last
>> thing drawn. The postdraw makes this easy.
> 
> What about inserting a POST_RENDER Camera under the camera with the
> DrawCallback attached to it? 

Er... to clarify: insert a Camera under your main camera and set it to 
POST_RENDER. Then attach your DrawCallback to the POST_RENDER camera. The 
DrawCallback should happen before the main camera's FBO copy to Image.

>> -osg-users-boun...@lists.openscenegraph.org wrote: -
>> 
>> To: OpenSceneGraph Users 
>> From: "J.P. Delport" 
>> Sent by: osg-users-boun...@lists.openscenegraph.org
>> Date: 08/05/2009 03:53PM
>> Subject: Re: [osg-users]  RenderStage::draw order ofcopyTexture and
>> PostDrawCallback 
>> 
>> Hi,
>> 
>> Brian R Hill wrote:
>>> Hi JP,
>>> 
>>> I was trying to determine if the current order (copy image, then call
>>> postdraw) was deliberate for specific reasons, or if it just got coded that
>>> way.
>> 
>> I think it was deliberate; however, I didn't write the code.
>> 
>>> 
>>> I understand where you would want the copied image to be available in the
>>> postdraw,
>> 
>> I think this is the common case and I always understood postdraw to mean
>> that the camera is done with rendering/drawing. So, if you wanted to add
>> things to be done before image copy, it should be part of the camera's
>> subgraph. 
>> 
>>> but I also understand where you would want the postdraw to apply
>>> to the image before the copy.
>>> 
>>> It just depends on what the intended purpose of the postdraw is.
>>> 
>>> Personally I feel the postdraw should occur before the copy and that the
>>> copied image should be accessed on the cpu side during the update phase.
>> 
>> Would it not be a frame late then? I understand your need for more
>> flexibilty ito processing order and copying. I would suggest you have a
>> look at osgPPU where you have more control over these things.
>> 
>> jp
>> 
>>> 
>>> Brian
>>> 
>>> 
>>> 
>>> This is a PRIVATE message. If you are not the intended recipient, please
>>> delete without copying and kindly advise us by e-mail of the mistake in
>>> delivery. NOTE: Regardless of content, this e-mail shall not operate to bind
>>> CSC to any order or other contract unless pursuant to explicit written
>>> agreement or government initiative expressly permitting the use of e-mail
>>> for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote:
>>> - 
>>> 
>>> To: OpenSceneGraph Users 
>>> From: "J.P. Delport" 
>>> Sent by: osg-users-boun...@lists.openscenegraph.org
>>> Date: 08/05/2009 03:27PM
>>> Subject: Re: [osg-users] RenderStage::draw order      of    copyTexture and
>>> PostDrawCallback 
>>> 
>>> Hi,
>>> 
>>> Brian R Hill wrote:
 Hi JP,
 
 I'm using a 3rd party library to do filtering on the rendered image. They
 do all their magic using opengl in a function call from the
 postdrawcallback. 
 
 Here's what it currently does:
 
 draw -> FBO -> copy to cpu -> postdraw
 
 The postdraw operates on the FBO after it's been copied to the cpu and I
 never see it. 
 
 Here's what I want to do:
 
 draw -> FBO -> postdraw -> copy to cpu
 
 I want to access the image with the filtering effects included.
 
 Does this make it clearer?
>>> 
>>> Yes.
>>> 
 My fallback is to not attach an image to the FBO and do the copying myself
 in the postdrawcallback after the filtering.
>>> 
>>> This sounds OK to me, do you have problems with it? AFAIK you cannot
>>> change the order for a single FBO camera. The only other option I can
>>> think of (if you don't want to manually copy) is to create a second FBO
>>> camera solely for copying the result of the filtering (input texture to
>>> the second camera) to an osg::Image.
>>> 
>>> Then you have
>>> 
>>> draw -> FBO1 -> postdraw -> FBO2 -> to CPU
>>> 
>>> jp
>>> 
>>> 
 Brian
 
 
 This is a PRIVATE message. If you are not the intended recipient, please
 delete without copying and kindly advise us by e-mail of the mistake in
 delivery. NOTE: Regardless of content, this e-mail shall not operate to
 bind CSC to any order or other contract unless pursuant to explicit written
 agreement or government initiative expressly permitting the use of e-mail
 for such purpose. * -

Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[Thrall, Bryan]

Brian R Hill wrote on Wednesday, August 05, 2009 3:05 PM:
>> I think this is the common case and I always understood postdraw to
>> mean that the camera is done with rendering/drawing.
> 
> I've always thought of it as the "last chance to draw something",
> essentially a hook into the drawing phase to integrate things that don't
> fit well in the scenegraph architecture.
> 
>> So, if you wanted to add things to be done before image copy, it
>> should be part of the camera's subgraph.
> 
> I guess I could do this. Create a custom drawable that call the 3rd party
> function. The difficulty will be guaranteeing it's the absolutely last
> thing drawn. The postdraw makes this easy.

What about inserting a POST_RENDER Camera under the camera with the 
DrawCallback attached to it?

> -osg-users-boun...@lists.openscenegraph.org wrote: -
> 
> To: OpenSceneGraph Users 
> From: "J.P. Delport" 
> Sent by: osg-users-boun...@lists.openscenegraph.org
> Date: 08/05/2009 03:53PM
> Subject: Re: [osg-users]  RenderStage::draw order ofcopyTexture and
> PostDrawCallback
> 
> Hi,
> 
> Brian R Hill wrote:
>> Hi JP,
>> 
>> I was trying to determine if the current order (copy image, then call
>> postdraw) was deliberate for specific reasons, or if it just got coded that
>> way.
> 
> I think it was deliberate; however, I didn't write the code.
> 
>> 
>> I understand where you would want the copied image to be available in the
>> postdraw,
> 
> I think this is the common case and I always understood postdraw to mean
> that the camera is done with rendering/drawing. So, if you wanted to add
> things to be done before image copy, it should be part of the camera's
> subgraph.
> 
>> but I also understand where you would want the postdraw to apply
>> to the image before the copy.
>> 
>> It just depends on what the intended purpose of the postdraw is.
>> 
>> Personally I feel the postdraw should occur before the copy and that the
>> copied image should be accessed on the cpu side during the update phase.
> 
> Would it not be a frame late then? I understand your need for more
> flexibilty ito processing order and copying. I would suggest you have a
> look at osgPPU where you have more control over these things.
> 
> jp
> 
>> 
>> Brian
>> 
>> 
>> 
>> This is a PRIVATE message. If you are not the intended recipient, please
>> delete without copying and kindly advise us by e-mail of the mistake in
>> delivery. NOTE: Regardless of content, this e-mail shall not operate to bind
>> CSC to any order or other contract unless pursuant to explicit written
>> agreement or government initiative expressly permitting the use of e-mail
>> for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote:
>> - 
>> 
>> To: OpenSceneGraph Users 
>> From: "J.P. Delport" 
>> Sent by: osg-users-boun...@lists.openscenegraph.org
>> Date: 08/05/2009 03:27PM
>> Subject: Re: [osg-users] RenderStage::draw order      of    copyTexture and
>> PostDrawCallback 
>> 
>> Hi,
>> 
>> Brian R Hill wrote:
>>> Hi JP,
>>> 
>>> I'm using a 3rd party library to do filtering on the rendered image. They
>>> do all their magic using opengl in a function call from the
>>> postdrawcallback. 
>>> 
>>> Here's what it currently does:
>>> 
>>> draw -> FBO -> copy to cpu -> postdraw
>>> 
>>> The postdraw operates on the FBO after it's been copied to the cpu and I
>>> never see it. 
>>> 
>>> Here's what I want to do:
>>> 
>>> draw -> FBO -> postdraw -> copy to cpu
>>> 
>>> I want to access the image with the filtering effects included.
>>> 
>>> Does this make it clearer?
>> 
>> Yes.
>> 
>>> My fallback is to not attach an image to the FBO and do the copying myself
>>> in the postdrawcallback after the filtering.
>> 
>> This sounds OK to me, do you have problems with it? AFAIK you cannot
>> change the order for a single FBO camera. The only other option I can
>> think of (if you don't want to manually copy) is to create a second FBO
>> camera solely for copying the result of the filtering (input texture to
>> the second camera) to an osg::Image.
>> 
>> Then you have
>> 
>> draw -> FBO1 -> postdraw -> FBO2 -> to CPU
>> 
>> jp
>> 
>> 
>>> Brian
>>> 
>>> 
>>> This is a PRIVATE message. If you are not the intended recipient, please
>>> delete without copying and kindly advise us by e-mail of the mistake in
>>> delivery. NOTE: Regardless of content, this e-mail shall not operate to
>>> bind CSC to any order or other contract unless pursuant to explicit written
>>> agreement or government initiative expressly permitting the use of e-mail
>>> for such purpose. * -osg-users-boun...@lists.openscenegraph.org wrote:
>>> - 
>>> 
>>> To: OpenSceneGraph Users 
>>> From: "J.P. Delport" 
>>> Sent by: osg-users-boun...@lists.openscenegraph.org
>>> Date: 08/05/2009 02:17PM
>>> Subject: Re: [osg-users] RenderStage::draw order of copyTexture   and
>>> PostDrawCallback 
>>> 
>>> Hi Brian,
>>> 
>>> Brian R Hill wrote:
 Sorry about the multiple posts/wrong subjects. Another 

Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[Brian R Hill]

Hi JP,

> I think this is the common case and I always understood postdraw to
> mean that the camera is done with rendering/drawing.

I've always thought of it as the "last chance to draw something",
essentially a hook into the drawing phase to integrate things that don't
fit well in the scenegraph architecture.

> So, if you wanted to add things to be done before image copy, it
> should be part of the camera's subgraph.

I guess I could do this. Create a custom drawable that call the 3rd party
function. The difficulty will be guaranteeing it's the absolutely last
thing drawn. The postdraw makes this easy.

Brian


This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: "J.P. Delport" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/05/2009 03:53PM
Subject: Re: [osg-users]  RenderStage::draw order ofcopyTexture and
PostDrawCallback

Hi,

Brian R Hill wrote:
> Hi JP,
>
> I was trying to determine if the current order (copy image, then call
> postdraw) was deliberate for specific reasons, or if it just got coded
that
> way.

I think it was deliberate; however, I didn't write the code.

>
> I understand where you would want the copied image to be available in the
> postdraw,

I think this is the common case and I always understood postdraw to mean
that the camera is done with rendering/drawing. So, if you wanted to add
things to be done before image copy, it should be part of the camera's
subgraph.

> but I also understand where you would want the postdraw to apply
> to the image before the copy.
>
> It just depends on what the intended purpose of the postdraw is.
>
> Personally I feel the postdraw should occur before the copy and that the
> copied image should be accessed on the cpu side during the update phase.

Would it not be a frame late then? I understand your need for more
flexibilty ito processing order and copying. I would suggest you have a
look at osgPPU where you have more control over these things.

jp

>
> Brian
>
>
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
> any order or other contract unless pursuant to explicit written agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose. •
> -osg-users-boun...@lists.openscenegraph.org wrote: -
>
> To: OpenSceneGraph Users 
> From: "J.P. Delport" 
> Sent by: osg-users-boun...@lists.openscenegraph.org
> Date: 08/05/2009 03:27PM
> Subject: Re: [osg-users] RenderStage::draw order      of    copyTexture
and
> PostDrawCallback
>
> Hi,
>
> Brian R Hill wrote:
>> Hi JP,
>>
>> I'm using a 3rd party library to do filtering on the rendered image.
They
>> do all their magic using opengl in a function call from the
>> postdrawcallback.
>>
>> Here's what it currently does:
>>
>> draw -> FBO -> copy to cpu -> postdraw
>>
>> The postdraw operates on the FBO after it's been copied to the cpu and I
>> never see it.
>>
>> Here's what I want to do:
>>
>> draw -> FBO -> postdraw -> copy to cpu
>>
>> I want to access the image with the filtering effects included.
>>
>> Does this make it clearer?
>
> Yes.
>
>> My fallback is to not attach an image to the FBO and do the copying
> myself
>> in the postdrawcallback after the filtering.
>
> This sounds OK to me, do you have problems with it? AFAIK you cannot
> change the order for a single FBO camera. The only other option I can
> think of (if you don't want to manually copy) is to create a second FBO
> camera solely for copying the result of the filtering (input texture to
> the second camera) to an osg::Image.
>
> Then you have
>
> draw -> FBO1 -> postdraw -> FBO2 -> to CPU
>
> jp
>
>
>> Brian
>>
>>
>> This is a PRIVATE message. If you are not the intended recipient, please
>> delete without copying and kindly advise us by e-mail of the mistake in
>> delivery.
>> NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to
>> any order or other contract unless pursuant to explicit written
agreement
>> or government initiative expressly permitting the use of e-mail for such
>> purpose. •
>> -osg-users-boun...@lists.openscenegraph.org wrote: -
>>
>> To: OpenSceneGraph Users 
>> From: "J.P. Delport" 
>> Sent by: osg-users-boun...@lists.openscenegraph.org
>> Date: 08/05/2009 02:17PM
>> Subject: Re: [osg-users] RenderStage::draw order of copyTexture   and
>> PostDrawCallback
>>
>> Hi Brian,
>>
>> Brian R Hill wrote:
>>> Sorry about the m

Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[J.P. Delport]

Hi,

Brian R Hill wrote:

Hi JP,

I was trying to determine if the current order (copy image, then call
postdraw) was deliberate for specific reasons, or if it just got coded that
way.


I think it was deliberate; however, I didn't write the code.



I understand where you would want the copied image to be available in the
postdraw, 


I think this is the common case and I always understood postdraw to mean 
that the camera is done with rendering/drawing. So, if you wanted to add 
things to be done before image copy, it should be part of the camera's 
subgraph.



but I also understand where you would want the postdraw to apply
to the image before the copy.

It just depends on what the intended purpose of the postdraw is.

Personally I feel the postdraw should occur before the copy and that the
copied image should be accessed on the cpu side during the update phase.


Would it not be a frame late then? I understand your need for more 
flexibilty ito processing order and copying. I would suggest you have a 
look at osgPPU where you have more control over these things.


jp



Brian



This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: "J.P. Delport" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/05/2009 03:27PM
Subject: Re: [osg-users] RenderStage::draw order  ofcopyTexture and
PostDrawCallback

Hi,

Brian R Hill wrote:

Hi JP,

I'm using a 3rd party library to do filtering on the rendered image. They
do all their magic using opengl in a function call from the
postdrawcallback.

Here's what it currently does:

draw -> FBO -> copy to cpu -> postdraw

The postdraw operates on the FBO after it's been copied to the cpu and I
never see it.

Here's what I want to do:

draw -> FBO -> postdraw -> copy to cpu

I want to access the image with the filtering effects included.

Does this make it clearer?


Yes.


My fallback is to not attach an image to the FBO and do the copying

myself

in the postdrawcallback after the filtering.


This sounds OK to me, do you have problems with it? AFAIK you cannot
change the order for a single FBO camera. The only other option I can
think of (if you don't want to manually copy) is to create a second FBO
camera solely for copying the result of the filtering (input texture to
the second camera) to an osg::Image.

Then you have

draw -> FBO1 -> postdraw -> FBO2 -> to CPU

jp



Brian


This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: "J.P. Delport" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/05/2009 02:17PM
Subject: Re: [osg-users] RenderStage::draw order of copyTexture   and
PostDrawCallback

Hi Brian,

Brian R Hill wrote:

Sorry about the multiple posts/wrong subjects. Another copy/paste

artifact.

Folks,

I'm doing offscreen rendering using fbos with attached images. I'm also
using the postdrawcallback to do additional processing. Currently the
image/texture copy occurs before the postdrawcallback resulting in the
image/texture not having the postdraw effects.

Is there a reason why the copy isn't after the postdrawcallback?

Copy to where?

In the postdrawcallback you have the result of the rendering to FBO
copied back to the CPU (osg::Image) if an image was attached to your FBO
camera. You can modify the data in the callback and then call dirty on
the image and the texture would be updated on GPU. If you then use this
texture you should see changes. The osgprerender example does exactly
this. I'm not sure if you are expecting anything else? If so, please
provide more details on what you want to do.

cheers
jp


Thanks,

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC

to

any order or other contract unless pursuant to explicit written

agreement

or government initiative expressly permitting the use of e-mail for such
purpose. •
___
osg-users mailing list
osg-users@lists.openscenegraph.org


http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

--

Re: [osg-users] [vpb] OSGDem Question

[spike inin]

Hi,

Is there a way I can acquaint OSGDem not to do that or at atomic accomplish 
that atramentous accomplishments transparent, so I can seamlessly bury the map 
I created over a lower resolution map of the world.

Thank you!

Cheers,
spike

_
Call center software (http://www.inin.com)

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





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

Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[Brian R Hill]

Hi JP,

I was trying to determine if the current order (copy image, then call
postdraw) was deliberate for specific reasons, or if it just got coded that
way.

I understand where you would want the copied image to be available in the
postdraw, but I also understand where you would want the postdraw to apply
to the image before the copy.

It just depends on what the intended purpose of the postdraw is.

Personally I feel the postdraw should occur before the copy and that the
copied image should be accessed on the cpu side during the update phase.

Brian



This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: "J.P. Delport" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/05/2009 03:27PM
Subject: Re: [osg-users] RenderStage::draw order  ofcopyTexture and
PostDrawCallback

Hi,

Brian R Hill wrote:
> Hi JP,
>
> I'm using a 3rd party library to do filtering on the rendered image. They
> do all their magic using opengl in a function call from the
> postdrawcallback.
>
> Here's what it currently does:
>
> draw -> FBO -> copy to cpu -> postdraw
>
> The postdraw operates on the FBO after it's been copied to the cpu and I
> never see it.
>
> Here's what I want to do:
>
> draw -> FBO -> postdraw -> copy to cpu
>
> I want to access the image with the filtering effects included.
>
> Does this make it clearer?

Yes.

>
> My fallback is to not attach an image to the FBO and do the copying
myself
> in the postdrawcallback after the filtering.

This sounds OK to me, do you have problems with it? AFAIK you cannot
change the order for a single FBO camera. The only other option I can
think of (if you don't want to manually copy) is to create a second FBO
camera solely for copying the result of the filtering (input texture to
the second camera) to an osg::Image.

Then you have

draw -> FBO1 -> postdraw -> FBO2 -> to CPU

jp


>
> Brian
>
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
> any order or other contract unless pursuant to explicit written agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose. •
> -osg-users-boun...@lists.openscenegraph.org wrote: -
>
> To: OpenSceneGraph Users 
> From: "J.P. Delport" 
> Sent by: osg-users-boun...@lists.openscenegraph.org
> Date: 08/05/2009 02:17PM
> Subject: Re: [osg-users] RenderStage::draw order of copyTexture   and
> PostDrawCallback
>
> Hi Brian,
>
> Brian R Hill wrote:
>> Sorry about the multiple posts/wrong subjects. Another copy/paste
> artifact.
>> Folks,
>>
>> I'm doing offscreen rendering using fbos with attached images. I'm also
>> using the postdrawcallback to do additional processing. Currently the
>> image/texture copy occurs before the postdrawcallback resulting in the
>> image/texture not having the postdraw effects.
>>
>> Is there a reason why the copy isn't after the postdrawcallback?
>
> Copy to where?
>
> In the postdrawcallback you have the result of the rendering to FBO
> copied back to the CPU (osg::Image) if an image was attached to your FBO
> camera. You can modify the data in the callback and then call dirty on
> the image and the texture would be updated on GPU. If you then use this
> texture you should see changes. The osgprerender example does exactly
> this. I'm not sure if you are expecting anything else? If so, please
> provide more details on what you want to do.
>
> cheers
> jp
>
>> Thanks,
>>
>> Brian
>>
>> This is a PRIVATE message. If you are not the intended recipient, please
>> delete without copying and kindly advise us by e-mail of the mistake in
>> delivery.
>> NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to
>> any order or other contract unless pursuant to explicit written
agreement
>> or government initiative expressly permitting the use of e-mail for such
>> purpose. •
>> ___
>> 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

Re: [osg-users] glMultiTexCoord4f , OSG with OGL code

[Pau Moreno]

Hi,

Ok, I've decided to follow your idea and do it with the osg shaders but I'm 
getting the next error


Code:
FRAGMENT glCompileShader "" FAILED
FRAGMENT Shader "" infolog:
(0) : error C: syntax error, unexpected $end at token ""
(0) : error C0501: type name expected at token ""

VERTEX glCompileShader "" FAILED
VERTEX Shader "" infolog:
(0) : error C: syntax error, unexpected $end at token ""
(0) : error C0501: type name expected at token ""

GEOMETRY glCompileShader "" FAILED
GEOMETRY Shader "" infolog:
(0) : error C: syntax error, unexpected $end at token ""
(0) : error C0501: type name expected at token ""

glLinkProgram "" FAILED
Program "" infolog:
Vertex info
---
(0) : error C: syntax error, unexpected $end at token ""
(0) : error C0501: type name expected at token ""

Geometry info
-
(0) : error C: syntax error, unexpected $end at token ""
(0) : error C0501: type name expected at token ""

Fragment info
-
(0) : error C: syntax error, unexpected $end at token ""
(0) : error C0501: type name expected at token ""




Here I have where I initialize the shader:


Code:
osg::StateSet* brickState = node->getOrCreateStateSet();

osg::Program* brickProgramObject= new osg::Program;
osg::Shader* brickVertexObject  = new osg::Shader( 
osg::Shader::VERTEX );
osg::Shader* brickFragmentObject= new osg::Shader( 
osg::Shader::FRAGMENT );
osg::Shader* brickGeometryObject= new osg::Shader( 
osg::Shader::GEOMETRY );

brickProgramObject->addShader( brickFragmentObject );
brickProgramObject->addShader( brickVertexObject   );
brickProgramObject->addShader( brickGeometryObject );

brickVertexObject->readShaderFile  ( osg::Shader::VERTEX   , 
"/home/Pau/OSG/Test1/Debug/Shaders/TestG80_VS.glsl" );
brickFragmentObject->readShaderFile( osg::Shader::FRAGMENT , 
"/home/Pau/OSG/Test1/Debug/Shaders/TestG80_GS2.glsl" );
brickGeometryObject->readShaderFile( osg::Shader::GEOMETRY , 
"/home/Pau/OSG/Test1/Debug/Shaders/TestG80_FS.glsl" );

brickProgramObject->setParameter( GL_GEOMETRY_INPUT_TYPE_EXT   , 
GL_POINTS );
brickProgramObject->setParameter( GL_GEOMETRY_OUTPUT_TYPE_EXT  , 
GL_TRIANGLE_STRIP );
brickProgramObject->setParameter( GL_GEOMETRY_VERTICES_OUT_EXT , 16 );


glGenTextures(1, &triTableTex );
glActiveTexture(GL_TEXTURE2);
glEnable(GL_TEXTURE_2D);

glBindTexture(GL_TEXTURE_2D, triTableTex);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE);

glTexImage2D( GL_TEXTURE_2D, 0, GL_ALPHA16I_EXT, 16, 256, 0, 
GL_ALPHA_INTEGER_EXT, GL_INT, &triTable);

float isolevel = 0.2;
osg::Uniform* triTableU = new osg::Uniform("triTableTex", 0 );
osg::Uniform* isolevelU = new osg::Uniform("isolevel", isolevel );

osg::Uniform* vtxDecal0U = new osg::Uniform("vertDecals[0]", 
osg::Vec3f( 0.0f, 0.0f , 0.0f   
   ) );
osg::Uniform* vtxDecal1U = new osg::Uniform("vertDecals[1]", 
osg::Vec3f( this->m_vStep.x , 0.0f , 0.0f   
   ) );
osg::Uniform* vtxDecal2U = new osg::Uniform("vertDecals[2]", 
osg::Vec3f( this->m_vStep.x , this->m_vStep.y  , 0.0f   
   ) );
osg::Uniform* vtxDecal3U = new osg::Uniform("vertDecals[3]", 
osg::Vec3f( 0.0f, this->m_vStep.y  , 0.0f   
   ) );
osg::Uniform* vtxDecal4U = new osg::Uniform("vertDecals[4]", 
osg::Vec3f( 0.0f, 0.0f , 
this->m_vStep.z   ) );
osg::Uniform* vtxDecal5U = new osg::Uniform("vertDecals[5]", 
osg::Vec3f( this->m_vStep.x , 0.0f , this->m_vStep.z
   ) );
osg::Uniform* vtxDecal6U = new osg::Uniform("vertDecals[6]", 
osg::Vec3f( this->m_vStep.x , this->m_vStep.y  , this->m_vStep.z   ) );
osg::Uniform* vtxDecal7U = new osg::Uniform("vertDecals[7]", 
osg::Vec3f( 0.0f, this->m_vStep.y  , this->m_vStep.z
   ) );

brickState->addUniform( triTableU );
brickState->addUniform( isolevelU );
brickState->addUniform( vtxDecal0U );
brickState->addUniform( vtxDecal1U );
brickState->addUniform( vtxDecal2U );
brickState->addUniform( vtxDecal3U );
brickState->addUniform( vtxDecal4U );
brickState->addUniform( vtxDecal5U );
brickState->addUniform( vtxDecal6U );
brickState->addUniform( vtxDecal7U );

brickState->s

Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[J.P. Delport]

Hi,

Brian R Hill wrote:

Hi JP,

I'm using a 3rd party library to do filtering on the rendered image. They
do all their magic using opengl in a function call from the
postdrawcallback.

Here's what it currently does:

draw -> FBO -> copy to cpu -> postdraw

The postdraw operates on the FBO after it's been copied to the cpu and I
never see it.

Here's what I want to do:

draw -> FBO -> postdraw -> copy to cpu

I want to access the image with the filtering effects included.

Does this make it clearer?


Yes.



My fallback is to not attach an image to the FBO and do the copying myself
in the postdrawcallback after the filtering.


This sounds OK to me, do you have problems with it? AFAIK you cannot 
change the order for a single FBO camera. The only other option I can 
think of (if you don't want to manually copy) is to create a second FBO 
camera solely for copying the result of the filtering (input texture to 
the second camera) to an osg::Image.


Then you have

draw -> FBO1 -> postdraw -> FBO2 -> to CPU

jp




Brian


This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: "J.P. Delport" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/05/2009 02:17PM
Subject: Re: [osg-users] RenderStage::draw order of copyTexture   and
PostDrawCallback

Hi Brian,

Brian R Hill wrote:

Sorry about the multiple posts/wrong subjects. Another copy/paste

artifact.

Folks,

I'm doing offscreen rendering using fbos with attached images. I'm also
using the postdrawcallback to do additional processing. Currently the
image/texture copy occurs before the postdrawcallback resulting in the
image/texture not having the postdraw effects.

Is there a reason why the copy isn't after the postdrawcallback?


Copy to where?

In the postdrawcallback you have the result of the rendering to FBO
copied back to the CPU (osg::Image) if an image was attached to your FBO
camera. You can modify the data in the callback and then call dirty on
the image and the texture would be updated on GPU. If you then use this
texture you should see changes. The osgprerender example does exactly
this. I'm not sure if you are expecting anything else? If so, please
provide more details on what you want to do.

cheers
jp


Thanks,

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
___
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
___
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

Re: [osg-users] RTT problem - missing faces

[Mathias]

Hi Robert,

I can really understand your situation :-) Maybe someone else has a good
idea?

Greetings
Mathias

Robert Osfield wrote:
> Hi Mathias,
>
> I'm afraid I have way too much work on my plate to go investigating
> user applications.
>
> Robert.
>
> On Wed, Aug 5, 2009 at 2:44 PM, Mathias Buhr wrote:
>   
>> Thanks again Robert! I really appreciate it.
>>
>> I've build a small example which should help to demonstrate the problem. I
>> removed the post processing since it is not reallly helpful nor the problem.
>> I hope this helps
>>
>> Greetings
>> Mathias
>>
>> Am 05.08.09 14:49, schrieb Robert Osfield:
>> 
>>> Hi Mathias,
>>>
>>> I can't really give you any recommendation as you are already doing
>>> custom code w.r.t FBO which means there is too many unknowns for me to
>>> guess at.
>>>
>>> Robert.
>>>
>>> On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhr  wrote:
>>>   
 Yes, thats exactly the plan but I need the images back in the FB to get
 the
 3rd party stuff working. This means I have to call
 glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to
 distortion-code or the function won't work. This assumes the image in
 GL_BACK and GL_BACK has to be stored to the FBO afterwards.
 How to do this?

 Greetings
 MAthias

 Am 05.08.09 14:08, schrieb Robert Osfield:
 
> HI Mathias,
>
> Given your setup it's pretty clear that you'd need to not use the OSG
> in built stereo support (that is implemented internally using
> osgUtil::SceneView), and instead setup up two slave camera sets that
> do the render to texture/post render for each eye and in the final
> step do the checkboard stereo at the same time
>   
 
> Robert.
>
> On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhr
>  wrote:
>   
>> Hi Robert,
>>
>> thank you for your answer.
>> I'll try to give some more details on the current setup:
>> - multiple physical displays/projectors which overlap to produce a
>> single
>> (flat-)screen
>> - alignment and blending of the displays is done with the 3rd-party
>> stuff
>> - the displays support checkerboard-stereo
>>
>> In mono-mode my integration of OSG and the 3rd party stuff works
>> perfectly
>> and all display do what they are supposed to do. The post-processing is
>> done
>> in the camera's postDrawCallback without any magic :) The problem
>> starts
>> when I enable OSGs checkerboard-stereo because the image-distortion in
>> the
>> postDrawCallback will result in an unusable checkerboard-frame. So
>> basically
>> I'm trying to get checkerboard-stereo to work.
>> Due to the described problem, I need access to the left and right
>> frames
>> to
>> distort them individually. Normally they are "blend together" via
>> stenciling
>> in osg::RenderStage::draw(). As far as I know, there is no direct
>> access
>> to
>> these frames. I could either implement some kind of callback into OSG
>> or
>> implement a variant of checkerboard-stereo myself.
>> Currently I'm trying to render both frames individually to an FBO and
>> putting them together afterwards. In this case I would have control  of
>> both
>> frames and I would be able to manipulate them with the help of the
>> 3rd-party
>> code.  osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT
>> wasn't
>> able to do the trick since I've found no way to access the FBO OSG
>> utilizes.
>> Therefore I've tried my own implementation (currently on a single
>> display)
>> with the following setup and the given result in the post before (take
>> a
>> look at the attached picture).
>>
>> The current implementation is very similiar to the osgprerender example
>> (stereo is not enabled) except that I'm creating my own FBO in a
>> preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture
>> and
>> is used as the rendertarget for the first (left) (RTT-)camera.
>> RenderTargetImplementation for this camera has not been explicitly set.
>> The
>> texture is attached to a rectangular geometry, which is itself a child
>> of
>> the osgViewers camera. Unfortunately the result of the RTT looks like
>> the
>> attached image. The image was saved in the postDrawCallback. I'm pretty
>> sure
>> I've messed something up or missed something. RTT with OSGs FBO works
>> fine
>> and I've looked at the code but I didn't find anything.
>>
>> Does someone have an idea? Or maybe another way to implement
>> checkerboard-stereo? It looks like some faces get culled away. If its
>> useful
>> I'll post some code.
>>
>> @Robert: I'm not using osgUtils low level stereo right now but I guess
>> some
>> of the code would later be useful to get th

[osg-users] Billboard problem

[Markus Husseini]

Hello,

i tried to place some treebillboards in my Terrain, but i have problems with 
the texturing.

I have two textures:

[Image: http://www.husseini.de/markus/C.jpg ]
[Image: http://www.husseini.de/markus/T.jpg ]

If I render the billboard the black color should be invisible but it doesn't 
work.

I get this code from the Osg Help Tutorials.


m_refTexPencil = new osg::Texture2D;
m_refTexPencil->setImage( osgDB::readImageFile( _Pencil ) );

m_refTexCracks = new osg::Texture2D;
m_refTexCracks->setImage( osgDB::readImageFile( _Cracks ) );

m_refGeo= new osg::Geometry;
  
m_refVerts  = new osg::Vec3Array;
m_refVerts->push_back( osg::Vec3( 0, 0, 0 )+vecPos );
m_refVerts->push_back( osg::Vec3( 100, 0, 0 )+vecPos );
m_refVerts->push_back( osg::Vec3( 100, 0, 100 )+vecPos );
m_refVerts->push_back( osg::Vec3( 0, 0, 100 )+vecPos );
m_refGeo->setVertexArray( m_refVerts );

m_refPrimitiveSet   = new osg::DrawElementsUInt( 
osg::PrimitiveSet::QUADS, 0 );
m_refPrimitiveSet->push_back( 3 );
m_refPrimitiveSet->push_back( 2 );
m_refPrimitiveSet->push_back( 1 );
m_refPrimitiveSet->push_back( 0 );
m_refGeo->addPrimitiveSet( m_refPrimitiveSet );

m_refTexCoords  = new osg::Vec2Array( 4 );
(*m_refTexCoords)[0].set( 0.0f, 0.0f );
(*m_refTexCoords)[1].set( 1.0f, 0.0f );
(*m_refTexCoords)[2].set( 1.0f, 1.0f );
(*m_refTexCoords)[3].set( 0.0f, 1.0f );
m_refGeo->setTexCoordArray( 0, m_refTexCoords );
m_refGeo->setTexCoordArray( 1, m_refTexCoords );

m_refBillboard  = new osg::Billboard;
m_refBillboard->setMode( osg::Billboard::AXIAL_ROT );//POINT_ROT_EYE );

m_refStateSet   = m_refBillboard->getOrCreateStateSet();
m_refStateSet->setMode( GL_LIGHTING, osg::StateAttribute::OFF );
m_refStateSet->setMode( GL_BLEND, osg::StateAttribute::ON );
m_refStateSet->setMode( GL_CULL_FACE, osg::StateAttribute::OFF );
m_refStateSet->setTextureAttributeAndModes( 0, m_refTexPencil, 
osg::StateAttribute::ON );
m_refStateSet->setTextureAttributeAndModes( 1, m_refTexCracks, 
osg::StateAttribute::ON );

m_refBillboard->addDrawable( m_refGeo );

m_refTexEnv = new osg::TexEnvCombine;

m_refTexEnv->setCombine_RGB( osg::TexEnvCombine::MODULATE );   
m_refTexEnv->setSource0_RGB( osg::TexEnvCombine::TEXTURE0 );   
m_refTexEnv->setOperand0_RGB( osg::TexEnvCombine::SRC_COLOR); 
m_refTexEnv->setSource1_RGB( osg::TexEnvCombine::TEXTURE1 );   
m_refTexEnv->setOperand1_RGB( osg::TexEnvCombine::SRC_COLOR );   

m_refStateSet->setTextureAttribute( 1, m_refTexEnv );

m_refPat= new osg::PositionAttitudeTransform;
m_refPat->setPosition( vecPos );
m_refPat->addChild( m_refBillboard );

Thx for Help.

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





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

Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[Brian R Hill]

Hi JP,

I'm using a 3rd party library to do filtering on the rendered image. They
do all their magic using opengl in a function call from the
postdrawcallback.

Here's what it currently does:

draw -> FBO -> copy to cpu -> postdraw

The postdraw operates on the FBO after it's been copied to the cpu and I
never see it.

Here's what I want to do:

draw -> FBO -> postdraw -> copy to cpu

I want to access the image with the filtering effects included.

Does this make it clearer?

My fallback is to not attach an image to the FBO and do the copying myself
in the postdrawcallback after the filtering.

Brian


This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: "J.P. Delport" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/05/2009 02:17PM
Subject: Re: [osg-users] RenderStage::draw order of copyTexture   and
PostDrawCallback

Hi Brian,

Brian R Hill wrote:
> Sorry about the multiple posts/wrong subjects. Another copy/paste
artifact.
>
> Folks,
>
> I'm doing offscreen rendering using fbos with attached images. I'm also
> using the postdrawcallback to do additional processing. Currently the
> image/texture copy occurs before the postdrawcallback resulting in the
> image/texture not having the postdraw effects.
>
> Is there a reason why the copy isn't after the postdrawcallback?

Copy to where?

In the postdrawcallback you have the result of the rendering to FBO
copied back to the CPU (osg::Image) if an image was attached to your FBO
camera. You can modify the data in the callback and then call dirty on
the image and the texture would be updated on GPU. If you then use this
texture you should see changes. The osgprerender example does exactly
this. I'm not sure if you are expecting anything else? If so, please
provide more details on what you want to do.

cheers
jp

>
> Thanks,
>
> Brian
>
> This is a PRIVATE message. If you are not the intended recipient, please
> delete without copying and kindly advise us by e-mail of the mistake in
> delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
> any order or other contract unless pursuant to explicit written agreement
> or government initiative expressly permitting the use of e-mail for such
> purpose. •
> ___
> 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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Computing depth buffer in osgVolume

[Yvon Halbwachs]

Hi,

I would like to add the computation of the z-depth value in the ray 
traced volume shaders. I'm pretty new to raytracing on gpu, so forgive 
me if this is a naive question!


I've tried to add this code in the fragment shader, just after the line 
"gl_FragColor = color":


  
  gl_FragColor = color;

  vec4 inter = gl_ModelViewProjectionMatrix * vec4(texcoord,1);
  gl_FragDepth = inter.z / inter.w;

  return;
  
In theory my idea is to compute the position of the intersection with 
the volume, and use the model view & projection transformation matrix to 
get z buffer value computed. It looks good... but it's not right!


Does any one have an idea about what I'm doing wrong?

Thanks for any help,

Regards,

Yvon

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

Re: [osg-users] Offscreen Rendering - clamping problem

[J.P. Delport]

Hi,

why are you not reading the floating point values directly from the FBO 
without worrying about the final frame buffer precision?


Have a look at the callback in osgmultiplerendertargets for the GL_FLOAT 
case. You can get a CPU copy of your floating point FBO and manipulate 
the data as you want.


cheers
jp

Brian R Hill wrote:

I think I found the reason. It looks like X windows doesn't support
floating point pbuffers.

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: Brian R Hill/DEF/c...@csc
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/04/2009 06:02PM
Subject: [osg-users] Offscreen Rendering - clamping problem


Folks,

Sorry for another post on this subject. I just can't figure out how to
disable the clamping of the output. I'm want to render offscreen without a
window with 32 bit floats.

Attached is the sample code I'm working with, it's based on the
osgscreencapture.cpp example. It uses a shader to write an input uniform
float "val" to the pbuffer. The "val" varies from -1.0 ... 2.0.

Any help would be appreciated.

Thanks,

Brian
(See attached file:
offscreenrender.cpp)___
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 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

Re: [osg-users] RenderStage::draw order of copyTexture and PostDrawCallback

[J.P. Delport]

Hi Brian,

Brian R Hill wrote:

Sorry about the multiple posts/wrong subjects. Another copy/paste artifact.

Folks,

I'm doing offscreen rendering using fbos with attached images. I'm also
using the postdrawcallback to do additional processing. Currently the
image/texture copy occurs before the postdrawcallback resulting in the
image/texture not having the postdraw effects.

Is there a reason why the copy isn't after the postdrawcallback?


Copy to where?

In the postdrawcallback you have the result of the rendering to FBO 
copied back to the CPU (osg::Image) if an image was attached to your FBO 
camera. You can modify the data in the callback and then call dirty on 
the image and the texture would be updated on GPU. If you then use this 
texture you should see changes. The osgprerender example does exactly 
this. I'm not sure if you are expecting anything else? If so, please 
provide more details on what you want to do.


cheers
jp



Thanks,

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
___
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

Re: [osg-users] Offscreen Rendering - clamping problem

[Brian R Hill]

I think I found the reason. It looks like X windows doesn't support
floating point pbuffers.

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
-osg-users-boun...@lists.openscenegraph.org wrote: -

To: OpenSceneGraph Users 
From: Brian R Hill/DEF/c...@csc
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/04/2009 06:02PM
Subject: [osg-users] Offscreen Rendering - clamping problem


Folks,

Sorry for another post on this subject. I just can't figure out how to
disable the clamping of the output. I'm want to render offscreen without a
window with 32 bit floats.

Attached is the sample code I'm working with, it's based on the
osgscreencapture.cpp example. It uses a shader to write an input uniform
float "val" to the pbuffer. The "val" varies from -1.0 ... 2.0.

Any help would be appreciated.

Thanks,

Brian
(See attached file:
offscreenrender.cpp)___
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] RenderStage::draw order of copyTexture and PostDrawCallback

[Brian R Hill]

Sorry about the multiple posts/wrong subjects. Another copy/paste artifact.

Folks,

I'm doing offscreen rendering using fbos with attached images. I'm also
using the postdrawcallback to do additional processing. Currently the
image/texture copy occurs before the postdrawcallback resulting in the
image/texture not having the postdraw effects.

Is there a reason why the copy isn't after the postdrawcallback?

Thanks,

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Offscreen Rendering - clamping problem

[Brian R Hill]

Folks,

I'm doing offscreen rendering using fbos with attached images. I'm also
using the postdrawcallback to do additional processing. Currently the
image/texture copy occurs before the postdrawcallback resulting in the
image/texture not having the postdraw effects.

Is there a reason why the copy isn't after the postdrawcallback?

Thanks,

Brian


This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] glMultiTexCoord4f , OSG with OGL code

[Thrall, Bryan]

Pau Moreno wrote on Wednesday, August 05, 2009 12:22 PM:
> Since I know, OSG doesn't have support for geometry shaders, does it?
I'll
> check it again. 

It has had support since January, 2008, according to the SVN log; see
osg::Shader.

-- 
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] glMultiTexCoord4f , OSG with OGL code

[Pau Moreno]

Hi,

Since I know, OSG doesn't have support for geometry shaders, does it? I'll 
check it again.

Thank you!

Cheers,
Pau

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





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

Re: [osg-users] osgText texture not reloading correctly thesecondtime?

[Tanguy Fautre]

Hi Robert,

Thanks for the explanation. It clears quite a lot of confusion.

I've added the stopThreading(), and this build is going to go through a
test cycle tonight, so I will know fairly soon if the problem still
appears.

Cheers,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 05 August 2009 17:20
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgText texture not reloading correctly
thesecondtime?

Hi Tanguy,

On Wed, Aug 5, 2009 at 4:53 PM, Tanguy
Fautre wrote:
> Robert, could you confirm that the rendering thread is not supposed to
> be actively culling/drawing when being outside of Viewer::run() (or
more
> precisely, Viewer::frame())?

If you are using DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext then the draw thread will run
over the end of frame() or even run().

Call viewer.stopThreading(); to ensure the threads are stopped.

--

W.r.t osgText not clearing it's GL objects properly, in theory
releaseGLobjects() should work, and should purge the graphics context
just fine. Looking at the implementation of Tex

void Text::releaseGLObjects(osg::State* state) const
{
TextBase::releaseGLObjects(state);
getActiveFont()->releaseGLObjects(state);
}

And

void Font::releaseGLObjects(osg::State* state) const
{
if (_stateset.valid()) _stateset->releaseGLObjects(state);

for(GlyphTextureList::const_iterator itr=_glyphTextureList.begin();
itr!=_glyphTextureList.end();
++itr)
{
(*itr)->releaseGLObjects(state);
}

// const_cast(this)->_glyphTextureList.clear();
// const_cast(this)->_sizeGlyphMap.clear();
}


Which broadly looks to be the right thing.


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

Re: [osg-users] osgText texture not reloading correctly the secondtime?

[Robert Osfield]

Hi Tanguy,

On Wed, Aug 5, 2009 at 4:53 PM, Tanguy
Fautre wrote:
> Robert, could you confirm that the rendering thread is not supposed to
> be actively culling/drawing when being outside of Viewer::run() (or more
> precisely, Viewer::frame())?

If you are using DrawThreadPerContext or
CullThreadPerCameraDrawThreadPerContext then the draw thread will run
over the end of frame() or even run().

Call viewer.stopThreading(); to ensure the threads are stopped.

--

W.r.t osgText not clearing it's GL objects properly, in theory
releaseGLobjects() should work, and should purge the graphics context
just fine. Looking at the implementation of Tex

void Text::releaseGLObjects(osg::State* state) const
{
TextBase::releaseGLObjects(state);
getActiveFont()->releaseGLObjects(state);
}

And

void Font::releaseGLObjects(osg::State* state) const
{
if (_stateset.valid()) _stateset->releaseGLObjects(state);

for(GlyphTextureList::const_iterator itr=_glyphTextureList.begin();
itr!=_glyphTextureList.end();
++itr)
{
(*itr)->releaseGLObjects(state);
}

// const_cast(this)->_glyphTextureList.clear();
// const_cast(this)->_sizeGlyphMap.clear();
}


Which broadly looks to be the right thing.


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

Re: [osg-users] osgText texture not reloading correctly the secondtime?

[Tanguy Fautre]

Hi guys,

We're having the same problem here. Textures are corrupted or are
showing the wrong image when the viewer is destroyed and re-created.
I've been tracking it for a week now. Here is the simplified core logic
of the application that shows the problem.

For (;;)
{
{
osgViewer::Viewer viewer();
viewer.setSceneData(scene_data);

viewer.run();

scene_data->releaseGLObjects();
osgDB::Registry::instance()->releaseGLObjects();
}

/* do other stuff */
}


- The problem appears randomly, it's not deterministic.
- The problem appears on all kind of different hardware.
- Destroying all the osg::Texture objects in scene_data after run() (and
re-creating them before run()) seems to solve the problem (note osgText
still appears corrupted.
- Only the textures that were shown during the last frame are corrupted;
all other textures are fine.


I've noticed something really strange once. The debugger stopped with an
assert on an invalid iterator usage. It happened in the graphics thread,
doing the culling. What puzzled me is that the graphic thread was still
running while the main thread is already in the viewer destructor
(thereby causing the culling to iterate over a scene that is no longer
valid). In fact the graphic thread was actively running and doing
culling/drawing after viewer.run() had exited.

Robert, could you confirm that the rendering thread is not supposed to
be actively culling/drawing when being outside of Viewer::run() (or more
precisely, Viewer::frame())?


>From what I understand from Texture.cpp and Texture2D.cpp, if the
graphic thread were to be still running after calling
releaseGLObjects(), the osg::Texture objects would re-create an
osg::Texture::TextureObject (containing the actual OpenGL texture
object) and be left in a state where they think they have a valid
TextureObject. This would explain quite a lot.


Cheers,

Tanguy



-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Juan
Casanueva
Sent: 04 May 2009 17:21
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] osgText texture not reloading correctly the
secondtime?


Hi JS,

I think I have exactly the same problem you are having.
I have an application that opens/closes a osg viewer. When I close the
osg viewer, everything gets deleted, even the viewer. However, when I
open the viewer the second time, some of the textures do not appear.
This seems to be happening at random, since the textures that disappear
are not the same ones every time. Sometimes its the terrain textures,
sometimes the clouds, sometimes the 3d models (.ac)...  I must say that
the problem does not happen every time on my application. It happens
from time to time, although if I open/close the viewer 3 or 4 times I
eventually end up seeing the problem.

I have no idea what is causing this problem, so I can't really help:(
Just to let you know that it is not happening only on your application
:)

regards
Juan

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





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

Re: [osg-users] 3DS loader revisited?

[Robert Osfield]

Hi Sukender,

In the past (quite a few years ago now) I did sync with lib3ds, but it
didn't change for a long while so haven't kept up with it.  The OSG's
version has now diverged substationally from lib3ds with it's use of
istream's rather than FILE so an easy merge will no longer be
possible.

What could probably do is backport the features from the current
lib3ds you want.

Robert.

On Wed, Aug 5, 2009 at 3:30 PM, Sukender wrote:
> Hi all,
>
> I'm working on something that needs 3DS import (Well, a modified 3DS import, 
> that reads data in keyframes). However I noticed the underlying lib3DS seems 
> a bit old (and it seems the few problems I got are related). Is that really 
> true? Should we work on "upgrading" the loader, or is there a risk to break 
> compatibility?
> Any thoughts will be appreciated...
> Thanks!
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
> ___
> 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] 3DS loader revisited?

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Sukender,

Sukender wrote:
> Hi all,
> 
> I'm working on something that needs 3DS import (Well, a modified 3DS
> import, that reads data in keyframes). However I noticed the
> underlying lib3DS seems a bit old (and it seems the few problems I
> got are related). Is that really true? Should we work on "upgrading"
> the loader, or is there a risk to break compatibility? Any thoughts
> will be appreciated... Thanks!
> 

I recall having the same issue at one point and Robert said to go ahead
with updating it. I just never got to it due to other things. So I would
say it should be a safe bet to update it, but ideally we should factor
out the bundled library and put it in the dependencies instead. It makes
for cleaner design and allows to use the system-provided one on Linux,
for example.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFKeaWhn11XseNj94gRAr85AKDmY+cIbDrkFnzmz7IOh9s5YHALGgCgzZ5N
qoNaH85r//lOit7tyF0y7hI=
=I8QH
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG and shaders

[Hadrien Thomas]

Thank you very much, I was so desperate  :\

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





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

Re: [osg-users] OSG and shaders

[Maxime BOUCHER]

Well,

 I'm doing an internship too.

At the beginning I didn't know osg at all, neither shaders.
There are still an extraordinary amount of things I ignore about OSG (my 
advice: when you try to do or understand something, take a look at how it's 
done in OpenGL).
Shaders aren't as hard to use as OSG, I discovered about one month ago and I 
can now write some modests but nice effects.

The essential is to read code and tutorials.
Don't try to go fast, it's the best way to misunderstand what you manipulate 
and to write bad code, failing your internship. You have 6 months, you can 
waste it OR spend 2 months to understand osg and shaders and then writting good 
code, masterizing your internship.

Thus, first read a few osg tutorials (to understand how textures are mapped for 
example, it seems you don't), I think the 4 or 5 firsts should be enough.
After, try to understand what is a shader (I guess you don't really).
Then try to understand the shader tutorials from typhoonlabs, or this 
(http://www.siteduzero.com/tutoriel-3-8879-communiquer-avec-l-application-attributs-et-uniforms.html?bcsi-ac-20A76BC15DBD50F6=194870AE0303lbVE9ryZWUuZzrBgMzY7DS6IPWi9BwMAAMDCRwEQDgAAINVbBwA=),
 it's in french.
I advice to look at osgshader example ONLY to understand (or copy the code) how 
to load and activate a shader, it's 5 lines.

Don't take me for moralistic, I did these errors.

Good luck and take your time, it's the best way to success.

Cheers,
Maxime

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





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

[osg-users] 3DS loader revisited?

[Sukender]

Hi all,

I'm working on something that needs 3DS import (Well, a modified 3DS import, 
that reads data in keyframes). However I noticed the underlying lib3DS seems a 
bit old (and it seems the few problems I got are related). Is that really true? 
Should we work on "upgrading" the loader, or is there a risk to break 
compatibility?
Any thoughts will be appreciated...
Thanks!

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osg 2.2 How to disable picking for objects attached to camera with smaller viewport when they are not visible in the scene

[James Sim]

Hi Robert,

I thought about what you mentioned but i dont think that method will work for 
me.

I am trying to do a scroll panel which has a variable size. I am using the 
approach where i have a sub camera which projects only some parts of the 
contents attached to the camera. 

I realised that the contents are pickable even if there are not visible. 

I was thinking if theres a method which can detect nodes that are not visible 
and disable picking. However, it seems like i have to manually detect? In that 
way, it seems alittle inefficient?

Thank you for your help!

Cheers,
James

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





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

Re: [osg-users] RTT problem - missing faces

[Robert Osfield]

Hi Mathias,

I'm afraid I have way too much work on my plate to go investigating
user applications.

Robert.

On Wed, Aug 5, 2009 at 2:44 PM, Mathias Buhr wrote:
> Thanks again Robert! I really appreciate it.
>
> I've build a small example which should help to demonstrate the problem. I
> removed the post processing since it is not reallly helpful nor the problem.
> I hope this helps
>
> Greetings
> Mathias
>
> Am 05.08.09 14:49, schrieb Robert Osfield:
>>
>> Hi Mathias,
>>
>> I can't really give you any recommendation as you are already doing
>> custom code w.r.t FBO which means there is too many unknowns for me to
>> guess at.
>>
>> Robert.
>>
>> On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhr  wrote:
>>>
>>> Yes, thats exactly the plan but I need the images back in the FB to get
>>> the
>>> 3rd party stuff working. This means I have to call
>>> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to
>>> distortion-code or the function won't work. This assumes the image in
>>> GL_BACK and GL_BACK has to be stored to the FBO afterwards.
>>> How to do this?
>>>
>>> Greetings
>>> MAthias
>>>
>>> Am 05.08.09 14:08, schrieb Robert Osfield:

 HI Mathias,

 Given your setup it's pretty clear that you'd need to not use the OSG
 in built stereo support (that is implemented internally using
 osgUtil::SceneView), and instead setup up two slave camera sets that
 do the render to texture/post render for each eye and in the final
 step do the checkboard stereo at the same time
>>>
>>>
 Robert.

 On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhr
  wrote:
>
> Hi Robert,
>
> thank you for your answer.
> I'll try to give some more details on the current setup:
> - multiple physical displays/projectors which overlap to produce a
> single
> (flat-)screen
> - alignment and blending of the displays is done with the 3rd-party
> stuff
> - the displays support checkerboard-stereo
>
> In mono-mode my integration of OSG and the 3rd party stuff works
> perfectly
> and all display do what they are supposed to do. The post-processing is
> done
> in the camera's postDrawCallback without any magic :) The problem
> starts
> when I enable OSGs checkerboard-stereo because the image-distortion in
> the
> postDrawCallback will result in an unusable checkerboard-frame. So
> basically
> I'm trying to get checkerboard-stereo to work.
> Due to the described problem, I need access to the left and right
> frames
> to
> distort them individually. Normally they are "blend together" via
> stenciling
> in osg::RenderStage::draw(). As far as I know, there is no direct
> access
> to
> these frames. I could either implement some kind of callback into OSG
> or
> implement a variant of checkerboard-stereo myself.
> Currently I'm trying to render both frames individually to an FBO and
> putting them together afterwards. In this case I would have control  of
> both
> frames and I would be able to manipulate them with the help of the
> 3rd-party
> code.  osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT
> wasn't
> able to do the trick since I've found no way to access the FBO OSG
> utilizes.
> Therefore I've tried my own implementation (currently on a single
> display)
> with the following setup and the given result in the post before (take
> a
> look at the attached picture).
>
> The current implementation is very similiar to the osgprerender example
> (stereo is not enabled) except that I'm creating my own FBO in a
> preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture
> and
> is used as the rendertarget for the first (left) (RTT-)camera.
> RenderTargetImplementation for this camera has not been explicitly set.
> The
> texture is attached to a rectangular geometry, which is itself a child
> of
> the osgViewers camera. Unfortunately the result of the RTT looks like
> the
> attached image. The image was saved in the postDrawCallback. I'm pretty
> sure
> I've messed something up or missed something. RTT with OSGs FBO works
> fine
> and I've looked at the code but I didn't find anything.
>
> Does someone have an idea? Or maybe another way to implement
> checkerboard-stereo? It looks like some faces get culled away. If its
> useful
> I'll post some code.
>
> @Robert: I'm not using osgUtils low level stereo right now but I guess
> some
> of the code would later be useful to get the correct left and right
> camera-position-setup.
>
> Nice greetings and thanks for any help or hint!
> Mathias Buhr
>
> P.S.: I was already able to do the distortion with that implementation
> (with
> blitting the FBO-image back to the window-system provided FB to get the
> 3rd
>

Re: [osg-users] OSG and shaders

[Hadrien Thomas]

Thank you for the links. I have already read them and found nothing useful at 
this stage.

As every link I've read...

The shaders codes are given without the mains, the mains without the shaders, 
the openscenegraph.org tutorials are with osgGL2 (which I can't work with), and 
there is no other tutorial on openscenegraph WITH shaders.

I opened something like 300 links these past three days.
I had to combine 5 of them to get to understand what is a shader, to load it 
and to write:

gl_Position = ftransform();
gl_FragColor = gl_Color;

for .vert and .frag

One more day to know how to send the texture. And now I'm stuck with the 
mapping.

Has anyone a long rope?

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





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

Re: [osg-users] RTT problem - missing faces

[Mathias Buhr]

Thanks again Robert! I really appreciate it.

I've build a small example which should help to demonstrate the problem. 
I removed the post processing since it is not reallly helpful nor the 
problem. I hope this helps


Greetings
Mathias

Am 05.08.09 14:49, schrieb Robert Osfield:

Hi Mathias,

I can't really give you any recommendation as you are already doing
custom code w.r.t FBO which means there is too many unknowns for me to
guess at.

Robert.

On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhr  wrote:

Yes, thats exactly the plan but I need the images back in the FB to get the
3rd party stuff working. This means I have to call
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to
distortion-code or the function won't work. This assumes the image in
GL_BACK and GL_BACK has to be stored to the FBO afterwards.
How to do this?

Greetings
MAthias

Am 05.08.09 14:08, schrieb Robert Osfield:


HI Mathias,

Given your setup it's pretty clear that you'd need to not use the OSG
in built stereo support (that is implemented internally using
osgUtil::SceneView), and instead setup up two slave camera sets that
do the render to texture/post render for each eye and in the final
step do the checkboard stereo at the same time




Robert.

On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhrwrote:


Hi Robert,

thank you for your answer.
I'll try to give some more details on the current setup:
- multiple physical displays/projectors which overlap to produce a single
(flat-)screen
- alignment and blending of the displays is done with the 3rd-party stuff
- the displays support checkerboard-stereo

In mono-mode my integration of OSG and the 3rd party stuff works
perfectly
and all display do what they are supposed to do. The post-processing is
done
in the camera's postDrawCallback without any magic :) The problem starts
when I enable OSGs checkerboard-stereo because the image-distortion in
the
postDrawCallback will result in an unusable checkerboard-frame. So
basically
I'm trying to get checkerboard-stereo to work.
Due to the described problem, I need access to the left and right frames
to
distort them individually. Normally they are "blend together" via
stenciling
in osg::RenderStage::draw(). As far as I know, there is no direct access
to
these frames. I could either implement some kind of callback into OSG or
implement a variant of checkerboard-stereo myself.
Currently I'm trying to render both frames individually to an FBO and
putting them together afterwards. In this case I would have control  of
both
frames and I would be able to manipulate them with the help of the
3rd-party
code.  osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT
wasn't
able to do the trick since I've found no way to access the FBO OSG
utilizes.
Therefore I've tried my own implementation (currently on a single
display)
with the following setup and the given result in the post before (take a
look at the attached picture).

The current implementation is very similiar to the osgprerender example
(stereo is not enabled) except that I'm creating my own FBO in a
preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture
and
is used as the rendertarget for the first (left) (RTT-)camera.
RenderTargetImplementation for this camera has not been explicitly set.
The
texture is attached to a rectangular geometry, which is itself a child of
the osgViewers camera. Unfortunately the result of the RTT looks like the
attached image. The image was saved in the postDrawCallback. I'm pretty
sure
I've messed something up or missed something. RTT with OSGs FBO works
fine
and I've looked at the code but I didn't find anything.

Does someone have an idea? Or maybe another way to implement
checkerboard-stereo? It looks like some faces get culled away. If its
useful
I'll post some code.

@Robert: I'm not using osgUtils low level stereo right now but I guess
some
of the code would later be useful to get the correct left and right
camera-position-setup.

Nice greetings and thanks for any help or hint!
Mathias Buhr

P.S.: I was already able to do the distortion with that implementation
(with
blitting the FBO-image back to the window-system provided FB to get the
3rd
party stuff working).



Am 04.08.09 19:14, schrieb Robert Osfield:


Hi Mathias,

You don't really provide enough info about your overall viewer setup
to give a direct answer.  It sounds like you are using the OSG's low
level stereo support in osgUtil and combining this with a 3rd party
code that does distortion correction or similar.  Doing low level
stereo and distortion correction is really going to work visually even
if you got it to work code wise, as the low level stereo support in
osgUtil assumes a flat display.

Have a bash at explaining what your system is trying to do at a high
level and then others will have a better chance of suggesting how to
go about it.

Robert.

On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhr
  wrote:



Hi,

before going into the details of the problem, I'd li

Re: [osg-users] Dashboard error

[Sukender]

No!!! It works now... Maybe I did something wrong?
Sorry for disturbing...

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/

- Mail d'origine -
De: Robert Osfield 
À: OpenSceneGraph Users 
Envoyé: Wed, 5 Aug 2009 10:17:11 +0200 (CEST)
Objet: Re: [osg-users] Dashboard error

Hi Sukender,

Are you still seeing these problems?

Robert.

On Tue, Aug 4, 2009 at 8:36 AM,  wrote:
> Hi Jose-Luis et al
>
> Either the dashboard does not respond, or I get the folowing error:
>
> no handler found
> Warning: error_log(backup/cdash.log) [function.error-log]: failed to open 
> stream: Permission denied in /home/www/cdash_OSG/cdash/common.php on line 192
>
> Hope it helps :)
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
> ___
> 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] RTT problem - missing faces

[Robert Osfield]

Hi Mathias,

I can't really give you any recommendation as you are already doing
custom code w.r.t FBO which means there is too many unknowns for me to
guess at.

Robert.

On Wed, Aug 5, 2009 at 1:31 PM, Mathias Buhr wrote:
> Yes, thats exactly the plan but I need the images back in the FB to get the
> 3rd party stuff working. This means I have to call
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to
> distortion-code or the function won't work. This assumes the image in
> GL_BACK and GL_BACK has to be stored to the FBO afterwards.
> How to do this?
>
> Greetings
> MAthias
>
> Am 05.08.09 14:08, schrieb Robert Osfield:
>>
>> HI Mathias,
>>
>> Given your setup it's pretty clear that you'd need to not use the OSG
>> in built stereo support (that is implemented internally using
>> osgUtil::SceneView), and instead setup up two slave camera sets that
>> do the render to texture/post render for each eye and in the final
>> step do the checkboard stereo at the same time
>
>
>> Robert.
>>
>> On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhr  wrote:
>>>
>>> Hi Robert,
>>>
>>> thank you for your answer.
>>> I'll try to give some more details on the current setup:
>>> - multiple physical displays/projectors which overlap to produce a single
>>> (flat-)screen
>>> - alignment and blending of the displays is done with the 3rd-party stuff
>>> - the displays support checkerboard-stereo
>>>
>>> In mono-mode my integration of OSG and the 3rd party stuff works
>>> perfectly
>>> and all display do what they are supposed to do. The post-processing is
>>> done
>>> in the camera's postDrawCallback without any magic :) The problem starts
>>> when I enable OSGs checkerboard-stereo because the image-distortion in
>>> the
>>> postDrawCallback will result in an unusable checkerboard-frame. So
>>> basically
>>> I'm trying to get checkerboard-stereo to work.
>>> Due to the described problem, I need access to the left and right frames
>>> to
>>> distort them individually. Normally they are "blend together" via
>>> stenciling
>>> in osg::RenderStage::draw(). As far as I know, there is no direct access
>>> to
>>> these frames. I could either implement some kind of callback into OSG or
>>> implement a variant of checkerboard-stereo myself.
>>> Currently I'm trying to render both frames individually to an FBO and
>>> putting them together afterwards. In this case I would have control  of
>>> both
>>> frames and I would be able to manipulate them with the help of the
>>> 3rd-party
>>> code.  osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT
>>> wasn't
>>> able to do the trick since I've found no way to access the FBO OSG
>>> utilizes.
>>> Therefore I've tried my own implementation (currently on a single
>>> display)
>>> with the following setup and the given result in the post before (take a
>>> look at the attached picture).
>>>
>>> The current implementation is very similiar to the osgprerender example
>>> (stereo is not enabled) except that I'm creating my own FBO in a
>>> preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture
>>> and
>>> is used as the rendertarget for the first (left) (RTT-)camera.
>>> RenderTargetImplementation for this camera has not been explicitly set.
>>> The
>>> texture is attached to a rectangular geometry, which is itself a child of
>>> the osgViewers camera. Unfortunately the result of the RTT looks like the
>>> attached image. The image was saved in the postDrawCallback. I'm pretty
>>> sure
>>> I've messed something up or missed something. RTT with OSGs FBO works
>>> fine
>>> and I've looked at the code but I didn't find anything.
>>>
>>> Does someone have an idea? Or maybe another way to implement
>>> checkerboard-stereo? It looks like some faces get culled away. If its
>>> useful
>>> I'll post some code.
>>>
>>> @Robert: I'm not using osgUtils low level stereo right now but I guess
>>> some
>>> of the code would later be useful to get the correct left and right
>>> camera-position-setup.
>>>
>>> Nice greetings and thanks for any help or hint!
>>> Mathias Buhr
>>>
>>> P.S.: I was already able to do the distortion with that implementation
>>> (with
>>> blitting the FBO-image back to the window-system provided FB to get the
>>> 3rd
>>> party stuff working).
>>>
>>>
>>>
>>> Am 04.08.09 19:14, schrieb Robert Osfield:

 Hi Mathias,

 You don't really provide enough info about your overall viewer setup
 to give a direct answer.  It sounds like you are using the OSG's low
 level stereo support in osgUtil and combining this with a 3rd party
 code that does distortion correction or similar.  Doing low level
 stereo and distortion correction is really going to work visually even
 if you got it to work code wise, as the low level stereo support in
 osgUtil assumes a flat display.

 Have a bash at explaining what your system is trying to do at a high
 level and then others will have a better chance of suggesting how to
 go abo

Re: [osg-users] how to draw a Curved Surface on the top of terrain?

[Glenn Waldron]

No - osggis does not drape polygon geometries.

Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
+1.703.652.4791


On Wed, Aug 5, 2009 at 5:45 AM, John Vidar Larring wrote:

> Hi Jason,
>
> Last time I checked (half a year ago), osggis did no create a "curved
> polygon" when creating a filled polygon for e.g. Russia. Since no sampling
> points are created inside the polygon the tessellated triangles goes
> straight from one edge to the other thought the ground.
>
> It would be great news if this has been fixed i later versions of osggis!
> Please let me know.
>
> // John
>
> Jason Beverage wrote:
>
>> Hi Lipan,
>>
>> You could look into using projected textures with the osgSim::OverlayNode
>> or if you are rendering vector data such as that from an ESRI shapefile I'd
>> recommend looking at osggis at http://www.osggis.org.
>>
>> Jason
>>
>> On Mon, Aug 3, 2009 at 7:15 AM, Pan Li > osg...@163.com>> wrote:
>>
>>Hi,
>>
>>1、how to draw a Curved Surface on the top of terrain? like the fig1.
>>2、how to compute the surface area of the Curved Surface?
>>any examples??
>>thanks a lot!!
>>
>>Cheers,
>>lipan
>>
>>--
>>Read this topic online here:
>>http://forum.openscenegraph.org/viewtopic.php?p=15723#15723
>>
>>
>>
>>
>>___
>>osg-users mailing list
>>osg-users@lists.openscenegraph.org
>>
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* , and is
>> believed to be clean.
>>
>>
>> 
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> Best regards,
> John
> WeatherOne
>
>
> ___
> 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] RTT problem - missing faces

[Mathias Buhr]

Yes, thats exactly the plan but I need the images back in the FB to get 
the 3rd party stuff working. This means I have to call 
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the call to 
distortion-code or the function won't work. This assumes the image in 
GL_BACK and GL_BACK has to be stored to the FBO afterwards.

How to do this?

Greetings
MAthias

Am 05.08.09 14:08, schrieb Robert Osfield:

HI Mathias,

Given your setup it's pretty clear that you'd need to not use the OSG
in built stereo support (that is implemented internally using
osgUtil::SceneView), and instead setup up two slave camera sets that
do the render to texture/post render for each eye and in the final
step do the checkboard stereo at the same time




Robert.

On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhr  wrote:

Hi Robert,

thank you for your answer.
I'll try to give some more details on the current setup:
- multiple physical displays/projectors which overlap to produce a single
(flat-)screen
- alignment and blending of the displays is done with the 3rd-party stuff
- the displays support checkerboard-stereo

In mono-mode my integration of OSG and the 3rd party stuff works perfectly
and all display do what they are supposed to do. The post-processing is done
in the camera's postDrawCallback without any magic :) The problem starts
when I enable OSGs checkerboard-stereo because the image-distortion in the
postDrawCallback will result in an unusable checkerboard-frame. So basically
I'm trying to get checkerboard-stereo to work.
Due to the described problem, I need access to the left and right frames to
distort them individually. Normally they are "blend together" via stenciling
in osg::RenderStage::draw(). As far as I know, there is no direct access to
these frames. I could either implement some kind of callback into OSG or
implement a variant of checkerboard-stereo myself.
Currently I'm trying to render both frames individually to an FBO and
putting them together afterwards. In this case I would have control  of both
frames and I would be able to manipulate them with the help of the 3rd-party
code.  osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't
able to do the trick since I've found no way to access the FBO OSG utilizes.
Therefore I've tried my own implementation (currently on a single display)
with the following setup and the given result in the post before (take a
look at the attached picture).

The current implementation is very similiar to the osgprerender example
(stereo is not enabled) except that I'm creating my own FBO in a
preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and
is used as the rendertarget for the first (left) (RTT-)camera.
RenderTargetImplementation for this camera has not been explicitly set. The
texture is attached to a rectangular geometry, which is itself a child of
the osgViewers camera. Unfortunately the result of the RTT looks like the
attached image. The image was saved in the postDrawCallback. I'm pretty sure
I've messed something up or missed something. RTT with OSGs FBO works fine
and I've looked at the code but I didn't find anything.

Does someone have an idea? Or maybe another way to implement
checkerboard-stereo? It looks like some faces get culled away. If its useful
I'll post some code.

@Robert: I'm not using osgUtils low level stereo right now but I guess some
of the code would later be useful to get the correct left and right
camera-position-setup.

Nice greetings and thanks for any help or hint!
Mathias Buhr

P.S.: I was already able to do the distortion with that implementation (with
blitting the FBO-image back to the window-system provided FB to get the 3rd
party stuff working).



Am 04.08.09 19:14, schrieb Robert Osfield:


Hi Mathias,

You don't really provide enough info about your overall viewer setup
to give a direct answer.  It sounds like you are using the OSG's low
level stereo support in osgUtil and combining this with a 3rd party
code that does distortion correction or similar.  Doing low level
stereo and distortion correction is really going to work visually even
if you got it to work code wise, as the low level stereo support in
osgUtil assumes a flat display.

Have a bash at explaining what your system is trying to do at a high
level and then others will have a better chance of suggesting how to
go about it.

Robert.

On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhrwrote:



Hi,

before going into the details of the problem, I'd like to explain what
I'm
trying to do and what I have done until now.
I have a 3rd-party function/method which is out of my scope. It seems to
read and write the window-system provided framebuffer and
manipulates/distorts the image. The first implementation was through
calling
this function in a postdraw-callback. Everything works fine this way.
Unfortunately this is not possible if the CHECKBOARD flag is set because
the
postdraw-callback is called after the complete frame (including the
stenceling for th

Re: [osg-users] OSG and shaders

[Ulrich Hertlein]

On 5/08/09 11:41 AM, Maxime BOUCHER wrote:

@btrall:
  Where do you find this ShaderGen? I found it neither in the classlist nor the 
osg examples.


It could be that it's not part of 2.8 but in trunk it's in:
src/osgUtil/ShaderGen.cpp
include/osgUtil/ShaderGen
examples/osgshadergen/osgshadergen.cpp

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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

[Robert Osfield]

Hi Tanguy,

On Wed, Aug 5, 2009 at 12:55 PM, Tanguy
Fautre wrote:
> To come back to the deadlock issue, I don't think there is any way to fix it 
> without breaking the current OSG API compatibility. While I would favour 
> removing the singletons (and would heavily suggest other designs for OSG 
> 3.0), I perfectly understand and agree with you that such an approach is 
> unacceptable in the short term.

Um... I have yet to see a compelling reason for not using singletons
like Registry or a decent proposal for a replacement.   For OSG-3.0 my
plan is to focus on refactoring just the core scene graph and how
rendering is implemented, for the rest of the API changes we should
keep as minimal as possible to try and reduce to headache of porting
from OSG-2.x to OSG-3.x.  We can't avoid refactoring the core scene
graph state management to be able to do shader composition, but the
rest of changes we minimize.

> The least disruptive solution I can think of (while being quite robust) would 
> be to introduce an initOsg() and a destroyOsg() function. It's a fairly 
> common approach and is in fact the one mandated by MSDN regarding the 
> limitations of DllMain (and the deadlocks that may follow if violated).

My gut reaction is YUK.   Design wise, implementation wise and support
wise I know it's a hack.


> initOsg() would initialize and construct all the global variables of Osg when 
> called, while destroyOsg() would take care of the destruction of such objects.

OK. So this uber initOsg() method would need to initialize all global
variables and hence know about all global variance and hence be
tightly coupled with all global variables.  Now if you have a very
simply set of libs to work with, and everything is fixed in it's
relationship this might work, but... if you have a loosely coupled
design that allows you to extend it at runtime what then??  For
instance NodeKits... who inits these?   Do we have explict init's for
each NodeKit the user might use.  What about NodeKits that are pulled
in at runtime to enable the loading of a particular databases?


> The benefits are twofold:
> - The user would have a better control on the lifetime of the OSG and its 
> global variables (among other things, solving the deadlock issue exposed in 
> this discussion).
> - The user would have the ability to reset the library in a predictable 
> manner, which is currently impossible.
>
> A few points should be observed:
> 1. init/destroyOsg needs to be referenced counted (allowing multiple and 
> re-entrant initializations)
> 2. init/destroyOsg needs to be thread-safe
> 3. init/destroyOsg needs to be aware that osg is divided into several 
> components (e.g. osg, osgDB, osgViewer, etc). It would probably be needed 
> that the user can in fact select which components of osg he wants to 
> init/destroy (in which case points 1 and 2 need to be done per component).

OK state all possible benefits and ignore the monstrous downsides such
as tight coupling and blowing out of the water the extensibility that
the OSG is known for.

I sure want to see a good solution to the problems you are seeing but
I won't idly stand by while the OSG is made less easy to use and less
extensible. You go explain to all the thousands of OSG users that
having to re-factor they code for no gain, whilst compromising in
extensibility that just supporting your particular usage pattern.

What we have at hand is very specific issue that occurs when a very
specific set of things are done in a client application, it's not a
general problem that requires a major re-factor.  Careful initiation
at your end may well be the solution.

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

Re: [osg-users] RTT problem - missing faces

[Robert Osfield]

HI Mathias,

Given your setup it's pretty clear that you'd need to not use the OSG
in built stereo support (that is implemented internally using
osgUtil::SceneView), and instead setup up two slave camera sets that
do the render to texture/post render for each eye and in the final
step do the checkboard stereo at the same time.

Robert.

On Wed, Aug 5, 2009 at 12:34 PM, Mathias Buhr wrote:
> Hi Robert,
>
> thank you for your answer.
> I'll try to give some more details on the current setup:
> - multiple physical displays/projectors which overlap to produce a single
> (flat-)screen
> - alignment and blending of the displays is done with the 3rd-party stuff
> - the displays support checkerboard-stereo
>
> In mono-mode my integration of OSG and the 3rd party stuff works perfectly
> and all display do what they are supposed to do. The post-processing is done
> in the camera's postDrawCallback without any magic :) The problem starts
> when I enable OSGs checkerboard-stereo because the image-distortion in the
> postDrawCallback will result in an unusable checkerboard-frame. So basically
> I'm trying to get checkerboard-stereo to work.
> Due to the described problem, I need access to the left and right frames to
> distort them individually. Normally they are "blend together" via stenciling
> in osg::RenderStage::draw(). As far as I know, there is no direct access to
> these frames. I could either implement some kind of callback into OSG or
> implement a variant of checkerboard-stereo myself.
> Currently I'm trying to render both frames individually to an FBO and
> putting them together afterwards. In this case I would have control  of both
> frames and I would be able to manipulate them with the help of the 3rd-party
> code.  osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't
> able to do the trick since I've found no way to access the FBO OSG utilizes.
> Therefore I've tried my own implementation (currently on a single display)
> with the following setup and the given result in the post before (take a
> look at the attached picture).
>
> The current implementation is very similiar to the osgprerender example
> (stereo is not enabled) except that I'm creating my own FBO in a
> preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture and
> is used as the rendertarget for the first (left) (RTT-)camera.
> RenderTargetImplementation for this camera has not been explicitly set. The
> texture is attached to a rectangular geometry, which is itself a child of
> the osgViewers camera. Unfortunately the result of the RTT looks like the
> attached image. The image was saved in the postDrawCallback. I'm pretty sure
> I've messed something up or missed something. RTT with OSGs FBO works fine
> and I've looked at the code but I didn't find anything.
>
> Does someone have an idea? Or maybe another way to implement
> checkerboard-stereo? It looks like some faces get culled away. If its useful
> I'll post some code.
>
> @Robert: I'm not using osgUtils low level stereo right now but I guess some
> of the code would later be useful to get the correct left and right
> camera-position-setup.
>
> Nice greetings and thanks for any help or hint!
> Mathias Buhr
>
> P.S.: I was already able to do the distortion with that implementation (with
> blitting the FBO-image back to the window-system provided FB to get the 3rd
> party stuff working).
>
>
>
> Am 04.08.09 19:14, schrieb Robert Osfield:
>>
>> Hi Mathias,
>>
>> You don't really provide enough info about your overall viewer setup
>> to give a direct answer.  It sounds like you are using the OSG's low
>> level stereo support in osgUtil and combining this with a 3rd party
>> code that does distortion correction or similar.  Doing low level
>> stereo and distortion correction is really going to work visually even
>> if you got it to work code wise, as the low level stereo support in
>> osgUtil assumes a flat display.
>>
>> Have a bash at explaining what your system is trying to do at a high
>> level and then others will have a better chance of suggesting how to
>> go about it.
>>
>> Robert.
>>
>> On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhr  wrote:
>>
>>>
>>> Hi,
>>>
>>> before going into the details of the problem, I'd like to explain what
>>> I'm
>>> trying to do and what I have done until now.
>>> I have a 3rd-party function/method which is out of my scope. It seems to
>>> read and write the window-system provided framebuffer and
>>> manipulates/distorts the image. The first implementation was through
>>> calling
>>> this function in a postdraw-callback. Everything works fine this way.
>>> Unfortunately this is not possible if the CHECKBOARD flag is set because
>>> the
>>> postdraw-callback is called after the complete frame (including the
>>> stenceling for the checkerboard) is rendered. The function would distort
>>> the
>>> checkerboard. Hence, I have to apply this function for each "eye"
>>> separately.
>>> This seems possible with some changes to OSG

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

[Tanguy Fautre]

Hi Robert,

It is indeed a Windows specific issue. If you get the chance to test the 
example on a Windows machine, it would really be appreciated. Aymeric and I 
have spent 3 days tracking, understanding and reproducing the problem. As a 
consequence, a fair amount of detailed technical explanation and MSDN 
references have been posted on this discussion to illustrate it.

It is indeed a problem that requires a specific set of conditions to be 
triggered. It mainly requires a Windows application to be already running 
several threads when loading another dll (in the example, the dll is explicitly 
loaded to easily to reproduce the problem). It is a form of subtle and 
intricate race condition.

We've had that potential race condition in our code for many months, but it was 
not until recently that the we saw that deadlock occurs in a consistent manner. 
Hence, I'm not surprised that nobody reported this issue before.

I apologize if I've appeared too emotional. The fact that the discussion has 
been mixing two points (the deadlock technical details and the singleton design 
critic) is probably not helping.

Although I will not hide what I think about singletons. Just in the last two 
weeks, not counting the deadlock with osg.dll, we've spent quite a long time 
tracking two thread-safety issues in OpenSSL and LibCurl that are actually 
related to the singleton design (for the story, the OpenSSL developers have 
acknowledged it as an API limitation and the LibCurl developers have already 
committed a fix). Hence, it may not be surprising that I appear emotional about 
singletons. My experience leads me to disagree on the statement that singletons 
help in having a loosely coupled design. I think that singletons are actually a 
hidden and tightly coupling design.


To come back to the deadlock issue, I don't think there is any way to fix it 
without breaking the current OSG API compatibility. While I would favour 
removing the singletons (and would heavily suggest other designs for OSG 3.0), 
I perfectly understand and agree with you that such an approach is unacceptable 
in the short term.

The least disruptive solution I can think of (while being quite robust) would 
be to introduce an initOsg() and a destroyOsg() function. It's a fairly common 
approach and is in fact the one mandated by MSDN regarding the limitations of 
DllMain (and the deadlocks that may follow if violated).

initOsg() would initialize and construct all the global variables of Osg when 
called, while destroyOsg() would take care of the destruction of such objects.

The benefits are twofold:
- The user would have a better control on the lifetime of the OSG and its 
global variables (among other things, solving the deadlock issue exposed in 
this discussion).
- The user would have the ability to reset the library in a predictable manner, 
which is currently impossible.

A few points should be observed:
1. init/destroyOsg needs to be referenced counted (allowing multiple and 
re-entrant initializations)
2. init/destroyOsg needs to be thread-safe
3. init/destroyOsg needs to be aware that osg is divided into several 
components (e.g. osg, osgDB, osgViewer, etc). It would probably be needed that 
the user can in fact select which components of osg he wants to init/destroy 
(in which case points 1 and 2 need to be done per component).


Regards,

Tanguy



-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: 05 August 2009 08:56
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Tanguy,

I don't have a windows box to test against so can't do anything first
hand.  It does very much sound like Windows threading issue that will
require a specific Windows mechanism in your application set up to
avoid hitting these problems.  I don't what what the solution might
be, but perhaps it would require serialization of all system calls
like getenv.

The solution will not be ditching singletons.  They are extremely
useful to design and implementation of the OSG. You simply can't
replace them without major surgery of API and implementation, and even
if you did you'd loose significant flexibility and function -
something which is currently loosely coupled (yes a great OO asset)
would end up be far more tightly coupled than it is now.

Please remember that the OSG is used heavily by thousands of
developers on thousands of applications across dozens of platforms,
with many applications which are heavily threaded - and it's been
under decades development without this issue cause problems.  The
problems you are seeing are serious, but they aren't the norm, it's
because of your particular application usage model and platform.   I'm
certainly open to finding an OSG solution, but it'll have to be
unobtrusive and require minimal code and API changes, otherwise it
simply won't be merged as the cost and ris

Re: [osg-users] RTT problem - missing faces

[Mathias Buhr]

Hi Robert,

thank you for your answer.
I'll try to give some more details on the current setup:
- multiple physical displays/projectors which overlap to produce a 
single (flat-)screen

- alignment and blending of the displays is done with the 3rd-party stuff
- the displays support checkerboard-stereo

In mono-mode my integration of OSG and the 3rd party stuff works 
perfectly and all display do what they are supposed to do. The 
post-processing is done in the camera's postDrawCallback without any 
magic :) The problem starts when I enable OSGs checkerboard-stereo 
because the image-distortion in the postDrawCallback will result in an 
unusable checkerboard-frame. So basically I'm trying to get 
checkerboard-stereo to work.
Due to the described problem, I need access to the left and right frames 
to distort them individually. Normally they are "blend together" via 
stenciling in osg::RenderStage::draw(). As far as I know, there is no 
direct access to these frames. I could either implement some kind of 
callback into OSG or implement a variant of checkerboard-stereo myself.
Currently I'm trying to render both frames individually to an FBO and 
putting them together afterwards. In this case I would have control  of 
both frames and I would be able to manipulate them with the help of the 
3rd-party code.  
osg::Camera::RenderTargetImplementation::FRAME_BUFFER_OBJECT wasn't able 
to do the trick since I've found no way to access the FBO OSG utilizes. 
Therefore I've tried my own implementation (currently on a single 
display) with the following setup and the given result in the post 
before (take a look at the attached picture).


The current implementation is very similiar to the osgprerender example 
(stereo is not enabled) except that I'm creating my own FBO in a 
preDrawCallback of the PRE_RENDER cam. This FBO has an attached texture 
and is used as the rendertarget for the first (left) (RTT-)camera. 
RenderTargetImplementation for this camera has not been explicitly set. 
The texture is attached to a rectangular geometry, which is itself a 
child of the osgViewers camera. Unfortunately the result of the RTT 
looks like the attached image. The image was saved in the 
postDrawCallback. I'm pretty sure I've messed something up or missed 
something. RTT with OSGs FBO works fine and I've looked at the code but 
I didn't find anything.


Does someone have an idea? Or maybe another way to implement 
checkerboard-stereo? It looks like some faces get culled away. If its 
useful I'll post some code.


@Robert: I'm not using osgUtils low level stereo right now but I guess 
some of the code would later be useful to get the correct left and right 
camera-position-setup.


Nice greetings and thanks for any help or hint!
Mathias Buhr

P.S.: I was already able to do the distortion with that implementation 
(with blitting the FBO-image back to the window-system provided FB to 
get the 3rd party stuff working).




Am 04.08.09 19:14, schrieb Robert Osfield:

Hi Mathias,

You don't really provide enough info about your overall viewer setup
to give a direct answer.  It sounds like you are using the OSG's low
level stereo support in osgUtil and combining this with a 3rd party
code that does distortion correction or similar.  Doing low level
stereo and distortion correction is really going to work visually even
if you got it to work code wise, as the low level stereo support in
osgUtil assumes a flat display.

Have a bash at explaining what your system is trying to do at a high
level and then others will have a better chance of suggesting how to
go about it.

Robert.

On Tue, Aug 4, 2009 at 4:10 PM, Mathias Buhr  wrote:
   

Hi,

before going into the details of the problem, I'd like to explain what I'm
trying to do and what I have done until now.
I have a 3rd-party function/method which is out of my scope. It seems to
read and write the window-system provided framebuffer and
manipulates/distorts the image. The first implementation was through calling
this function in a postdraw-callback. Everything works fine this way.
Unfortunately this is not possible if the CHECKBOARD flag is set because the
postdraw-callback is called after the complete frame (including the
stenceling for the checkerboard) is rendered. The function would distort the
checkerboard. Hence, I have to apply this function for each "eye"
separately.
This seems possible with some changes to OSG itself but it also would break
the possibilty to upgrade later.  So I decided to take another approach:

I've tried rendering to an FBO (RTT, similar to osgprerender) but I can't
apply the function anymore in the postdraw-callback (gives GL errors). Since
there is no access to the OSG-managed FBO (for bliting from FBO to FB) I
have implemented my own and rendered to that instead. I'll give you a brief
overview for that:

MainCamera
- addChild(QUAD_STRIP)//an osg:Geode with an
osg::Texture2D
- addChild(LeftCamera)
- PreDrawCallback:

Re: [osg-users] Feature request for 2.9: please include swig bindings in main release

[Joe Kilner]

A couple of points:

Firstly it is possible to inject C++ code in to Python quite easily using 
scipy.weave. And using a cast in the C++ and the ".this" member in the Python 
swig wrappers makes marshaling data between the two quite easy.

So you can write code like this:


Code:


v = mesh.vertices
f = mesh.faces.flatten()
tri_geometry = osg.Geometry()
verts = osg.Vec3Array()
faces = osg.DrawElementsUInt(osg.PrimitiveSet.TRIANGLES,0)
# Fix for problems with vectors, but also _much_ faster
pVerts = int(verts.this)
pFaces = int(faces.this)
mesh2osgCode = """
osg::Vec3Array *verts = (osg::Vec3Array *)pVerts;
osg::DrawElementsUInt *faces = (osg::DrawElementsUInt *)pFaces;

//Set up vertex array
verts->reserve(v_array->dimensions[0]);
int v_s0 = v_array->strides[0] / sizeof(double);
int v_s1 = v_array->strides[1] / sizeof(double);
double *begin = v;
double *end = v + (v_array->dimensions[0] * v_s0);
for (double *p = begin; p < end ;p += v_s0) {
double a = *p;
double b = *(p + v_s1);
double c = *(p + v_s1 + v_s1);
verts->push_back( osg::Vec3(a,b,c) );
}

//Set up faces
faces->reserve(f_array->dimensions[0]);
int f_s0 = f_array->strides[0] / sizeof(long int);
long int *f_begin = f;
long int *f_end = f + (f_array->dimensions[0] * f_s0);
for (long int *p = f_begin; p < f_end ;p += f_s0) {
faces->push_back( *p );
}
"""

scipy.weave.inline(mesh2osgCode,["v","f","pVerts", 
"pFaces"],headers=[""],libraries=["osg"],include_dirs=["/home/joe/include"],
 library_dirs=["/home/joe/lib"])
tri_geometry.setVertexArray(verts)
tri_geometry.addPrimitiveSet(faces)




This example is a little complex as it is reading data from the numpy array 
data structure, but it has the benefit of (a) working and (b) being much faster 
than trying to move all that data around in pure Python.

Secondly, I've been reading up on SWIG but not had time to play around with 
things yet. I was thinking that SWIG runs in two passes - the first one parses 
the code to work out what to wrap, the second pass compiles code to make the 
wrappers. What we want to do is to tell SWIG that MixinVectors are std::vectors 
during that first phase, but let it compile against the correct code in the 
second phase. Will this work? Might it be as simple as adding:


Code:

#ifdef SWIG
#define MixinVector std::vector
#endif




I'll have a play around later, but there are maybe some other ways to do this 
based on the fact that we don't need SWIG to build against std::vector, we just 
need it to parse MixinVector as if it was a std::vector. Well, I think that's 
what is needed, I'm only just starting to look at this so I might be completely 
wrong.

Of course a helper function to convert between osg::Arrays and numpy.arrays 
would be much more useful to me in practice... 

Cheers,
Joe

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





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

Re: [osg-users] Using GLObjectsVisitor with DrawThreadPerContext

[Robert Osfield]

Hi Tugkan,

I don't know offhand why it's crashing, but in svn/trunk there is now
a helper class for incrementally compiling OpenGL objects prior to
merging with the scene graph to help prevent frame drops.  The class
is osgUtil::IncrementalCompileOperation, and this can be assigned to
the Viewer/CompositeViewer using:

/** Set the incremental compile operation.
  * Used to manage the OpenGL object compilation and merging
of subgraphs in a way that avoids overloading
  * the rendering of frame with too many new objects in one frame. */
void 
setIncrementalCompileOperation(osgUtil::IncrementalCompileOperation*
ico);


Robert.

On Wed, Aug 5, 2009 at 10:48 AM, Tugkan Calapoglu wrote:
> Hi,
>
> In our application we create new objects in runtime. Most of the time newly
> created objects are not in frustum in the beginning hence they do not result
> in a stutter But, when the object comes into the frustum texture download
> and display list creation results in stutters.
>
> It is acceptable for us to have stutter when the object is created so
> whenever we create an object we use GLObjectVisitor to compile GL objects.
> We do this in a FinalDrawCallback. The problem we are facing is that this
> results in crashes. The crash is very rare. Sometimes more than an hour
> passes with hundreds of objects created and destroyed. There are some
> computers; however, where the problem is far more frequent. The difference
> of these computers is that they have Quaddro cards and more powerful CPU's.
>
> Our application uses DrawThreadPerContext and all test computers have at
>  least two CPU's. When we run in SingleThreaded mode we do not see any
> problems. So the question is whether it is safe to use GLObjectsVisitor in a
> FinalDrawCallback? If not, how should it be used?
>
>
> General info:
> OS: Suse 10.3
> CPU: Several different CPU's (at least two CPU)
> Graphics : Several different NVidia cards
> OSG: 2.9.5 (SVN version 10258)
>
>
> Tugkan
> ___
> 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] Using GLObjectsVisitor with DrawThreadPerContext

[Tugkan Calapoglu]

Hi,

In our application we create new objects in runtime. Most of the time 
newly created objects are not in frustum in the beginning hence they do 
not result in a stutter But, when the object comes into the frustum 
texture download and display list creation results in stutters.


It is acceptable for us to have stutter when the object is created so 
whenever we create an object we use GLObjectVisitor to compile GL 
objects. We do this in a FinalDrawCallback. The problem we are facing is 
that this results in crashes. The crash is very rare. Sometimes more 
than an hour passes with hundreds of objects created and destroyed. 
There are some computers; however, where the problem is far more 
frequent. The difference of these computers is that they have Quaddro 
cards and more powerful CPU's.


Our application uses DrawThreadPerContext and all test computers have at 
 least two CPU's. When we run in SingleThreaded mode we do not see any 
problems. So the question is whether it is safe to use GLObjectsVisitor 
in a FinalDrawCallback? If not, how should it be used?



General info:
OS: Suse 10.3
CPU: Several different CPU's (at least two CPU)
Graphics : Several different NVidia cards
OSG: 2.9.5 (SVN version 10258)


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

Re: [osg-users] how to draw a Curved Surface on the top of terrain?

[John Vidar Larring]

Hi Jason,

Last time I checked (half a year ago), osggis did no create a "curved 
polygon" when creating a filled polygon for e.g. Russia. Since no 
sampling points are created inside the polygon the tessellated triangles 
goes straight from one edge to the other thought the ground.


It would be great news if this has been fixed i later versions of 
osggis! Please let me know.


// John

Jason Beverage wrote:

Hi Lipan,

You could look into using projected textures with the 
osgSim::OverlayNode or if you are rendering vector data such as that 
from an ESRI shapefile I'd recommend looking at osggis at 
http://www.osggis.org.


Jason

On Mon, Aug 3, 2009 at 7:15 AM, Pan Li > wrote:


Hi,

1、how to draw a Curved Surface on the top of terrain? like the fig1.
2、how to compute the surface area of the Curved Surface?
any examples??
thanks a lot!!

Cheers,
lipan

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




___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



--
This message has been scanned for viruses and
dangerous content by *MailScanner* , and is
believed to be clean.




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



--
Best regards,
John
WeatherOne

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

Re: [osg-users] OSG and shaders

[Maxime BOUCHER]

Hi,

@btrall:
 Where do you find this ShaderGen? I found it neither in the classlist nor the 
osg examples.

@carnibirdy:
Rewritting the lights effects and texture mapping in the shader is quite easy.
You can find implementation examples here (http://www.typhoonlabs.com/), in the 
"OpenGL Shading Language Course" part or here 
(http://www-evasion.imag.fr/Membres/Sebastien.Barbier/Enseignement/tp_glsl.zip) 
for several shaders, including a phong lighting.
For the texture mapping see this post 
(http://forum.openscenegraph.org/viewtopic.php?t=3293).


Have fun!

Cheers,
Maxime

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





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

Re: [osg-users] FBOs without color or depth attachments /DrawBuffer / ReadBuffer

[Wojciech Lewandowski]

Robert,

Thanks for the quick answers.

[..]

> Do you approve such a plan of extending CullSettings masks for use with
> DrawBuffer and ReadBuffer ?



I think this would be appropriate - i.e. to extend CullSettings to
default to inheriting the _readBuffer and _drawBuffer values, and on
setting change this inheritance mask to allow the variable to be used.
 Other members of CullSettings work this way so look at these for a
template.


Thats what I plan to do. I picked up Camera::_clearColor handling example 
for the same purpose.



[..]

>
> Which option do You prefer here ?



I don't prefer either



I wonder if a has been applied flags could be used in osg::State to
accompany the _drawBuffer and _readBuffer member variables, and if the
variables haven't yet been applied to OpenGL the previous value is
ignored and the gl calls are made regardless of whether previous value
held in osg::State. This way the default effectively doesn't existing
and the calling code will always set it.


I agree, it seems the best option. Using existing framework like 
haveAppliedAttribute would mean that we want to make DrawBuffer/ReadBuffer 
an attribute. I am not sure if this is what you are after ? To some degree 
it makes sense, I can imagine that someone may want to add such state in 
StateSet to turn off DrawBuffer to draw to depthBuffer only.


But on the other hand I have the feeling that image/texture read may be 
vulnerable to unexpected readBuffer changes. So maybe it wil be better to 
not make DrawBuffer/ReadBuffer attributes but treat them independently like 
I propesed earlier + add extra flags bool: _drawBufferValid, 
_readBufferValid  and corresponding logic and methods to make sure that 
first setDrawBuffer/setReadBuffer is always apllied.


This is an example how osg::State::setDrawBuffer method would look in this 
scenario:


void osg::State::setDrawBuffer( GLenum  bufferMode )
{
   if( !_drawBufferValid || _drawBuffer != bufferMode )
   {
   glDrawBuffer( bufferMode )
   _drawBuffer = bufferMode;
   _drawBufferValid = true;
   }
}

If you accept that, I am rolling up my sleeves and start work ;-)

Wojtek
___
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] osg on iPhone / iPod touch with OpenGL ES 1.1

[Adrian Egli OpenSceneGraph (3D)]

Hi All,

Just for your information :

http://www.computamaps.com/assets/press/iphone.htm

regards
adrian

2009/7/17 Robert Osfield 

> Hi Marco,
>
> No OpenGL ES 1.x code has been checked in yet, but there have been
> successful trail ports to OpenGL ES 1.x.  Next week I'll just so
> happen to be with a client interested in this side of work, although
> not related to the iFamilyOfProducts, so hopefully we'll be able to
> come up with clearer strategy for getting OpenGL ES 1.x support
> integrated into the core OSG.
>
> The likely approach will be to initially start with a branch in our
> svn repository for the port to OpenGL ES, and then have me refactor
> svn/trunk to step by step pull in the changes till we have svn/trunk
> compatible with OpenGL ES 1.x and then later with openGL ES 2.x.
>
> The time frame is difficult to pinpoint right now as it depends on
> various different groups coordinating work as well just how quickly
> the technical challenges are surmounted.  I would hope that we could
> see a OpenSceneGraph-2.12 release (the next stable release after the
> imminent OSG-2.10 release) with OpenGL ES 1.x support this autumn.
>
> Cheers,
> Robert.
>
> On Thu, Jul 16, 2009 at 5:28 PM, Marco Lohse wrote:
> > Since this is my first post: First of all, thank you for osg!
> >
> > We would be interested in a OpenGL ES 1.1 version for running our osg
> based applications on iPhone / iPod touch using Open GL ES 1.1
> >
> > I found some references saying that there will be support for this
> platform. Now, I would like to know what the current status is, what still
> needs to be done, etc. I would also be interested in knowing the current
> status and plans for Open GL ES 2.0 (for the latest iPhone versions).
> >
> > We are willing to help with beta-testing, and - depending on the current
> status - also to do some coding.
> >
> > I would appreciate your comments
> >
> > Thank you! Marco
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=15037#15037
> >
> >
> >
> >
> >
> > ___
> > 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

Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator

[Robert Osfield]

Hi Andrew,

On Wed, Aug 5, 2009 at 9:35 AM, Andrew
Burnett-Thompson wrote:
> I noticed osg::Camera offers more direct access to the view/projection than
> the camera manipulator (which only affects the View), so I've dumped camera
> manipulator and created two cameras - perspective / plan.

Yes this would be doable, although having two separate views in
CompositeViewer might be more logical an easier to manage.

> Then I am directly updating the camera in the perspective/plan mode from my
> own event handling code. (In addition I need multiple other cameras that I
> can position around the scene in perspective mode and switch to on various
> key presses).
>
> One problem - I am trying to swap the cameras in/out of the osg::Viewer so I
> was using osg::Viewer::setCamera and getCamera to get/set the default
> camera, however it is not behaving as expected.

What problem are you seeing?  Using the
viewer.getCamera()->set..MatrixAs..(..) methods work fine, but if you
need to make sure that you aren't also attaching a CameraManipulator
as this will overwrite your values on each frame.

> Is this the right way to set the default camera?

Just use the Camera that is already assigned to the Viewer.

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

Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator

[Andrew Burnett-Thompson]

Hi Robert,

Thanks for your reply. Yes I realise the problems inherent in making an
orthogonal view behave like a perspective view.

What I'm trying to do however is create a plan view on a CAD like
application for oil rigs. So imagine in perspective view you can move around
the rig, in plan view you want to see it top down, everything's in
wireframe, sort of like a blueprint.

I need the ability to zoom in the plan view, but not rotate or move
forwards/backwards, literally just pan/zoom.

I noticed osg::Camera offers more direct access to the view/projection than
the camera manipulator (which only affects the View), so I've dumped camera
manipulator and created two cameras - perspective / plan.

Then I am directly updating the camera in the perspective/plan mode from my
own event handling code. (In addition I need multiple other cameras that I
can position around the scene in perspective mode and switch to on various
key presses).

One problem - I am trying to swap the cameras in/out of the osg::Viewer so I
was using osg::Viewer::setCamera and getCamera to get/set the default
camera, however it is not behaving as expected.

Is this the right way to set the default camera?

I just one one to render at a time, not to composite the view. If I sort the
orthogonal code (Plan view) I'll post it here for reference purposes.

Thank you,
Andrew


On Wed, Aug 5, 2009 at 8:23 AM, Robert Osfield wrote:

> Hi Andrew,
>
> I would not recommend trying to make an orthographic view behave like
> a perspective view, it simple doesn't work (this is not an OSG issue,
> but the basic principles involved.)  I've written about this before so
> I won't waste my key presses have a look through the archives.
>
> The upshot is I would suggest keeping orthographic views for fixed
> maps/side/front views, or very constrained user interaction models.
> If you try to make a orthographic behave like a perspective you'll
> just waste lots of time.
>
> Robert.
>
> On Thu, Jul 30, 2009 at 6:22 PM, Andrew Thompson
> wrote:
> > Hi there,
> >
> > I am using a custom CameraManipulator class (inheriting
> osgGA::MatrixManipulator) which is added to my scene after the
> OpenSceneGraph is initialised
> >
> > The CameraManipulator has two member variables I've added, a Vec3d target
> and position. These are used to create a projection matrix by calling
> Matrix::makeLookAt. As the events are handled by the manipulator, I am
> updating the position/target and recomputing the matrix, then on Frame I am
> returning the constructed matrix.
> >
> > This provides a great perspective view, however I cannot work out how to
> construct an orthogonal projection using a target/position.
> >
> > In addition, I'd like to be able to change the Field Of View when I
> create the matrix.
> >
> > I realise there is a Matrix::makeOrtho and Matrix::makePerspective,
> however I'm not sure how to use these with my CameraLocation/Target
> variables.
> >
> > Could anyone offer me some advice?
> >
> > Thank you!
> > Andrew
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=15659#15659
> >
> >
> >
> >
> >
> > ___
> > 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] Dashboard error

[Robert Osfield]

Hi Sukender,

Are you still seeing these problems?

Robert.

On Tue, Aug 4, 2009 at 8:36 AM,  wrote:
> Hi Jose-Luis et al
>
> Either the dashboard does not respond, or I get the folowing error:
>
> no handler found
> Warning: error_log(backup/cdash.log) [function.error-log]: failed to open 
> stream: Permission denied in /home/www/cdash_OSG/cdash/common.php on line 192
>
> Hope it helps :)
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
> ___
> 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] FBOs without color or depth attachments / DrawBuffer / ReadBuffer

[Robert Osfield]

Hi Wojtek,

Comments interspersed below.

On Tue, Aug 4, 2009 at 11:47 PM, Wojciech
Lewandowski wrote:
>
> (1)  We agreed that we may now remove the code forcing attachment of
> color/depth buffers to FBO when user had not attached such buffer. To relax
> FBO requirements its neeccessary to refactor DrawBuffer/ReadBuffer
> management. Specifically, we need to allow for explicit setting of GL_NONE
> for DrawBuffer & ReadBuffer. Current implementation does use GL_NONE flag
> but interprets it more like "INHERIT BUFFER SETTING FROM PARENT" value. In
> practice glDrawBuffer( GL_NONE ) and glReadBuffer( GL_NONE ) is not called
> by OSG.
>
> (2)  We also agreed that it would be nice if we could add
> setDrawBuffer/setReadBuffer methods to State and change buffers in 'lazy
> update' manner.
>
> I promised I would try to come up with solution and post a submission
> implementing above proposals. I considered couple options and decided that
> best approach to implementing (1) would be adding DRAW_BUFFER / READ_BUFFER
> to CullSettings::VariablesMask flags. As we are going to allow for GL_NONE
> buffers in their verbatim meaning, we need to specifcally define methods to
> allow cameras inherit or override buffer settings from their parents. I
> think it will be appropriate to handle this in similar way
> Camera::_clearColor is handled. CullSettings::CLEAR_COLOR mask defines
> whether ClearColor is inherited or overriden. CullSettings::DRAW_BUFFER and
> CullSettings::READ_BUFFER could be introduced and interpreted in the same
> way with Camera::_drawBuffer, Camera::_readBuffer variables.
>
> Do you approve such a plan of extending CullSettings masks for use with
> DrawBuffer and ReadBuffer ?

I think this would be appropriate - i.e. to extend CullSettings to
default to inheriting the _readBuffer and _drawBuffer values, and on
setting change this inheritance mask to allow the variable to be used.
  Other members of CullSettings work this way so look at these for a
template.


> I also have a decision problem with feature (2): I wanted to add following
> osg::State methods and variables
>
> State::_drawBuffer
> void State::setDrawBuffer( GLuint )
> GLuint State::getDrawBuffer( void )
>
> State::_readBuffer
> void State::setReadBuffer( GLuint )
> GLuint State::getReadBuffer( void )
>
> Difficulty here is related to proper setting of default values of
> State::_readBuffer and State::_drawBuffer. OpenGL spec says that defaults
> depend on context. They are set to GL_BACK for double buffered contexts and
> set to GL_FRONT for single buffered contexts. When State is created its not
> yet known with which context it would be used.
>
> I came up with 2 possible solutions:
>
> (A) Changing State::_drawBuffer/_readBuffer defaults after associating State
> with GraphicsContext. This is usually done in GraphicsWindow(or its
> subclass)::init virtual method. This method would have to call
> state->setDrawBuffer/setReadBuffer to initialize defaults properly.
> Drawbacks:
> - many classes deriving from GraphicsWindow - many changes need to be done.
> - not sure what defaults should be applied for SharedContexts and external
> contexts for windows created by the users.
> - I am hesitant to modify all GraphicsWindow subclasses::init because I am
> mainly Windows progrmammer. I'am afraid I may break something in Linux or
> MacOS.
>
> (B) Read buffer defaults ( glGet(GL_DRAW_BUFFER) ) set in GL Context when
> State sees context for the first time. Good place for this would be
> State::initializeExtensionProcs method.
> Drawbacks:
> - initializeExtensionProcs is mainly used for setting OpenGL context / State
> capability variables like number of texture stages etc. Setting
> DrawBuffer/ReadBuffer defaults would be (dangerous?) precedence of
> StateAttributes/StateModes like initialization.
>
> Which option do You prefer here ?

I don't prefer either

I wonder if a has been applied flags could be used in osg::State to
accompany the _drawBuffer and _readBuffer member variables, and if the
variables haven't yet been applied to OpenGL the previous value is
ignored and the gl calls are made regardless of whether previous value
held in osg::State. This way the default effectively doesn't existing
and the calling code will always set it.

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

Re: [osg-users] Registry object cache observations / questions

[Robert Osfield]

Hi Tim,

On Tue, Aug 4, 2009 at 9:31 PM, Tim Moore wrote:
> It's not critical as far as we're concerned.

OK, I'll patch the OSG-2.8 branch but not worry too much about a
2.8.3.  If we later need a 2.8.3 for other reasons then it could
rolled into this.

I've made most of the changes to svn/trunk to move the flush of the
cache into osgViewer::Viewer/CompositeViewer rather than
osgDB::DatabasePager.   This actually cleans things up w.r.t a
CompositeViewer, as with multiple scene's the object cache will have
been clear multiple times per frame, and also fixes the general case
of where no DatabasePager is assigned but the object cache is used.

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

Re: [osg-users] Feature request for 2.9: please include swig bindings in main release

[Robert Osfield]

Hi Guys,

For 2.9.x we a not far away from a feature freeze so adding lots of
extra code is not appropriate.

Longer term I'd love to see us properly solve the issues of language
wrappers and introspection for the OSG in a way that is easy to
maintain for all involved.  What form this might take I don't know.
My original hope was that osgIntrospection would be the basis of
solving these problems, but alas this hasn't picked up the usage out
in the community.   I believe it would be inappropriate to have two
different schemes for wrapping though, so if we introduce a new scheme
it'll need solve be fit to replace osgIntrospection's place in the
core OSG, rather than just add another scheme that runs in a parallel.

W.r.t MixinVector, have a look at the svn logs from include/osg/Array
to see the author and details of why the changes we required.  The
quick answer is that in C++ you need a virtual destructor to do
inheritance, but std::vector<> doesn't have one, so the results on
inheriting from it are undefined and can lead to memory leaks.

Robert.

On Tue, Aug 4, 2009 at 3:46 PM, Gerwin de Haan wrote:
> Hi Luigi, Frank and others,
>
> FYI I am currently using osgswig with a "patched" osg 2.9.5. This patch
> consists of reverting the MixinVector stuff from osg 2.6+ with the standard
> std:vector alternative in osg 2.4 so osgswig can wrap the VecArrays again. I
> have tried this only on linux, and I'm not sure if I break anything in osg
> itself by messin' up MixinVector.
>
> Luigi, I am interested in your modifications, could you send them to me so I
> can integrate them?
>
> First thing would be to make a list of things that are wrapped or are
> ignored. I started working in that direction by using a wrapped version of
> osgIntrospection to inspect what's available in the osg libraries and
> plugins. Adding unit tests for basic instantiation would be a bonus.
>
> As far as automation of the process goes, I'm keen to see what the
> techniques from the new wrapITK could bring us.
> (http://code.google.com/p/wrapitk/) My colleagues tell me ITK is bigger a
> beast than osg, an heavy on STL templates and nested classes, but that their
> Python/Java wrappings are impressive.
>
> As far as (potential) users go, please mail me your name,
> company/institution and a use case so I can update "the list"
> (http://code.google.com/p/osgswig/wiki/UsingOsgswig). Hopefully we can
> convince others (e.g. bosses, colleagues) that working on and working with
> osgswig is useful.
>
> regards,
> Gerwin
>
>
> On Tue, Aug 4, 2009 at 4:15 PM, Frank Midgley 
> wrote:
>>
>> On Aug 4, 2009, at 7:55 AM, Luigi Calori wrote:
>>
>>> I'm unwilling to update as each time I update osg... there are some
>>> problems with swig wrapping.
>>> One of the worst issues has been the  MixinVector  that has broken all
>>> the vecArrays wrapping thus preventing python construction of geometry.
>>> I do not know weather Robert is aware of the hassle this mod has caused
>>> to osgswig users.
>>
>>
>> I'm still running against OSG 2.6 but was finally able to construct custom
>> geometry via Python with code similar to the following:
>>
>> def vectorArrayFromList(vectorList):
>>    from ctypes import *
>>    vectorArray = osg.Vec3Array(len(vectorList))
>>    arrayPointer =
>> pointer(c_float.from_address(int(vectorArray.getDataPointer(
>>    vectorSize = vectorArray.getDataSize()
>>    offset = 0
>>    for vector in vectorList:
>>        for dim in range(3):
>>            arrayPointer[offset + dim] = vector[dim]
>>        offset += vectorSize
>>    return vectorArray
>>
>> The vectorList argument should be a list of tuples to stick into the
>> array, e.g. [(1.0, 2.0, 3.0), (4.0, 5.0, 6.0)].  The trick is to take
>> advantage of the Vec3Array constructor that takes just a length argument.
>>  You get a vector full of (0.0, 0.0, 0.0) values which you can then replace
>> with real data via ctypes.  I adapted this from Randolph Fritz's post to
>> osg-users
>> ().
>>
>> You can do the same thing for primitive sets:
>>
>> def primitiveSetFromList(primitiveType, vertexIndexList):
>>    from ctypes import *
>>    primitiveSet = osg.DrawElementsUInt(primitiveType,
>> len(vertexIndexList))
>>    arrayPointer =
>> pointer(c_uint.from_address(int(primitiveSet.getDataPointer(
>>    offset = 0
>>    for vertex in vertexIndexList:
>>        arrayPointer[offset] = vertex
>>        offset += 1
>>    return primitiveSet
>>
>> I haven't done massive testing but it's working fine so far on both Mac OS
>> X and Win XP…
>>
>> -Frank
>>
>> 
>> Frank Midgley
>> HHMI JFRC - Scientific Computing
>> midgl...@janelia.hhmi.org
>> (571) 209-4629
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> _

Re: [osg-users] OpenSceneGraph-2.8.2 released

[Robert Osfield]

Hi Sukender,

Thanks for uploading these.  Are they all ready to upload?

Could you provide the md5sum's and sizes of these files so I can
verify they have been uploaded OK?

Cheers,
Robert.

On Tue, Aug 4, 2009 at 10:11 AM, Sukender wrote:
> Hi Robert,
>
> As expected, I did a mistake when building two VC9 packages (documentation 
> was missing in packages named "all" because I forgot to generate the doc 
> before). Sorry.
> Please use openscenegraph-all-2.8.2-win32-x86-vc90-Debug(2).zip and 
> openscenegraph-all-2.8.2-win32-x86-vc90-Release(2).zip (instead of the 
> "without (2)" ones). Same thing for 
> openscenegraph-all-2.8.2-win32-x86-vc80sp1-Release(2).zip as told in my 
> previous mail.
> Upload should be complete in less that 30 min.
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
> - Mail d'origine -
> De: Sukender 
> À: OpenSceneGraph Users 
> Envoyé: Tue, 4 Aug 2009 07:41:21 +0200 (CEST)
> Objet: Re: [osg-users] OpenSceneGraph-2.8.2 released
>
> Hi Robert, hi Jose-Luis, hi all,
>
> I'm uploading VC8sp1 binaries for 2.8.2, as for VC9sp1. However, You'll have 
> to delete "openscenegraph-all-2.8.2-win32-x86-vc80sp1-Release.zip" (which was 
> truncated beacause of a transfer termination) and use/rename 
> "openscenegraph-all-2.8.2-win32-x86-vc80sp1-Release(2).zip" instead.
>
> BTW, Jose-Luis and Robert, may packages maintainers have a full read/write 
> access to a specific FTP folder, such as one with their name? That would 
> avoid such things, as I could have replaced the truncated file. (And I have 
> to check something on VC9 binaries I uploaded ; I just hope all went right or 
> I'll have to upload renamed files again!)
>
> And a final question: should the site have a link (or text reference) to 
> download a "doc" package on the wiki/Support page? Something like this:
> "Reference Guides - online reference for OpenSceneGraph API's. Offline 
> documentation may be downloaded from one of the precompiled binaries set on 
> the download page."
>
> Cheers,
>
> --
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
>
> Le Mon, 03 Aug 2009 16:51:57 +0200,  a écrit:
>
>> Hi Robert, hi all,
>>
>> Uploading VC9sp1 binaries for 2.8.2 (release & debug - ETA: 3 minutes)... 
>> I'll try to do the same with VC8sp1 tonight or tomorrow.
>> Please tell if anything went wrong.
>> Cheers,
>>
>> PS: I'll certainly become active again on the mailing list from now :)
>>
>> Sukender
>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>>
>> - Mail d'origine -
>> De: Robert Osfield 
>> À: OpenSceneGraph Users 
>> Envoyé: Tue, 28 Jul 2009 08:33:04 +0200 (CEST)
>> Objet: [osg-users] OpenSceneGraph-2.8.2 released
>>
>> Hi All,
>>
>> I'm delighted to announced the 2.8.2 release, the second patch release
>> of the OpenSceneGraph-2.8 series.  We don't have any binaries yet, so
>> I'd appreciate if some gracious souls could pitch in and build the
>> binaries and then upload them to ftp so we can work on getting them
>> uploaded to the downloads page.
>>
>> Many thanks for all your assistance in testing and bug fixing,
>> Robert.
>>
>> --
>>
>> Source code packages can be found on the Downloads page
>> (http://www.openscenegraph.org/projects/osg/wiki/Downloads):
>>
>>     source package : OpenSceneGraph-2.8.2.zip
>>     svn tag: svn co
>> http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2
>> OpenSceneGraph
>>
>>
>> Updates between 2.8.2 and 2.8.1 releases include: ¶
>>
>>     * Build fixes for:
>>           o RedHat Enterprise Linux
>>           o Building of dicom plugin with ITK under Linux.
>>     * Crash fixes to:
>>           o crash during window destruction under Windows when using
>> closing a MFC based GraphicsWindow
>>           o deadlock under Windows due threading issues with atomic
>> operations in Win32 Barrier implementation
>>           o OpenFlight plugin not handling spaces at the end of option 
>> strings
>>     * Bug fixes to :
>>           o computation of sector range in osgSim::LightPoint
>>           o extension checking of FBO packed stencil support
>>           o position of tabs at corners of manipulators
>>           o threading bug in .osg plugin that occurred during
>> multi-threaded initialization
>>           o alignment of Text what setting alignment after assign text string
>>           o loading of compressed texture arrays
>>           o texture generate mipmap for non power of two textures
>>           o regression in X11 key symbol remapping, improved support
>> for Russian keyboards
>>           o regression of StencilMask setting in RenderStage
>>           o small memory leak in X11 usage
>>           o Transform::computeBound() double BoundingSphere support
>>           o Resize handling when master and slave Cameras share the
>> same GraphicsContext
>>           o Handling of locale in plugins and env var parsing so it
>> alw

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

[Robert Osfield]

Hi Tanguy,

I don't have a windows box to test against so can't do anything first
hand.  It does very much sound like Windows threading issue that will
require a specific Windows mechanism in your application set up to
avoid hitting these problems.  I don't what what the solution might
be, but perhaps it would require serialization of all system calls
like getenv.

The solution will not be ditching singletons.  They are extremely
useful to design and implementation of the OSG. You simply can't
replace them without major surgery of API and implementation, and even
if you did you'd loose significant flexibility and function -
something which is currently loosely coupled (yes a great OO asset)
would end up be far more tightly coupled than it is now.

Please remember that the OSG is used heavily by thousands of
developers on thousands of applications across dozens of platforms,
with many applications which are heavily threaded - and it's been
under decades development without this issue cause problems.  The
problems you are seeing are serious, but they aren't the norm, it's
because of your particular application usage model and platform.   I'm
certainly open to finding an OSG solution, but it'll have to be
unobtrusive and require minimal code and API changes, otherwise it
simply won't be merged as the cost and risks to existing users will be
too great.

As a general note, please abstain from using immotive language to try
and make your point.  I have found over the years that the quality of
reasoning if often inversely proportional to how immotive the language
is used by a poster, so once I see such language I know it's a early
warning of what may well be an unreasonable request.  If you have a
good point, you don't need trumped up rhetoric, the facts speak for
themselves.

Robert.

On Mon, Aug 3, 2009 at 7:34 PM, Tanguy
Fautre wrote:
> Hi all,
>
> With the help of Aymeric, we've been able to create a small program
> reproducing the problem. On my machine (Core i7, Vista x64, VC8 and VC9,
> Debug and Release) it deadlocks 99% of the time. Other machines have
> shown to deadlock less often (Aymeric's machine deadlocks roughly 20% of
> time, Dave's only about 10 %).
>
> The example program is very simple. While you'll find the full program
> with its cmake files attached, I've copy/pasted the heart of the program
> directly into this post. The full explanation of why it is deadlocking
> has already been posted by Aymeric
> (http://forum.openscenegraph.org/viewtopic.php?p=15636).
>
> Cheers,
>
> Tanguy
>
>
>
> // Library.cpp (to be compiled in Library.dll)
>
> static const char * env =
> std::getenv("LIBRARY_UBER_OPTION_ENV_VARIABLE");
>
>
>
> // Main.cpp (to be compiled in Main.exe)
>
> void libraryThreadMain(void *)
> {
>        LoadLibraryA("Library.dll");
> }
>
> void threadMain(void * argv)
> {
>        const char * prog_name = ((char **)argv)[0];
>
>        struct stat sd;
>        stat(prog_name, &sd);
> }
>
> int main(int argc, char * argv)
> {
>        HANDLE thread_a = (HANDLE) _beginthread(&libraryThreadMain, 0,
> 0);
>        HANDLE thread_b = (HANDLE) _beginthread(&threadMain, 0, argv);
>
>        WaitForSingleObject(thread_a, INFINITE);
>        WaitForSingleObject(thread_b, INFINITE);
>
>        CloseHandle(thread_a);
>        CloseHandle(thread_b);
> }
>
> ___
> 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] complete copy of my scenegraph

[Robert Osfield]

Hi Bob,

Cloning your whole scene graph sounds like a very heavy handed thing to do.

What might be better is to use use a custom node that manages both
StateSet's and then decides upon which to use depending upon the cull
traversal mask from within a custom traversal method.  You could also
set this up using a Group containing two subgraphs that have a Group
with the appropriate StateSet and NodeMask, but sharing the same
subgraph.

Robert.

On Tue, Jul 28, 2009 at 7:50 PM, Bob Youmans wrote:
> Hi All, as I’m trying to set up my scenegraph for rendering in two ways, I’m
> thinking I want 2 complete copies:  one to set callbacks and statesets on
> for the shader-version and another to have that user can “throw” without any
> of this stuff.  Then I can user the viewer::setSceneData to swap them.  Can
> I do this simply by using CopyOp::DEEP_COPY_ALL?
>
>
>
> Thanks,
>
> Bob
>
> ___
> 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] OpenSceneGraph-2.8.2-rc4 problem with osgViewerFox

[Martin Fleck]

Hello ^^

If I try to compile the sample-program in debug-mode I also get an error, but a 
violation access-error (when he tries calling readNodeFile).

I've also experienced the linker-warning when trying to compile in Release-mode.

So has anyone solved the problem yet? Or does anyone have a different 
approach/idea how it could work?

Thank you!

Cheers,
Martin

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





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

Re: [osg-users] osg 2.2 How to disable picking for objects attached to camera with smaller viewport when they are no visible in the scene

[Robert Osfield]

Hi James,

The easiest way to do selective picking is the use a traversal mask on
the intersection traversal that maps to node masks on the nodes in
your scene.  For instance is you set a node mask of 0x1 on the parts
of the scene you won't to pick, and 0x2 on the parts your don't want
to, then use a traversal mask of 0x1 then only the parts you won't
will be picked.

Robert.

On Fri, Jul 31, 2009 at 9:38 AM, James Sim wrote:
> Hi,
>
> i have a hud camera with a viewport of (x, y, w=200, h=200) and projection 
> fixed at (x, x+w, y, y+h). The objects attached to Camera is an image of size 
> 640*480 which is the screen resolution for the viewer.
>
> i have a pickhandler that handles the picking for the hud and the 3D objects 
> behind the hud.
>
> The pickhandler picks the hud when i click on the camera, it also picks the 
> hud when i click outside the camera as shown by the red dot in the attachment.
>
> Is there anyway i can disable picking outside the camera?
>
> Thank you!
>
> Cheers,
> James
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=15670#15670
>
>
>
>
> ___
> 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] glMultiTexCoord4f , OSG with OGL code

[Ulrich Hertlein]

Hi Pau,

On 5/08/09 1:58 AM, Pau Moreno wrote:

I've realized that the problem is that I'm losing the graphics context. I'm 
having the
same problem with the inicialization of a shader, and it crashes here before the
glMultiTexCoord4f(), so I think if I solve the problem with the shader this 
maybe
solves my first issue. My problem is that I have to work with a geometry 
shader, so I
have to do all the initializations in OGL. I finally found a solution to 
initialize
glew doing viewer.setRealizeOperation( ... ); but when I do viewer.realize, 
seems that
I loose the Graphics Context again. I want to initialize my shader
(glCreateProgramObjectARB) in a diferent place than where I do glewInit... how 
I can do
that?


Why are you manually creating GLSL programs?

If you could just use osg::Program you wouldn't have any context issues in the 
first place.

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

Re: [osg-users] OSG and WPF Questions

[Martin Fleck]

Hello everyone,

sorry for not writing so long, but I've been quite busy. I've tried some things 
to integrate OSG in .NET, but none of the solutions were satisfactory. 
As stated by Brian above, the WPF popup windows were flickering and I didn't 
manage to get the rendering to texture to work. 
Then I tried WinForms and there also at least the shadow of those windows were 
flickering. :(

Now my boss said I should leave .NET aside and said I should try using the 
Fox-Toolkit. So everyone thank you for your help in .NET, but seems like I 
won't work on this topic any further.

Cheers,
Martin

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





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

Re: [osg-users] Blending Low Resolution Texture to Big Screen

[Robert Osfield]

Hi Kiruba,

Your problem is unreasonable expectations.  Mip mapping is purely for
minification and won't help you when you magnify.  What you should
expect is heavily un-sampled textures to look lousy, this is normal.
The fix is to sample your textures correctly so they aren't heavily
undersampled.

Robert.

On Fri, Jul 31, 2009 at 8:08 AM, kiruba nantham wrote:
> Hi Robert,
>       Yes i understand i am trying to do somthing that beyond OSG support. i
> have already done these teture mappings but i have never tried these
> mipmapping techniques. even now i am able mipmap it but my big problem here
> as you said undersampling. i checked with CImg Library (3rd party)
> applications but i am unable to integrate it in my application. please can
> you explain if you have any idea?
> regards,
> kiruba.
> --- On Mon, 7/27/09, Robert Osfield  wrote:
>
> From: Robert Osfield 
> Subject: Re: [osg-users] Blending Low Resolution Texture to Big Screen
> To: "OpenSceneGraph Users" 
> Date: Monday, July 27, 2009, 3:46 PM
>
> Hi Kurba,
>
> I'm Ulrich, this is classic undersampling, the best way to solve it is
> to choose you texture resolution far more appropriately, you certainly
> can't expect good results with such an aggressive undersampling,
> OpenGL certainly won't help you, and the OSG does have any magical
> pixie dust to help you either.
>
> If you really really must try and use such an undersampled image then
> go have a look at 3rd party tools for image processing to see if they
> can provide edge detection and filtering based on this, or some other
> specific method to handling such extreme undersampling.
>
> Robert.
>
> On Mon, Jul 27, 2009 at 11:08 AM, kiruba
> nantham wrote:
>> Hi Hertlein,
>>    Thank you for your reply,
>>    Yes, i accept as you said i am blowing each pixel in the texture to 8x
>> its size. but what all i want is after making this image bigger (i.e. 8x)
>> just adding some blur to overall picture so that the edges dostn't look
>> odd.
>> the problem here is i don't know how to add blur in OSG. if you can give
>> some tutorial links i can look in to it.
>> Regards,
>> Kiruba.
>>
>> --- On Mon, 7/27/09, Ulrich Hertlein  wrote:
>>
>> From: Ulrich Hertlein 
>> Subject: Re: [osg-users] Blending Low Resolution Texture to Big Screen
>> To: "OpenSceneGraph Users" 
>> Date: Monday, July 27, 2009, 3:01 PM
>>
>> On 27/07/09 10:48 AM, kiruba nantham wrote:
>>> Hi friends,   I am new to OSG. i am trying to map my small texture
>>> (128*128 pixel) to
>>> Big display (800*800 pixel). i am able to load successfully but i face
>>> one
>>> problem with
>>> it. the problem is my picture doesn't like smooth, my image looks very
>>> bad
>>> (picture is
>>> attached with this mail). can any one suggest any way to make my picture
>>> look proper?
>>
>> Increase the resolution.
>>
>> There is simply not enough information in a 128x128 image to make it look
>> nice at the output resolution.  Remember that your blowing up each pixel
>> in
>> the texture to 8x its size.
>>
>> Cheers,
>> /ulrich
>> ___
>> 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] Perspective / Orthogonal projection matrix with CameraManipulator

[Robert Osfield]

Hi Andrew,

I would not recommend trying to make an orthographic view behave like
a perspective view, it simple doesn't work (this is not an OSG issue,
but the basic principles involved.)  I've written about this before so
I won't waste my key presses have a look through the archives.

The upshot is I would suggest keeping orthographic views for fixed
maps/side/front views, or very constrained user interaction models.
If you try to make a orthographic behave like a perspective you'll
just waste lots of time.

Robert.

On Thu, Jul 30, 2009 at 6:22 PM, Andrew Thompson wrote:
> Hi there,
>
> I am using a custom CameraManipulator class (inheriting 
> osgGA::MatrixManipulator) which is added to my scene after the OpenSceneGraph 
> is initialised
>
> The CameraManipulator has two member variables I've added, a Vec3d target and 
> position. These are used to create a projection matrix by calling 
> Matrix::makeLookAt. As the events are handled by the manipulator, I am 
> updating the position/target and recomputing the matrix, then on Frame I am 
> returning the constructed matrix.
>
> This provides a great perspective view, however I cannot work out how to 
> construct an orthogonal projection using a target/position.
>
> In addition, I'd like to be able to change the Field Of View when I create 
> the matrix.
>
> I realise there is a Matrix::makeOrtho and Matrix::makePerspective, however 
> I'm not sure how to use these with my CameraLocation/Target variables.
>
> Could anyone offer me some advice?
>
> Thank you!
> Andrew
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=15659#15659
>
>
>
>
>
> ___
> 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] Draw time vs. GPU time Stats question

[Robert Osfield]

Hi Alex,

Draw time is composed of the Draw dispatch (yellow bar) and the Draw
GPU (orange bar).  The Draw dispatch is the OSG's CPU overhead in
sending all the OpenGL tokens and data into the OpenGL fifo.  The Draw
GPU is the time it takes to render the frame down on the GPU, it's
value is determined by an OpenGL extension, but this extension doesn't
provide an absolute timing so the position on the on screen stats is
just an estimate that the OSG makes.

Robert.

On Wed, Jul 29, 2009 at 10:30 PM, Pecoraro, Alexander
N wrote:
> Is it fair to say that the Draw time in the OSG stats measures the time
> needed to sort and call the display lists of the Geometry nodes obtained by
> the Cull stage and make the other frame rendering related OpenGL calls? And
> GPU time is the time that the GPU spends rendering the geometry (vertices,
> textures, etc)?
>
>
>
> Thanks.
>
>
>
> Alex
>
> ___
> 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] [OT] Looking for a lib that adapts terrain to 3D object

[Robert Osfield]

Hi Sukender,

I'm diving in this thread rather late...

One of my intentions for osgTerrain is to support adding polygonal
constraints to the tessellation of the height fields.  This will allow
us to import building outlines etc. and have them automatically
matched with the terrain.   This is a feature I won't be able to
tackle soon though, too many other tasks on my plate...  but I'll get
there eventually if others don't beat me to it ;-)

Robert.

On Tue, Jul 28, 2009 at 3:59 PM,  wrote:
> Hi all,
>
> I saw (once upon a time...) a library/toolkit/nodekit/whatever that's able to 
> nicely adapt/modify a terrain mesh so that a given 3D object (say a building) 
> is on the floor instead of floating over it. You know, when you got a 
> heightfiled that does not match the building altitude...
> I guess it was on this mailing list... Does anyone knows what I'm talking 
> about, and where to find it? I just can't!
> Thanks.
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
> ___
> 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] Optimizer changes LOD rangemode

[Robert Osfield]

Hi Favien,

This sounds like a bug.  Any chance you could have a look at fixing it? :-)

Robert.

On Wed, Jul 29, 2009 at 11:06 AM, Fabien Dachicourt wrote:
> Hi All,
> Using osg 2.8, it seems that the optimizer option COMBINE_ADJACENT_LODS
> doesn't take care of LOD rangemode.
> LOD children with rangemode PIXEL_SIZE_ON_SCREEN are merged in a LOD with
> rangemode DISTANCE_FROM_EYE_POINT.
>
> Regards,
>
> --
> 
> Fabien
>
>
>
> ___
> 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] osg::View::computeIntersections and Shaders

[Robert Osfield]

Hi Harold,

There is no connection between the intersection traversal and shaders,
the IntersectionVisitor ignores state completely.

What is probably the problem is how the Effect node is interacting
with the intersection traversal.  Go put some break points in your
code to see what is happening during the intersection traversal.

Robert.

On Wed, Jul 29, 2009 at 10:59 AM, Harold Comere wrote:
> Hi all,
>
> I will time to explain my problem clearly this time :)
>
> I use osg::View::computeIntersections to get the picked node.
> When a node is picket, i apply a shader effect.
> The select effect is done by a class SelectEffect wich inherate of
> osgFX::Effect.
> To apply the select effect i insert a SelectEffect between the picked node
> and its parent.
> Then to remove the effect, i delete the SelectEffect and restor initial
> parent.
>
> The problem is when i call osg::View::computeIntersections, it do not
> intersect nodes with an select effect applied.
> If i display the intersected drawable list returned by computeIntersections,
> before and after have applied the select effect on the node containing the
> picked drawable, the drawable simply disapear from list.
>
> Is there any link between shaders and osg::View::computeIntersections ? I
> cant get it from source code.
>
> Thanks for your attention,
> Regards,
>
> Harold
>
> ___
> 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] What are txf and tpf files ?

[Robert Osfield]

Hi Mach,

Terrapage databases usually have overly aggressive LOD range settings
so it culls out tiles complete at long distances.  As others have said
the default camera position in osgviewer is beyond the distance range
of many Terrapage databases so you have to zoom before it starts
paging in.   There is nothing wrong here, it's simply the way the
database is set up, and the fact that osgviewer is a general purpose
3D viewer so the default camera positions reflect what is appropriate
for the broadest range of 3D scenes.

W.r.t memory consumption unless you are in range of the LOD distances
you won't see any paging in at all, and the memory won't start
increasing either.  This is the OSG doing exactly what it's supposed
to, it's the whole point of database paging - you only load what is
required, and if the database says that a tile ain't in range it
simply won't load it.  Get in range of the LOD and things will
automatically start paging in.

For a simulator you'll be controlling the camera position to be within
the confines of the model any way so you'll see the terrain pop up.

Robert.



On Wed, Jul 29, 2009 at 7:33 AM, Mach Bhai wrote:
> I tried changing both LOD and Eye point but it didn't work.
>
> As an after thought i opened task manager to monitor the memory consumption 
> of osgviewer and then loaded the txp file. There was no increase in memory 
> consumption which was a bit disappointing.
>
> Then i opened another simpler txp and the memory consumption just shot up.
>
> So i can conclude fairly that the osgviewer is not reading the txp file at 
> all.
>
> As of now i am looking at other viewers / options mentioned here. And i would 
> love to get more nudges in the right diection.
>
> Thank you all.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=15575#15575
>
>
>
>
>
> ___
> 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