Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release

[Wojciech Lewandowski]

Hi Robert,

I have been bit out of sync with froums recently. I am curious if the issue 
with color/normal per primitve was resolved ? Its fairly basic functionality 
so I thought I'll remind about this before new release.


Cheers,
Wojtek Lewandowski


--
From: "Robert Osfield" 
Sent: Friday, December 04, 2009 6:34 PM
To: "OpenSceneGraph Users" 
Subject: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release


Hi All,

It's been a long long time since the last dev release, virtue of me
being distracted by work like OpenGL ES, GL object pools etc.  I'm now
almost back on top of submissions, so the time now looks good to make
the 2.9.6 developer release.  Since it's been so long since the last
dev release there has been lots and lots of build and source code
changes so would appreciate testing of svn/trunk so we can catch any
problems prior to the 2.9.6 release - all going well I'll make it this
comming Monday morning.

The API should be pretty compatible between 2.8.x and 2.9.6 so I'm
hopping that users won't see too many problems arising from all these
changes, what I can say is whether all the changes have broken the
build in the less actively used platforms i.e. beyond Linux and
Window.  Even on the most commonly used platforms there are still lots
of different architecture, build and dependency differences to throw a
spanner in the works so as much testing as you can throw at it the
better.

If you see build and runtime issues just post a report of them to
osg-users/forum on this thread, and any fixes to osg-submissions as
complete modified files.

If things work well for you then please email into this thread to
confirm that your plarform/build combination is working fine so I know
how well we are converging to a reasonably stable 2.9.6.

Thanks in advance for your assistance,
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

Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release

[Wojciech Lewandowski]

Thank You,

Indeed it now looks right.  I could not locate the post yesterday but today 
I tried harder with Remote PC connection to the company computer and found 
it:

http://forum.openscenegraph.org/viewtopic.php?t=3998
I have downloaded the example model and it does look correct now. My 
appologies for the distraction.


Cheers,
Wojtek

--
From: "Robert Osfield" 
Sent: Saturday, December 05, 2009 10:53 AM
To: "OpenSceneGraph Users" 
Subject: Re: [osg-users] Please test svn/trunk in prep for 2.9.6 dev release


Hi Wojtek,

On Fri, Dec 4, 2009 at 8:51 PM, Wojciech Lewandowski
 wrote:
I have been bit out of sync with froums recently. I am curious if the 
issue
with color/normal per primitve was resolved ? Its fairly basic 
functionality

so I thought I'll remind about this before new release.


I'm not sure about which issue you are talking about.  As far as I'm
aware osg::Geometry is now working correctly and there haven't been
any recent reports of problems.  If there are specific test models
that still fail please point me at them.

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

Re: [osg-users] osgShadows

[Wojciech Lewandowski]

Hi,

Cascaded Shadow Maps is the same as Parallel Split Shadow Map. PSSM is 
implemented in osgShadow. Also LispSM could work for you scenario. 

Cheers,
Wojtek Lewandowski






From: Trajce Nikolov 
Sent: Wednesday, December 09, 2009 10:19 AM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] osgShadows


Hi Harold, 


yes, my light source is the "sun". No other lights in the scene yet. And the 
results are not good. I will do research on the "cascade shadowmaps" and will 
try to implement it. Thanks for the hint

Nick

http://www.linkedin.com/in/tnikolov
Sent from Gümüşsuyu, İstanbul, Turkey 


On Wed, Dec 9, 2009 at 11:13 AM, Harold Comere  wrote:

Hi Nike,


  There is many way to get shadows and the shadowing technique choice shall 
depend of your scene data.

  The two basic shadowing techniques are :
  - shadow maps ( image based )
  - shadow volumes ( geometry based )

  Shadow maps are very cheap and easy to implement but will works good only if 
your light is not far from what you are shadowing due to the image approach. So 
if you have a large terrain with an unique directional light ( as sun ), simple 
shadowmaps should do an ugly result.
  You could try "cascade shadowmaps" which is a technique used a lot in video 
games. It uses a kind of shadowmap LOD to avoid image based algorithms issues 
and stay cheap.

  Shadow volumes generate very accurate shadows but as it is based on geometry, 
if your scene geometry is complex you will experience some perf issues.

  Again, the shadowing technique choice depends of how many lights you have, 
where they are, what you are shadowing etc.
  Give a bit more details of your goal and i'm sure some osg pro will bring to 
you the ideal solution using osg :)

  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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgShadows

[Wojciech Lewandowski]

Hi Nick,

I don't know much about PSSM.  I am na author of LispSM implementation. 
However, many osgShadow techniques use shaders and they will not work out of 
the box for all the applications that also use shaders.  In this case one have 
to 1) subsitute shadow shaders to add aplication shader functionality or 2) 
override shadow shaders at the scene root with application shaders that were 
modified to include shadow term computation (using the uniforms theat shadow 
technique sets).  Check forums there was a lot on the subject recently.

Both cases are advanced topics, so one trying to do this usually must have good 
knowledge of C++ (to read and understand the Technique code), GLSL (to modify 
shaders), shadow map algorithm (to know whats important is shaders, NVidia has 
nice presentations). Its steep path but implementing CSM technique in OSG for 
multithreaded/multimonitor from scratch will be much much steeper.

Wojtek





From: Trajce Nikolov 
Sent: Wednesday, December 09, 2009 12:11 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] osgShadows


I tried both. 


PSSM gives some artifacts (see the attached image) - the white in the 
background, also, some flickering of the shadow on the models.

Nick

http://www.linkedin.com/in/tnikolov
Sent from G�m��suyu, �stanbul, Turkey 


On Wed, Dec 9, 2009 at 12:27 PM, Wojciech Lewandowski  
wrote:

  Hi,
  �
  Cascaded Shadow Maps is�the same as Parallel Split Shadow Map. PSSM is 
implemented in osgShadow. Also LispSM�could�work for you scenario. 
  �
  Cheers,
  Wojtek Lewandowski
  �
  �
  �
  �


  From: Trajce Nikolov 
  Sent: Wednesday, December 09, 2009 10:19 AM
  To: OpenSceneGraph Users 
  Subject: Re: [osg-users] osgShadows


  Hi Harold, 


  yes, my light source is the "sun". No other lights in the scene yet. And the 
results are not good. I will do research on the "cascade shadowmaps" and will 
try to implement it. Thanks for the hint

  Nick

  http://www.linkedin.com/in/tnikolov
  Sent from G�m��suyu, �stanbul, Turkey 


  On Wed, Dec 9, 2009 at 11:13 AM, Harold Comere  
wrote:

  Hi Nike,


There is many way to get shadows and the shadowing technique choice shall 
depend of your scene data.

The two basic shadowing techniques are :
- shadow maps ( image based )
- shadow volumes ( geometry based )

Shadow maps are very cheap and easy to implement but will works good only 
if your light is not far from what you are shadowing due to the image approach. 
So if you have a large terrain with an unique directional light ( as sun ), 
simple shadowmaps should do an ugly result.
You could try "cascade shadowmaps" which is a technique used a lot in video 
games. It uses a kind of shadowmap LOD to avoid image based algorithms issues 
and stay cheap.

Shadow volumes generate very accurate shadows but as it is based on 
geometry, if your scene geometry is complex you will experience some perf 
issues.

Again, the shadowing technique choice depends of how many lights you have, 
where they are, what you are shadowing etc.
Give a bit more details of your goal and i'm sure some osg pro will bring 
to you the ideal solution using osg :)

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



  ___
  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] LISP Shadow Map and OverlayNode

[Wojciech Lewandowski]

Hi.

As far as I know both OverlayNode and ViewDependentTechniques (LispSM ) use 
shaders so you should make sure to not use conflicting texture stages and merge 
the shaders at least if you plan to use both techniques together.

Wojtek


From: Trajce Nikolov 
Sent: Wednesday, December 09, 2009 6:20 PM
To: OpenSceneGraph Users 
Subject: [osg-users] LISP Shadow Map and OverlayNode


Hi, 


I have a scenegraph like this


ShadowMapScene with Light Space Perspective ShadowMap Technique and children an 
overlay node. The overlayed subgraph is all around ... unexpected. Possible 
bug. Any work around?

Nick

http://www.linkedin.com/in/tnikolov






___
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] theading mode question

[Wojciech Lewandowski]

Hi Alex,

I suppose only --SingleThreaded mode will be fully serialized Update will 
preceede and finish before Cull and Cull will precede and complete before Draw. 
Other threading modes theoretically may overlap Draw nad Update traversals if 
OSG decides all the nodes are not updated dynamically.

Setting DATA_VARIANCE to DYNAMIC on the states/drawables you don't want to 
overlap their UpdateCallbacks/UpdateTraversal with Draw should also do the 
trick for remaining treading modes.

Cheers,
Wojtek


From: Pecoraro, Alexander N 
Sent: Thursday, December 17, 2009 10:00 PM
To: OpenSceneGraph Users 
Subject: [osg-users] theading mode question


Is there a way to set the threading mode so that the draw thread does not run 
until after the update traversal is done?

 

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] viewer loaded from dll not responsive to events

[Wojciech Lewandowski]

Hi Guys

I doubt your problem is directly related to DLL use. We have a code at the 
company where allmost all OSG stuff including osgViewer creation is loaded 
as dynamic DLL plugins. Its built with VS 2008 Express. All works correctly 
and we see no problem with window focus or similar things. I suspect 
something might get lost in translation to DLL. Mangled args passed to 
viewer, mixed library models, overrriden HINSTANCE or somethin like 
this...( these are very fuzzy thoughts, if I was to elaborate I would not be 
able to tell how they could directly affect DLL window setup).


Cheers,
Wojtek

--
From: "Robert Osfield" 
Sent: Monday, December 21, 2009 10:21 AM
To: "OpenSceneGraph Users" 
Subject: Re: [osg-users] viewer loaded from dll not responsive to events


Hi Nick,

I'm no windows programmers, but vaguely recall a restriction on events
and the main thread, osgViewer has code built in to cope with this,
but don't recall any issues with loading a viewer from a dll.

The best platform for handling really flexible window creation is the
oldest one we support... X11 allows you great control over events
and is far better than Windows and OSX for this.  Alas sometimes
technologies go backwards overtime

Robert.

On Sun, Dec 20, 2009 at 11:01 PM, Trajce Nikolov
 wrote:

Hi,
I am loading my viewer from a dll and as the topic says, it does not 
respond

to any events. Windows platform. Any ideas?
There is a way I think to put message hooks but it is more then a hack 
then

a real solution
Thanks
Nick

http://www.linkedin.com/in/tnick

___
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] osgShadow & ECEF precision problems

[Wojciech Lewandowski]

Hi Marius,

I am not sure what ECEF acronym means. I guess its WGS84 eliposoid 
coordinate system with origin in ellipsoid center.


We are using LispSM with VPB generated terrain. Do you use 
setModellingSpaceToWorldTransform method ? It should be helpful in your 
work. See example of usage and setting it in osgshadow.cpp lines 832-851 
(OSG trunk).
However, I have not tested it with LispsmVB though, but LispsmCB and 
LispsmDB. And they seem to work precisely enough most of the time.


When impleneting Lispsm/Minimal Shadow Map algorithms, I made the effort to 
make all computations using doubles. At the time when I was doing this, 
bounding boxes were based on floats so it may be the case that some issues 
could be related to inacurate bounding box precision.


But my observations regarding shadow volume computations suggest different 
cause: even double precision is not enough for convex polytope math in WGS84 
world coords when these convex polytopes are made from view frustums with 
very short near planes. For this case it would be better to make all shadow 
volume computations in view space. I wish I could do this someday but 
frankly I do not expect it to happen anytime soon.


Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Marius Heise" 

To: 
Sent: Tuesday, December 29, 2009 12:20 PM
Subject: [osg-users] osgShadow & ECEF precision problems



Hi!

I have been using osgShadow::LightSpacePerspectiveShadowMapVB very 
successfully in previous osg projects. I am currently making the 
transition from a local XYZ to a whole earth ECEF database.


In general the shadow still works correctly, but jumps around by about a 
meter or two when my model moves. It looks like the underlying shadow 
bounding volume calculation architecture is not completely implemented 
with double precision. If so, could anybody give me a hint if the 
modifications are simple and where they are?


Thanks a lot - any help is appreciated.

Cheers,
Marius

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





___
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] osgShadow & ECEF precision problems

[Wojciech Lewandowski]

Hi Marius,

When I do this I see empty blue screen. No model displayed. Looks like 
camera is positioned far from the model. Perhaps you have done more 
modifications ?


Wojtek


- Original Message - 
From: "Marius Heise" 

To: 
Sent: Tuesday, December 29, 2009 4:17 PM
Subject: Re: [osg-users] osgShadow & ECEF precision problems



Hi Wojtek,

I have done various tests with the osgShadow demo. All three versions of 
the LightSpacePerspectiveShadowMap (VB/CB/DB) have the same precision 
problem even if setModellingSpaceToWorldTransform() is used. I did the 
following to reproduce:


Simulate a "large" database by changing osgShadow demo line 371 to:

osg::Vec3 center(3000.0, 3000.0, 3000.0);

Execute the demo with the following:

osgshadow --directionalLight --lispsm --ViewBounds --debugHUD -2
osgshadow --directionalLight --lispsm --CullBounds --debugHUD -2
osgshadow --directionalLight --lispsm --DrawBounds --debugHUD -2

Any ideas?

Thanks a lot for your effort!

Cheers,
Marius

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





___
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] osgShadow & ECEF precision problems

[Wojciech Lewandowski]

Marius,

We must have been using different OSG versions. 1 , SPACE seems to not work 
on my trunk code. I solved this by setting home postion manually.
I was able replicate your problem but unfortunately have no more time to 
spare now and any aditional hints do not cross my mind at the moment. 
However,  I am curious what can be wrong myself and will look into it in 
next or two days.


Wojtek


- Original Message - 
From: "Marius Heise" 

To: 
Sent: Tuesday, December 29, 2009 5:05 PM
Subject: Re: [osg-users] osgShadow & ECEF precision problems



Hi Wojtek,

sorry.. press '1' and then SPACE ... the camera home position is then 
calculated automatically to fit the model into the view. This is all 
caused because the model is so far away.


Good luck :-)

Cheers,
Marius

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





___
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] osgShadow & ECEF precision problems

[Wojciech Lewandowski]

Hi Marius,

My congratulations! I am glad you did it.


I solved my directional light case. I changed all floats to doubles in

* StandardShadowMap::ViewData::aimShadowCastingCamera


The code in the above method was based on original ShadowMap code and indeed 
used floats (I must admit I neglected this method).


In the process I also "upgraded" the polytope class to double (I don't 
think this is necessary). I can fix the other light type cases (VB/CB/DB) 
but someone will have to give me a quick walk-through on posting updates 
to osg so I don't have to do my work twice.


osg::Polytope is double based by default as far as I know.
Other classes stemming from ViewDependentShadowTechnique inherit and use 
StandardShadowMap::ViewData::aimShadowCastingCamera method so you have fixed 
them all in one shot ;-)


Can you post your modified StandardShadowMap.cpp ? I am preparing few fixes 
and I would like to merge my changes with the change you have meade before 
sending my submissions.


Cheers,
Wojtek

- Original Message - 
From: "Marius Heise" 

To: 
Sent: Wednesday, December 30, 2009 11:04 AM
Subject: Re: [osg-users] osgShadow & ECEF precision problems



Hi Wojtek,


The light camera position was calculated as float as was thus jumping 
around.


Of course the change from yesterday using double bounding volumes also has 
to be activated.



Thanks a lot for your support.

Cheers,
Marius

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





___
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] DDS uncompressed RGB(A) / BGR(A)

[Wojciech Lewandowski]

Hi,

I had some experience with D3D in the past maybe could help clear a picture 
a little.


Basic 32 bit color format using in Directx is named in Direct 3D: 
D3DFMT_A8R8G8B8. Components are enumerated from  most significant byte to 
least significant byte. Such pixel value is usually set by using single 
DWORD. for example DWORD color = 0xAA112233 coresponds to following bytes 
alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier, this is 
an order byte significance, not an order of bytes in memory. When you write 
this dword to memory they will land in following order on Intel (big endian 
CPUs)  [Blue][Red][Green][Alpha]. So in OpenGL notation it would be GL_BGRA. 
Hope this explains a bit. Hence basic Directx ARGB format should be read as 
OpenGL BGRA. To switch to more intuitive OpenGL RGBA you apparently have to 
swap R and B bytes.


However, DDS format is capable of storing all variants of 32 bit color 
layouts. RGBA, BGRA, ABGR, & ARGB. As far as I remember only color component 
bitmasks should be changed accordingly to select proper variant.  If your 
tools do not read them correctly this is most probably an issue with those 
tools. I am sure OSG DDS ReaderWiriter is not saint here as well.


Cheers,
Wojtek




- Original Message - 
From: "Sukender" 

To: "OpenSceneGraph Users" 
Sent: Wednesday, December 30, 2009 1:22 PM
Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)



Hi all,

Is there an endianess problem with DDS format? I'm using a Core2Duo here 
and I don't know under which kind of machine the DDS has been tested...


A little explanation: After a bit of investigation (=cleaning stupid 
copy-paste), I found that the only "true" bug I had was "Changing R, G or 
B writer's masks doesn't seem to affect reading in 3rd-party readers". Has 
anybody encountered this before?
Writing DDS: It seems the DDS must be BGR in order to make 3rd-party 
readers work correctly (by inverting R and B channels).
Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are 
marked RGB but are BGR...


Please help and share your experience!

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


- "Sukender"  a écrit :


Hi Robert and all,

I'm lost:
- Changing R, G or B writer's masks doesn't seem to affect reading
(either the plugin or 3rd-party readers, except when masks are
completely nonsense)
- Copying the image (DEEP_COPY) and writing the copy instead of the
oringinal result in a vertical flip of the image in the file!
- Manually inverting R & B channels in a copy of the image doesn't do
anything...
I must have a very stupid mistake somewhere but I can't fugure out
where...

Any idea?

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

- "Robert Osfield"  a écrit :

> Hi Sukender,
>
> I'm not overly familiar with the dds plugin, but what you describe
> sounds like a bug in writer in our dds plugin.
>
> Robert.
>
> On Fri, Dec 18, 2009 at 5:15 PM, Sukender  wrote:
> > Hi all,
> >
> > It was discussed a long time ago but I dit not find an answer.
> Saving to DDS an uncompressed RGB image and then loading from the
file
> works: the loaded image is the same as the original. However, the
file
> is BGR (R and B inverted). I tried three 3rd-party tools (image
> viewer/converters) and all display the same.
> > Do you think this is a bug in DDS readerwriter? Anyone has a clue
> about it?
> > Thanks a lot.
> >
> > 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

___
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] osgShadow & ECEF precision problems

[Wojciech Lewandowski]

Hi Marius,

Current trunk version does not draw debug volumes, don't be surprised not 
seeing them. Its a problem outside of the osgShadow related to changes in 
COLOR_PER_PRIMITIVE handling.


Cheers,
Wojtek



- Original Message - 
From: "Marius Heise" 

To: 
Sent: Wednesday, December 30, 2009 1:37 PM
Subject: Re: [osg-users] osgShadow & ECEF precision problems



Hi Wojtek,

:-) will do. Since I am currently on osg 2.9.5 I will switch to trunk and 
check if the "double" modifications only in StandardShadowMap.cpp are 
enough to solve the problem I had. If this is the case, I will send you 
the svn patch for osg trunk. My 2.9.5 is too "dirty" and old that I can 
send you that patch.


Will let you know as soon as I've done it

Cheers,
Marius

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





___
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] DDS uncompressed RGB(A) / BGR(A)

[Wojciech Lewandowski]

Oops sorry small correction: Intel is little endian. I always confuse these 
names. I prefer using Least Significant Byte First and Most Significant Byte 
First to describe the CPU archtecture.


Wojtek

- Original Message - 
From: "Wojciech Lewandowski" 

To: "OpenSceneGraph Users" 
Sent: Wednesday, December 30, 2009 1:57 PM
Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)



Hi,

I had some experience with D3D in the past maybe could help clear a 
picture a little.


Basic 32 bit color format using in Directx is named in Direct 3D: 
D3DFMT_A8R8G8B8. Components are enumerated from  most significant byte to 
least significant byte. Such pixel value is usually set by using single 
DWORD. for example DWORD color = 0xAA112233 coresponds to following bytes 
alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier, this 
is an order byte significance, not an order of bytes in memory. When you 
write this dword to memory they will land in following order on Intel (big 
endian CPUs)  [Blue][Red][Green][Alpha]. So in OpenGL notation it would be 
GL_BGRA. Hope this explains a bit. Hence basic Directx ARGB format should 
be read as OpenGL BGRA. To switch to more intuitive OpenGL RGBA you 
apparently have to swap R and B bytes.


However, DDS format is capable of storing all variants of 32 bit color 
layouts. RGBA, BGRA, ABGR, & ARGB. As far as I remember only color 
component bitmasks should be changed accordingly to select proper variant. 
If your tools do not read them correctly this is most probably an issue 
with those tools. I am sure OSG DDS ReaderWiriter is not saint here as 
well.


Cheers,
Wojtek




- Original Message - 
From: "Sukender" 

To: "OpenSceneGraph Users" 
Sent: Wednesday, December 30, 2009 1:22 PM
Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)



Hi all,

Is there an endianess problem with DDS format? I'm using a Core2Duo here 
and I don't know under which kind of machine the DDS has been tested...


A little explanation: After a bit of investigation (=cleaning stupid 
copy-paste), I found that the only "true" bug I had was "Changing R, G or 
B writer's masks doesn't seem to affect reading in 3rd-party readers". 
Has anybody encountered this before?
Writing DDS: It seems the DDS must be BGR in order to make 3rd-party 
readers work correctly (by inverting R and B channels).
Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are 
marked RGB but are BGR...


Please help and share your experience!

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


- "Sukender"  a écrit :


Hi Robert and all,

I'm lost:
- Changing R, G or B writer's masks doesn't seem to affect reading
(either the plugin or 3rd-party readers, except when masks are
completely nonsense)
- Copying the image (DEEP_COPY) and writing the copy instead of the
oringinal result in a vertical flip of the image in the file!
- Manually inverting R & B channels in a copy of the image doesn't do
anything...
I must have a very stupid mistake somewhere but I can't fugure out
where...

Any idea?

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

- "Robert Osfield"  a écrit :

> Hi Sukender,
>
> I'm not overly familiar with the dds plugin, but what you describe
> sounds like a bug in writer in our dds plugin.
>
> Robert.
>
> On Fri, Dec 18, 2009 at 5:15 PM, Sukender  wrote:
> > Hi all,
> >
> > It was discussed a long time ago but I dit not find an answer.
> Saving to DDS an uncompressed RGB image and then loading from the
file
> works: the loaded image is the same as the original. However, the
file
> is BGR (R and B inverted). I tried three 3rd-party tools (image
> viewer/converters) and all display the same.
> > Do you think this is a bug in DDS readerwriter? Anyone has a clue
> about it?
> > Thanks a lot.
> >
> > 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

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

Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)

[Wojciech Lewandowski]

Hi ,

Sorry, I have not followed all the posts in this thread. I am not sure what 
is the essence of your problem:
   Are you saying that 24 bit GL_RGB image written by OSG and later read by 
OSG looks differently ?
   Or there is an issue with reading 24 bit color images written by 3rd 
party tools ?

   What about 32 bit images ? Are they OK ?

About 3rd party tools, I've tested XNView, The Compressonator (AMD) and 
DeepExploration, and all seem to ignore the R, G, B masks... Or there is a 
mistake somewhere in OSG DDS writing that make those masks unreadable... 
or else I made a mistake somewhere!


I always recommend peeking into heart of darkness ;-) and trying MS 
DXTextureTool (installed with DirectX SDK)


I just checked,  the only 24 bit format that OSG DDS Writer currently writes 
is GL_RGB. (GL_BGR is not written but could be added quickly is guess). But 
its capable to read both GL_RGB and GL_BGR.


Can you post such 24 bit RGB DDS image that looks differently in OSG and in 
3rd party tools ?


Wojtek

- Original Message - 
From: "Sukender" 

To: "OpenSceneGraph Users" 
Sent: Wednesday, December 30, 2009 3:09 PM
Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)



Hi Wojciech,


I'm a bit lost now... What's next? Should we change something according to 
endianness (if little endian, swap R&B when reading and writing)?

If you got any idea there... ;)

Cheers,

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


- "Wojciech Lewandowski"  a écrit :


Hi,

I had some experience with D3D in the past maybe could help clear a
picture
a little.

Basic 32 bit color format using in Directx is named in Direct 3D:
D3DFMT_A8R8G8B8. Components are enumerated from  most significant byte
to
least significant byte. Such pixel value is usually set by using
single
DWORD. for example DWORD color = 0xAA112233 coresponds to following
bytes
alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier,
this is
an order byte significance, not an order of bytes in memory. When you
write
this dword to memory they will land in following order on Intel (big
endian
CPUs)  [Blue][Red][Green][Alpha]. So in OpenGL notation it would be
GL_BGRA.
Hope this explains a bit. Hence basic Directx ARGB format should be
read as
OpenGL BGRA. To switch to more intuitive OpenGL RGBA you apparently
have to
swap R and B bytes.

However, DDS format is capable of storing all variants of 32 bit color
layouts. RGBA, BGRA, ABGR, & ARGB. As far as I remember only color
component
bitmasks should be changed accordingly to select proper variant.  If
your
tools do not read them correctly this is most probably an issue with
those
tools. I am sure OSG DDS ReaderWiriter is not saint here as well.

Cheers,
Wojtek




- Original Message -
From: "Sukender" 
To: "OpenSceneGraph Users" 
Sent: Wednesday, December 30, 2009 1:22 PM
Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)


> Hi all,
>
> Is there an endianess problem with DDS format? I'm using a Core2Duo
here
> and I don't know under which kind of machine the DDS has been
tested...
>
> A little explanation: After a bit of investigation (=cleaning stupid
> copy-paste), I found that the only "true" bug I had was "Changing R,
G or
> B writer's masks doesn't seem to affect reading in 3rd-party
readers". Has
> anybody encountered this before?
> Writing DDS: It seems the DDS must be BGR in order to make 3rd-party
> readers work correctly (by inverting R and B channels).
> Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools
are
> marked RGB but are BGR...
>
> Please help and share your experience!
>
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
> - "Sukender"  a écrit :
>
>> Hi Robert and all,
>>
>> I'm lost:
>> - Changing R, G or B writer's masks doesn't seem to affect reading
>> (either the plugin or 3rd-party readers, except when masks are
>> completely nonsense)
>> - Copying the image (DEEP_COPY) and writing the copy instead of the
>> oringinal result in a vertical flip of the image in the file!
>> - Manually inverting R & B channels in a copy of the image doesn't
do
>> anything...
>> I must have a very stupid mistake somewhere but I can't fugure out
>> where...
>>
>> Any idea?
>>
>> Sukender
>> PVLE - Lightweight cross-platform game engine -
>> http://pvle.sourceforge.net/
>>
>> - "Robert Osfield"  a écrit :
>>
>> > Hi Sukender,
>> >
>> > I'm not overly familiar with the dds plugin, but what you
describe
>> > sounds like a bug in writer in our dds plugin.
&

Re: [osg-users] Depth buffer for shadow mapping

[Wojciech Lewandowski]

Hi Nick,

ShadowComparison = true 
causes opengl to use result of TexFilter(depth_at_texel > depth_map_coord_r) 

ShadowComparison = false 
causes opengl to use TexFilter( depth_at_texel ) value. 

To display depth texture on some hud its neccessary to turn ShadowComparison 
off. Its kinda tricky because it has to be also on for use with shadow mapping.
I used to apply special callback that was used to change the mode to draw 
shadow map on the screen. See osgShadow/DebugShadowMap.cpp 
DrawableDrawWithDepthShadowComparisonOffCallback callback

Wojtek


From: Trajce Nikolov 
Sent: Monday, January 11, 2010 10:31 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] Depth buffer for shadow mapping


Hi, 


I am trying to do the same. I noticed two methods of Texture2D.   
texShadowMap->setShadowComparison(true);
texShadowMap->setShadowTextureMode(Texture2D::LUMINANCE);


what are these doing? Also, what is to be done to display the depth texture on 
screen. 
Thanks
Nick

http://www.linkedin.com/in/tnick
Sent from Ünalan, İstanbul, Turkey 


On Mon, Jan 11, 2010 at 11:27 PM, Mourad Boufarguine 
 wrote:

  Hi Dominic, 


  AFAIK, the png plugin does not support writing depth image. Try the tiff 
plugin in svn/trunk ; a recent submission made it write depth images, and it 
works for me.


  Mourad


  On Mon, Jan 11, 2010 at 4:17 PM, Dominic Stalder  
wrote:

Hi there

I have the following RTT method:

   ref_ptr image = new Image;
   image->allocateImage(osgViewer->width(), osgViewer->height(), 1, 
GL_RGBA, GL_UNSIGNED_BYTE);

   // resets the size of the texture
   texture->setTextureSize(osgViewer->width(), osgViewer->height());

   // sets the clear mask the depth buffer
   camera->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   // sets the clear color to white
   camera->setClearColor(Vec4(1.0, 1.0, 1.0, 1.0));

   ...matrices and viewport...

   // sets the reference frame to an absolute coordinate frame
   camera->setReferenceFrame(Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT);

   // sets the texture camera to render before rendering to the screen
   camera->setRenderOrder(Camera::PRE_RENDER);

   // sets the rendering target of the texture camera to the frame buffer 
object (FBO)
   camera->setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);

   // attaches the texture to the texture camera (important: samples 
mustn't be greater than zero)
   // buffer component, texture, level, face, mip map generation, samples, 
color samples
   camera->attach(Camera::COLOR_BUFFER, image.get(), 0, 0);

   // adds the node to the texture camera (this node will be rendered to 
the texture)
   camera->addChild(node);

   // adds the texture camera to the root node
   root->addChild(camera);

If I write this image to file, it works great, I have my "balance" in the 
middle of the image --> see attachment color_buffer.png. Now I would like to 
write the depth buffer to the image (just for debugging, afterward I write it 
to the texture), so I change the following lines:

image->allocateImage(osgViewer->width(), osgViewer->height(), 1, GL_RGBA, 
GL_UNSIGNED_BYTE); --> image->allocateImage(osgViewer->width(), 
osgViewer->height(), 1, GL_DEPTH_COMPONENT, GL_FLOAT);

camera->attach(Camera::COLOR_BUFFER, image.get(), 0, 0); --> 
camera->attach(Camera::DEPTH_BUFFER, image.get(), 0, 0);

After that I get the image depth_buffer.png, but this isn't correct, is it?

The texture looks like this, is it correct?

   // creates the texture for the shadow map
   texShadowMap = new Texture2D;
   texShadowMap->setInternalFormat(GL_DEPTH_COMPONENT);
   texShadowMap->setShadowComparison(true);
   texShadowMap->setShadowTextureMode(Texture2D::LUMINANCE);
   texShadowMap->setFilter(Texture2D::MIN_FILTER, Texture2D::LINEAR);
   texShadowMap->setFilter(Texture2D::MAG_FILTER, Texture2D::LINEAR);
   texShadowMap->setWrap(Texture2D::WRAP_S, Texture2D::CLAMP_TO_BORDER);
   texShadowMap->setWrap(Texture2D::WRAP_T, Texture2D::CLAMP_TO_BORDER);
   texShadowMap->setBorderColor(Vec4(1.0, 1.0, 1.0, 1.0));

What am I doing wrong in this function?

Thanks a lot
Dominic


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

Re: [osg-users] RTT slave views and multi-threading

[Wojciech Lewandowski]

Hi Tugkan,

Robert mentioned lengthy read operation. It may be related to read buffer 
operation thats used to compute shadow volume in 
LightSpacePerpspectiveShadowMapDB. If your slave view uses 
osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if 
osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has the 
same problem.


I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation but 
I could not find quick and easy to implement workaround that would do this 
without scanning the image by CPU. I allocate small 64x64 texture and render 
the scene there, then read it into CPU memory and use CPU to scan pixels to 
optimzie shadow volume from depths and pixel locations strored in this 
prerender image.


Wojtek

- Original Message - 
From: "Robert Osfield" 

To: "OpenSceneGraph Users" 
Sent: Wednesday, January 13, 2010 1:04 PM
Subject: Re: [osg-users] RTT slave views and multi-threading


Hi Tugkan,

The osgdistortion example works a bit like what you are describing,
could you try this to see what performance it's getting.

As for general notes about threading, if you are working on the same
graphics context as you are then all the draw dispatch and the draw
GPU can only be done by a single graphics thread so there is little
opportunity to make it more parallel without using another graphics
card/graphics context and interleaving of frames.

As for why the second camera is very expensive on draw dispatch, this
suggest to me that it's blocking either due to the OpenGL fifo being
full or that it contains a GL read back operation of some kind.

Robert.

On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu  wrote:

Hi All,

I am using a slave view for rendering the scene to a texture. Initially
I tried with a camera node, however, this did not work well due to a
problem in LiSPSM shadows and I was suggested to use RTT slave views.

My setup is as follows: There is a single main view and I attach a slave
view to it. This slave view is attached with addSlave( slave , false );
so that it does *not* automatically use the master scene.

I attach a texture to the slave view and make my scene child of this
view. I attach a screen aligned quad to the main view. This quad
visualizes the RTT texture from the slave view.

Now I have a threading problem which can be seen on the snapshot I
attached. There are two issues:
1- The main view (cam1) has a very large draw time even though it only
renders the screen aligned quad. I double checked to see whether it also
renders the actual scene but this is not the case.

2- Slave view does not run cull and draw in parallel. Cull and draw do
run in parallel if they are not rendered with the slave view. Moreover,
if I change the render order of the slave camera from PRE_RENDER to
POST_RENDER it is ok.

I could simply use POST_RENDER but I am afraid it introduces an extra
one frame latency. If I render the screen aligned quad first and the
scene later than what I see on the quad is the texture from previous
frame (right?).

Any ideas?

cheers,
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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] light lobes and shadow maps

[Wojciech Lewandowski]

Hi Nick,

Post the troublesome code and elaborate a bit more about the problem. If its 
really a minute or two I am sure someone will be able to help.

Wojtek Lewandowski


From: Trajce Nikolov 
Sent: Thursday, January 14, 2010 8:58 PM
To: OpenSceneGraph Users 
Subject: [osg-users] light lobes and shadow maps


Hi community,

I have some shader that does some lighting in the scene. Now studying osgShadow 
and the techniques. I want to a shadow map technique to disable the lightening 
of the scene behind obstacles. I have some code done, but not working. I need 
some help, someone experienced with GLSL to spend a minute or to to have a look 
and if possible to spot the problem. Anyone?

Thanks a lot

Nick

http://www.linkedin.com/in/tnick
Sent from Izmit, 41, Turkey 





___
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] light lobes and shadow maps

[Wojciech Lewandowski]

Trajce,

Attached is a fixed source code. There is a lots of shadow shimmering on my 
GF8800. You will have to add some depth bias while rendering shadow map. 
Selection proper PolygonOffset values is usually a matter of trial and error so 
leave this for you.

Wojtek

- Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Friday, January 15, 2010 9:58 AM
  Subject: Re: [osg-users] light lobes and shadow maps


  ABout the code. I use shader to simulate lght lobes thru phong lighting in 
the shader. Then I use shadow maps to detect the area behind the obstacles that 
need not to be lighten. Most is mixture of shadow maps technique with lighting 
scheme. Code snippets borrowed from all around

  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey 


  On Fri, Jan 15, 2010 at 10:54 AM, Trajce Nikolov  
wrote:

Hi Guys,


here is the code.

Nick

http://www.linkedin.com/in/tnick

Sent from Devlet, Ankara, Turkey 



On Thu, Jan 14, 2010 at 11:42 PM, Wojciech Lewandowski 
 wrote:

  Hi Nick,

  Post the troublesome code and elaborate a bit more about the problem. If 
its really a minute or two I am sure someone will be able to help.

  Wojtek Lewandowski


  From: Trajce Nikolov 
  Sent: Thursday, January 14, 2010 8:58 PM
  To: OpenSceneGraph Users 
  Subject: [osg-users] light lobes and shadow maps


  Hi community,

  I have some shader that does some lighting in the scene. Now studying 
osgShadow and the techniques. I want to a shadow map technique to disable the 
lightening of the scene behind obstacles. I have some code done, but not 
working. I need some help, someone experienced with GLSL to spend a minute or 
to to have a look and if possible to spot the problem. Anyone?

  Thanks a lot

  Nick

  http://www.linkedin.com/in/tnick
  Sent from Izmit, 41, Turkey 


--


  ___
  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
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
 *
 * This application is open source and may be redistributed and/or modified   
 * freely and without restriction, both in commericial and non commericial 
applications,
 * as long as this copyright notice is maintained.
 * 
 * This application is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/

#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 

#if 1
osg::Matrixd createTransformMatrix(double x, double y, double z, double h, 
double p, double r)
{
osg::Matrixd mxR;
mxR.makeRotate(osg::DegreesToRadians(r),osg::Vec3(0,1,0));
osg::Matrixd mxP;
mxP.makeRotate(osg::DegreesToRadians(p),osg::Vec3(1,0,0));
osg::Matrixd mxH;
mxH.makeRotate(osg::DegreesToRadians(h),osg::Vec3(0,0,1));
osg::Matrixd mxT;
mxT.makeTranslate(osg::Vec3(x,y,z));

return (mxR*mxP*mxH*mxT);
}

osg::Node* makeFrustumFromCamera( osg::Camera* camera )
{
// Projection and ModelView matrices
osg::Matrixd proj;
osg::Matrixd mv;
if (camera)
{
proj = camera->getProjectionMatrix();
mv = camera->getViewMatrix();
}
else
{
// Create some kind of reasonable default Projection matrix.
proj.makePerspective( 30., 1., 1., 10. );
// leave mv as identity
}

// Get near and far from the Projection matrix.
const double near = proj(3,2) / (proj(2,2)-1.0);
const double far = proj(3,2) / (1.0+proj(2,2));

// Get the sides of the near plane.
const double nLeft = near * (proj(2,0)-1.0) / proj(0,0);
const double nRight = near * (1.0+proj(2,0)) / proj(0,0);
const double nTop = near * (1.0+proj(2,1)) / proj(1,1);
const double nBottom = near * (proj(2,1)-1.0) / proj(1,1);

// Get the si

Re: [osg-users] light lobes and shadow maps

[Wojciech Lewandowski]

0.0 <= shadow2DProj( shadow_texture, projShadow ).r  <= 1.0 

Shimering is a result of self shadowing. Boosting  depths in shadow map with 
glPolygonOffset usuallly fixes this. There are many schools for PolygonOffset 
settings. I usually set glPolygonOffset( 1.1, 4.0 ) and draw objects with front 
face culling (see StandardShadowMap::ViewData::init(0 for details ).  But for 
this setup models need to work correctly with backface culling on. If you do 
not enforce backface culling PolygonOffset may need different initialization.

Wojtek
 
- Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Friday, January 15, 2010 2:46 PM
  Subject: Re: [osg-users] light lobes and shadow maps


  one more question. What are the possible values for shadow2DProj( 
shadow_texture, projShadow ).r ? I am trying to put the light attenuation back 
. and to avoid the shimmering
  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey 


  On Fri, Jan 15, 2010 at 3:35 PM, Trajce Nikolov  
wrote:

Hey Wojtek  Thanks a lot. !! I will tune it to fix the shimmering



Nick

http://www.linkedin.com/in/tnick



On Fri, Jan 15, 2010 at 3:08 PM, Wojciech Lewandowski 
 wrote:

  Trajce,

  Attached is a fixed source code. There is a lots of shadow shimmering on 
my GF8800. You will have to add some depth bias while rendering shadow map. 
Selection proper PolygonOffset values is usually a matter of trial and error so 
leave this for you.

  Wojtek

  - Original Message - 
From: Trajce Nikolov 
To: OpenSceneGraph Users 
Sent: Friday, January 15, 2010 9:58 AM
Subject: Re: [osg-users] light lobes and shadow maps


ABout the code. I use shader to simulate lght lobes thru phong lighting 
in the shader. Then I use shadow maps to detect the area behind the obstacles 
that need not to be lighten. Most is mixture of shadow maps technique with 
lighting scheme. Code snippets borrowed from all around 

Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey 


On Fri, Jan 15, 2010 at 10:54 AM, Trajce Nikolov 
 wrote:

  Hi Guys, 


  here is the code.

  Nick

  http://www.linkedin.com/in/tnick

  Sent from Devlet, Ankara, Turkey 



  On Thu, Jan 14, 2010 at 11:42 PM, Wojciech Lewandowski 
 wrote:

Hi Nick,

Post the troublesome code and elaborate a bit more about the 
problem. If its really a minute or two I am sure someone will be able to help.

Wojtek Lewandowski


From: Trajce Nikolov 
Sent: Thursday, January 14, 2010 8:58 PM
To: OpenSceneGraph Users 
Subject: [osg-users] light lobes and shadow maps


Hi community,

I have some shader that does some lighting in the scene. Now 
studying osgShadow and the techniques. I want to a shadow map technique to 
disable the lightening of the scene behind obstacles. I have some code done, 
but not working. I need some help, someone experienced with GLSL to spend a 
minute or to to have a look and if possible to spot the problem. Anyone?

Thanks a lot

Nick

http://www.linkedin.com/in/tnick
Sent from Izmit, 41, Turkey 





___
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] light lobes and shadow maps

[Wojciech Lewandowski]

Hi,

Light close to obstacles ? If you have COMPUTE_NEAR_FAR it may clamp near plane 
to very small value which may impact depth resolution. Other issue maybe 
related to GLSL float precision. The trick with multiplying view space coord by 
inverse view matrix to get world coord is performed on float values inside 
GLSL.  Precision wise it would be better to multiply light camera MVP matrix by 
main camera INVERSE VIEW on the CPU. Osg Matrices use  doubles. Put the result 
of the multiplication on GLSL matrix Uniform and use it to multiply gl_Vertex 
in the shader. Such approach multiplies matrices with high precision and 
resulting matrix will be better suited to be cast on single prec. GLSL matrix. 
The drawback of this solution is: you need to update the uniform every frame, 
because main camera view changes with each move. 

Wojtek



From: Trajce Nikolov 
Sent: Friday, January 15, 2010 7:37 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] light lobes and shadow maps


Hi Wojtek, 


now I spent more time exploring this, the polyoffset seam to work, but there is 
still a bit of shimmering. Its interesting, I put the light source in move, 
when it moves backwards, the obstacles are lighten ok, but forward, when the 
light comes close to the obstacles, the lighting is incorrect with shimmering . 
Any clue how to resolve this artifact ?

Nick

http://www.linkedin.com/in/tnick



On Fri, Jan 15, 2010 at 4:48 PM, Trajce Nikolov  
wrote:

  ok .. make sense. Here is updated code, if some one wants to benefit from. 
LightLobes with handling of obstacles :). Thanks to Wojiech, Robert and the 
online community 

  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey 


  On Fri, Jan 15, 2010 at 3:53 PM, Wojciech Lewandowski  
wrote:

0.0 <= shadow2DProj( shadow_texture, projShadow ).r  <= 1.0 

Shimering is a result of self shadowing. Boosting  depths in shadow map 
with glPolygonOffset usuallly fixes this. There are many schools for 
PolygonOffset settings. I usually set glPolygonOffset( 1.1, 4.0 ) and draw 
objects with front face culling (see StandardShadowMap::ViewData::init(0 for 
details ).  But for this setup models need to work correctly with backface 
culling on. If you do not enforce backface culling PolygonOffset may need 
different initialization.

Wojtek

- Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Friday, January 15, 2010 2:46 PM
  Subject: Re: [osg-users] light lobes and shadow maps


  one more question. What are the possible values for shadow2DProj( 
shadow_texture, projShadow ).r ? I am trying to put the light attenuation back 
. and to avoid the shimmering
  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey 


  On Fri, Jan 15, 2010 at 3:35 PM, Trajce Nikolov 
 wrote:

Hey Wojtek  Thanks a lot. !! I will tune it to fix the shimmering 



Nick

http://www.linkedin.com/in/tnick



On Fri, Jan 15, 2010 at 3:08 PM, Wojciech Lewandowski 
 wrote:

  Trajce,

  Attached is a fixed source code. There is a lots of shadow shimmering 
on my GF8800. You will have to add some depth bias while rendering shadow map. 
Selection proper PolygonOffset values is usually a matter of trial and error so 
leave this for you.

  Wojtek

  - Original Message - 
From: Trajce Nikolov 
To: OpenSceneGraph Users 
Sent: Friday, January 15, 2010 9:58 AM
Subject: Re: [osg-users] light lobes and shadow maps


ABout the code. I use shader to simulate lght lobes thru phong 
lighting in the shader. Then I use shadow maps to detect the area behind the 
obstacles that need not to be lighten. Most is mixture of shadow maps technique 
with lighting scheme. Code snippets borrowed from all around 

Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey 


On Fri, Jan 15, 2010 at 10:54 AM, Trajce Nikolov 
 wrote:

  Hi Guys, 


  here is the code.

  Nick

  http://www.linkedin.com/in/tnick

  Sent from Devlet, Ankara, Turkey 



  On Thu, Jan 14, 2010 at 11:42 PM, Wojciech Lewandowski 
 wrote:

Hi Nick,

Post the troublesome code and elaborate a bit more about the 
problem. If its really a minute or two I am sure someone will be able to help.

Wojtek Lewandowski


From: Trajce Nikolov 
Sent: Thursday, January 14, 2010 8:58 PM
To: OpenSceneGraph Users 
Subject: [osg-users] light lobes and shadow maps


Hi community,

I have some shader that does some lighting in the scene. Now 
studying osgShadow and the techniques. I want to a shadow map technique to 
disable the ligh

Re: [osg-users] light lobes and shadow maps

[Wojciech Lewandowski]

Nick,

I may look into the code but don't expect much this time.  You need to attach 
the code first, though ;-). Few academy guys wrote couple dissertations on 
rasterization and aliasing errors in shadow mapping. Unless you try to do some 
exotic stuff like variance or logarithmic map you will have to use polygon 
offset. I guess you will end up to cranking up PolygonOfset even more if 
current values fail at some distance.  I don't really have other tricks in my 
sleeve.  

Wojtek



From: Trajce Nikolov 
Sent: Friday, January 15, 2010 9:08 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] light lobes and shadow maps


That is exactly what I did. Please have a look at the updated code. The uniform 
is updated thru a callback and it multiplies the matrices, still there is a 
visual artifact.I dont have compute_near_far. The projection matrix is fixed 
with very small far plane (100 units, with the znear of 0.01). 

Nick

http://www.linkedin.com/in/tnick



On Fri, Jan 15, 2010 at 9:47 PM, Wojciech Lewandowski  
wrote:

  Hi,

  Light close to obstacles ? If you have COMPUTE_NEAR_FAR it may clamp near 
plane to very small value which may impact depth resolution. Other issue maybe 
related to GLSL float precision. The trick with multiplying view space coord by 
inverse view matrix to get world coord is performed on float values inside 
GLSL.  Precision wise it would be better to multiply light camera MVP matrix by 
main camera INVERSE VIEW on the CPU. Osg Matrices use  doubles. Put the result 
of the multiplication on GLSL matrix Uniform and use it to multiply gl_Vertex 
in the shader. Such approach multiplies matrices with high precision and 
resulting matrix will be better suited to be cast on single prec. GLSL matrix. 
The drawback of this solution is: you need to update the uniform every frame, 
because main camera view changes with each move. 

  Wojtek



  From: Trajce Nikolov 
  Sent: Friday, January 15, 2010 7:37 PM
  To: OpenSceneGraph Users 
  Subject: Re: [osg-users] light lobes and shadow maps


  Hi Wojtek, 


  now I spent more time exploring this, the polyoffset seam to work, but there 
is still a bit of shimmering. Its interesting, I put the light source in move, 
when it moves backwards, the obstacles are lighten ok, but forward, when the 
light comes close to the obstacles, the lighting is incorrect with shimmering . 
Any clue how to resolve this artifact ?

  Nick

  http://www.linkedin.com/in/tnick



  On Fri, Jan 15, 2010 at 4:48 PM, Trajce Nikolov  
wrote:

ok .. make sense. Here is updated code, if some one wants to benefit from. 
LightLobes with handling of obstacles :). Thanks to Wojiech, Robert and the 
online community 

Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey 


On Fri, Jan 15, 2010 at 3:53 PM, Wojciech Lewandowski 
 wrote:

  0.0 <= shadow2DProj( shadow_texture, projShadow ).r  <= 1.0 

  Shimering is a result of self shadowing. Boosting  depths in shadow map 
with glPolygonOffset usuallly fixes this. There are many schools for 
PolygonOffset settings. I usually set glPolygonOffset( 1.1, 4.0 ) and draw 
objects with front face culling (see StandardShadowMap::ViewData::init(0 for 
details ).  But for this setup models need to work correctly with backface 
culling on. If you do not enforce backface culling PolygonOffset may need 
different initialization.

  Wojtek

  - Original Message - 
From: Trajce Nikolov 
To: OpenSceneGraph Users 
Sent: Friday, January 15, 2010 2:46 PM
Subject: Re: [osg-users] light lobes and shadow maps


one more question. What are the possible values for shadow2DProj( 
shadow_texture, projShadow ).r ? I am trying to put the light attenuation back 
. and to avoid the shimmering
Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey 


On Fri, Jan 15, 2010 at 3:35 PM, Trajce Nikolov 
 wrote:

  Hey Wojtek  Thanks a lot. !! I will tune it to fix the shimmering 



  Nick

  http://www.linkedin.com/in/tnick



  On Fri, Jan 15, 2010 at 3:08 PM, Wojciech Lewandowski 
 wrote:

Trajce,

Attached is a fixed source code. There is a lots of shadow 
shimmering on my GF8800. You will have to add some depth bias while rendering 
shadow map. Selection proper PolygonOffset values is usually a matter of trial 
and error so leave this for you.

Wojtek

- Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Friday, January 15, 2010 9:58 AM
  Subject: Re: [osg-users] light lobes and shadow maps


  ABout the code. I use shader to simulate lght lobes thru phong 
lighting in the shader. Then I use shadow maps to detect the area behind the 
obstacles that need not to be lighten. Most is mixture of shadow maps

Re: [osg-users] light lobes and shadow maps

[Wojciech Lewandowski]

Google for Shadow Maps. You will come up with a number of techniques. Few of 
them:

http://www.punkuser.net/vsm/

http://gamma.cs.unc.edu/LOGPSM/

http://developer.download.nvidia.com/presentations/2008/GDC/GDC08_SoftShadowMapping.pdf

Most of these belong to the family of soft shadow algorithms. Soft shadows 
usually oversample depth texel and produce some average shadow term. Clamping 
this term to 0 if value is below certain threshold (for example <0.25) usually 
removes some of self shadowing artifacts.

I will have the second look on the code but not today.
  
Wojtek


From: Trajce Nikolov 
Sent: Friday, January 15, 2010 10:16 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] light lobes and shadow maps


do you have some pointers, papers to the work of this guys? I am interested in 
learning what is that about
Nick

http://www.linkedin.com/in/tnick
Sent from Ünalan, İstanbul, Turkey 


On Fri, Jan 15, 2010 at 11:01 PM, Wojciech Lewandowski  
wrote:

  Nick,

  I may look into the code but don't expect much this time.  You need to attach 
the code first, though ;-). Few academy guys wrote couple dissertations on 
rasterization and aliasing errors in shadow mapping. Unless you try to do some 
exotic stuff like variance or logarithmic map you will have to use polygon 
offset. I guess you will end up to cranking up PolygonOfset even more if 
current values fail at some distance.  I don't really have other tricks in my 
sleeve.  

  Wojtek



  From: Trajce Nikolov 
  Sent: Friday, January 15, 2010 9:08 PM
  To: OpenSceneGraph Users 
  Subject: Re: [osg-users] light lobes and shadow maps


  That is exactly what I did. Please have a look at the updated code. The 
uniform is updated thru a callback and it multiplies the matrices, still there 
is a visual artifact.I dont have compute_near_far. The projection matrix is 
fixed with very small far plane (100 units, with the znear of 0.01). 

  Nick

  http://www.linkedin.com/in/tnick



  On Fri, Jan 15, 2010 at 9:47 PM, Wojciech Lewandowski  
wrote:

Hi,

Light close to obstacles ? If you have COMPUTE_NEAR_FAR it may clamp near 
plane to very small value which may impact depth resolution. Other issue maybe 
related to GLSL float precision. The trick with multiplying view space coord by 
inverse view matrix to get world coord is performed on float values inside 
GLSL.  Precision wise it would be better to multiply light camera MVP matrix by 
main camera INVERSE VIEW on the CPU. Osg Matrices use  doubles. Put the result 
of the multiplication on GLSL matrix Uniform and use it to multiply gl_Vertex 
in the shader. Such approach multiplies matrices with high precision and 
resulting matrix will be better suited to be cast on single prec. GLSL matrix. 
The drawback of this solution is: you need to update the uniform every frame, 
because main camera view changes with each move. 

Wojtek



From: Trajce Nikolov 
Sent: Friday, January 15, 2010 7:37 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] light lobes and shadow maps


Hi Wojtek, 


now I spent more time exploring this, the polyoffset seam to work, but 
there is still a bit of shimmering. Its interesting, I put the light source in 
move, when it moves backwards, the obstacles are lighten ok, but forward, when 
the light comes close to the obstacles, the lighting is incorrect with 
shimmering . Any clue how to resolve this artifact ?

Nick

http://www.linkedin.com/in/tnick



On Fri, Jan 15, 2010 at 4:48 PM, Trajce Nikolov  
wrote:

  ok .. make sense. Here is updated code, if some one wants to benefit 
from. LightLobes with handling of obstacles :). Thanks to Wojiech, Robert and 
the online community 

  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey 


  On Fri, Jan 15, 2010 at 3:53 PM, Wojciech Lewandowski 
 wrote:

0.0 <= shadow2DProj( shadow_texture, projShadow ).r  <= 1.0 

Shimering is a result of self shadowing. Boosting  depths in shadow map 
with glPolygonOffset usuallly fixes this. There are many schools for 
PolygonOffset settings. I usually set glPolygonOffset( 1.1, 4.0 ) and draw 
objects with front face culling (see StandardShadowMap::ViewData::init(0 for 
details ).  But for this setup models need to work correctly with backface 
culling on. If you do not enforce backface culling PolygonOffset may need 
different initialization.

Wojtek

- Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Friday, January 15, 2010 2:46 PM
  Subject: Re: [osg-users] light lobes and shadow maps


  one more question. What are the possible values for shadow2DProj( 
shadow_texture, projShadow ).r ? I am trying to put the light attenuation back 
. and to avoid the shimmering
  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey 


  

Re: [osg-users] glsl mix

[Wojciech Lewandowski]

Nick,

GLSL mix works on my GF280. And I bet it works right everywhere. I changed 
your code to


" cube_color = vec3( 0,1,1 ); \n"
" base_color = vec3( 1,0,0 ); \n"
" gl_FragColor = vec4( mix(cube_color, base_color, reflect_factor).rgb,
1.0); \n"

and resulting sphere color is light gray as expected. I guess your problem 
must be somewhere else in your code...


Wojtek





From: Trajce Nikolov
Sent: Saturday, January 23, 2010 11:42 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] glsl mix


Here is attached code ... Would really appreciate if some take couple of
minutes to have a look


Thanks a lot
Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey


On Sat, Jan 23, 2010 at 11:44 PM, Trajce Nikolov 
wrote:

I am also getting this warning
Warning: detected OpenGL error 'invalid operation' at after
RenderBin::draw(..)

Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey


On Sat, Jan 23, 2010 at 9:50 PM, Trajce Nikolov 
wrote:

Hi guys,


this might sound stupid but., I am trying to mix two values in the fragment
shader. Can not blend them together no mater what. I try "manual" blending,
but still the results are as for only 1 and 0 blend factor. NOthing in
between,


Here is the shader. Any clue?


"varying vec4 uv; \n" //
"uniform sampler2D colorMap; \n" //
"uniform samplerCube cubeMap; \n" //
"const float reflect_factor = 0.5; \n" //
"void main( void ) \n" //
"{  \n" //
" vec3 base_color = texture2D(colorMap, gl_TexCoord[0].xy).rgb; \n" //
" vec3 cube_color = textureCube(cubeMap, uv.xyz).rgb; \n" //
" gl_FragColor = vec4( mix(base_color, cube_color, reflect_factor), 1.0);
\n" //
"}


Nick

http://www.linkedin.com/in/tnick
Sent from Devlet, Ankara, Turkey







___
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] glsl mix

[Wojciech Lewandowski]

Indeed. Replacing order of sampler lookups ie swapping 2 first lines of shader 
gives different results as well. Looks like a Driver bug...  
I am using Windows 7 64 bit Ge Force driver 191.07. I am curious what will 
happen on ATI or XP drivers. 

Wojtek Lewandowski


From: Trajce Nikolov 
Sent: Sunday, January 24, 2010 11:39 AM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] glsl mix


Hi Wojtek, 


when setting it like this I get the right results. When obtaing the values from 
textures, it doesnt.  I saw in the archive someone else had the same problem. 
And I know, it sound odd :). I am using mix in other shaders and there it works 
as well. But not in this case



Nick

http://www.linkedin.com/in/tnick
Sent from Ünalan, İstanbul, Turkey 


On Sun, Jan 24, 2010 at 11:42 AM, Wojciech Lewandowski  
wrote:

  Nick,

  GLSL mix works on my GF280. And I bet it works right everywhere. I changed 
your code to

  " cube_color = vec3( 0,1,1 ); \n"
  " base_color = vec3( 1,0,0 ); \n"
  " gl_FragColor = vec4( mix(cube_color, base_color, reflect_factor).rgb,
  1.0); \n"

  and resulting sphere color is light gray as expected. I guess your problem 
must be somewhere else in your code...

  Wojtek





  From: Trajce Nikolov
  Sent: Saturday, January 23, 2010 11:42 PM
  To: OpenSceneGraph Users
  Subject: Re: [osg-users] glsl mix 



  Here is attached code ... Would really appreciate if some take couple of
  minutes to have a look


  Thanks a lot
  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey


  On Sat, Jan 23, 2010 at 11:44 PM, Trajce Nikolov 
  wrote:

  I am also getting this warning
  Warning: detected OpenGL error 'invalid operation' at after
  RenderBin::draw(..)

  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey


  On Sat, Jan 23, 2010 at 9:50 PM, Trajce Nikolov 
  wrote:

  Hi guys,


  this might sound stupid but., I am trying to mix two values in the fragment
  shader. Can not blend them together no mater what. I try "manual" blending,
  but still the results are as for only 1 and 0 blend factor. NOthing in
  between,


  Here is the shader. Any clue?


  "varying vec4 uv; \n" //
  "uniform sampler2D colorMap; \n" //
  "uniform samplerCube cubeMap; \n" //
  "const float reflect_factor = 0.5; \n" //
  "void main( void ) \n" //
  "{  \n" //
  " vec3 base_color = texture2D(colorMap, gl_TexCoord[0].xy).rgb; \n" //
  " vec3 cube_color = textureCube(cubeMap, uv.xyz).rgb; \n" //
  " gl_FragColor = vec4( mix(base_color, cube_color, reflect_factor), 1.0);
  \n" //
  "}


  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey








  ___
  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] glsl mix

[Wojciech Lewandowski]

I also made a test on Radeon 5890 64 bit Vista. Also wrong results. However its 
bit different than on NVIidia because it looks like base texture does not get 
read at all. I really doubt this case is simply an issue with mixing CubeMap / 
Tex2D fetches. I suspect there are other factors involved (like fact that cube 
map is rendered on the fly) but do not have time to trace it...

Wojtek
  - Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Monday, January 25, 2010 12:30 PM
  Subject: Re: [osg-users] glsl mix


  Hi Jp.


  so you are saying you see the images blended  but still getting a 
warning. That is good result. I guess this points to be really a driver issue.


  Thanks for finding a time to test this!

  Nick

  http://www.linkedin.com/in/tnick
  Sent from Kordel, RP, Germany 


  On Mon, Jan 25, 2010 at 9:19 AM, J.P. Delport  wrote:

Hi,

seems to work on Linux 32-bit NVidia GeForce Go 7400, driver 190.53. Also 
same on GTS250, driver 190.53. I've tried different factors and it made a 
change in the output. I do get:

Warning: detected OpenGL error 'invalid operation' at After 
Renderer::compile

on both machines.

jp

Trajce Nikolov wrote:

  Here is attached code ... Would really appreciate if some take couple of 
minutes to have a look 
  Thanks a lot
  Nick

  http://www.linkedin.com/in/tnick
  Sent from Devlet, Ankara, Turkey


  On Sat, Jan 23, 2010 at 11:44 PM, Trajce Nikolov 
mailto:nikolov.tra...@gmail.com>> wrote:

 I am also getting this warning
 Warning: detected OpenGL error 'invalid operation' at after
 RenderBin::draw(..)

 Nick

 http://www.linkedin.com/in/tnick
 Sent from Devlet, Ankara, Turkey

 On Sat, Jan 23, 2010 at 9:50 PM, Trajce Nikolov

 mailto:nikolov.tra...@gmail.com>> wrote:

 Hi guys,

 this might sound stupid but., I am trying to mix two values in
 the fragment shader. Can not blend them together no mater what.
 I try "manual" blending, but still the results are as for only 1
 and 0 blend factor. NOthing in between,

 Here is the shader. Any clue?

 "varying vec4 uv; \n" //
 "uniform sampler2D colorMap; \n" //
 "uniform samplerCube cubeMap; \n" //
 "const float reflect_factor = 0.5; \n" //
 "void main( void ) \n" //
 "{ 
\n" //
 " vec3 base_color = texture2D(colorMap, gl_TexCoord[0].xy).rgb;
 \n" //
 " vec3 cube_color = textureCube(cubeMap, uv.xyz).rgb; \n" //
 " gl_FragColor = vec4( mix(base_color, cube_color,
 reflect_factor), 1.0); \n" //
 "}

 Nick

 http://www.linkedin.com/in/tnick
 Sent from Devlet, Ankara, Turkey





  


  ___
  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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] light lobes and shadow maps

[Wojciech Lewandowski]

That looks like shadow texture or shadow texcoords being out of sync by one 
frame. Most probably main camera view matrix from former frame is used to setup 
shadow coord tex generation. 

Wojtek 
- Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Wednesday, January 27, 2010 4:20 PM
  Subject: Re: [osg-users] light lobes and shadow maps


  Looks like its really the order of updating things. I moved the movement from 
the update callback and place it outside the frame loop, so the next frame 
everything is in place.


  Attached is the latest code if someone is interested in light lobes working 
with obstacles

  Nick

  http://www.linkedin.com/in/tnick



  On Wed, Jan 27, 2010 at 4:59 PM, Trajce Nikolov  
wrote:

Hi again on this topic.


here is the issue. When I have the camera static, no matter how close to 
the obstacles, all is rendered it should, no artifacts. When I move the camera, 
it shows artifact. I have set the camera to not compute znear and zfar. What 
can affect this change when moving and not moving?

Nick

http://www.linkedin.com/in/tnick



On Sat, Jan 16, 2010 at 1:48 PM, Trajce Nikolov  
wrote:

  Hi Wojtech,


  thanks for the links. I will do some research.


  I think I have fixed that. It turned out is the order of updating 
entities in the scene. The "lightlobe" camera was updated before updating the 
light itself, thats why different behavior based on the direction of movement.


  I think I will go further with this, to implement something for number of 
lights.


  Thanks again !

  Nick

  http://www.linkedin.com/in/tnick



  On Sat, Jan 16, 2010 at 9:59 AM, Wojciech Lewandowski 
 wrote:

Google for Shadow Maps. You will come up with a number of techniques. 
Few of them:

http://www.punkuser.net/vsm/

http://gamma.cs.unc.edu/LOGPSM/


http://developer.download.nvidia.com/presentations/2008/GDC/GDC08_SoftShadowMapping.pdf

Most of these belong to the family of soft shadow algorithms. Soft 
shadows usually oversample depth texel and produce some average shadow term. 
Clamping this term to 0 if value is below certain threshold (for example <0.25) 
usually removes some of self shadowing artifacts.

I will have the second look on the code but not today.
  
Wojtek


From: Trajce Nikolov 
Sent: Friday, January 15, 2010 10:16 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] light lobes and shadow maps


do you have some pointers, papers to the work of this guys? I am 
interested in learning what is that about
Nick

http://www.linkedin.com/in/tnick
Sent from Ünalan, İstanbul, Turkey 


On Fri, Jan 15, 2010 at 11:01 PM, Wojciech Lewandowski 
 wrote:

  Nick,

  I may look into the code but don't expect much this time.  You need 
to attach the code first, though ;-). Few academy guys wrote couple 
dissertations on rasterization and aliasing errors in shadow mapping. Unless 
you try to do some exotic stuff like variance or logarithmic map you will have 
to use polygon offset. I guess you will end up to cranking up PolygonOfset even 
more if current values fail at some distance.  I don't really have other tricks 
in my sleeve.  

  Wojtek



  From: Trajce Nikolov 
  Sent: Friday, January 15, 2010 9:08 PM
  To: OpenSceneGraph Users 
  Subject: Re: [osg-users] light lobes and shadow maps


  That is exactly what I did. Please have a look at the updated code. 
The uniform is updated thru a callback and it multiplies the matrices, still 
there is a visual artifact.I dont have compute_near_far. The projection matrix 
is fixed with very small far plane (100 units, with the znear of 0.01). 

  Nick

  http://www.linkedin.com/in/tnick



  On Fri, Jan 15, 2010 at 9:47 PM, Wojciech Lewandowski 
 wrote:

Hi,

Light close to obstacles ? If you have COMPUTE_NEAR_FAR it may 
clamp near plane to very small value which may impact depth resolution. Other 
issue maybe related to GLSL float precision. The trick with multiplying view 
space coord by inverse view matrix to get world coord is performed on float 
values inside GLSL.  Precision wise it would be better to multiply light camera 
MVP matrix by main camera INVERSE VIEW on the CPU. Osg Matrices use  doubles. 
Put the result of the multiplication on GLSL matrix Uniform and use it to 
multiply gl_Vertex in the shader. Such approach multiplies matrices with high 
precision and resulting matrix will be better suited to be cast on single prec. 
GLSL matrix. The drawback of this solution is: you need to update the uniform 
every frame, because main camera view changes with each move. 

Wojtek



From: Trajce Nikolov 
Sent: Friday, January 15, 2010

Re: [osg-users] uniform update question

[Wojciech Lewandowski]

Hi Manu,

IMHO I can offfer tips for 2 or your questions: 

Why no cull calback for uniform ?
I guess there is no cull calback for state attribs/uniforms because they could 
be used many times and located in many statesets/nodes. So cull visitor can 
traverse them couple times per one frame.

How to obtain master camera view matrix ?
In ViewDependentShadowTechniques I used following method to obtain master view 
or slave view camera:
cullVisitor->getRenderStage()->getCamera() 

Depending on your setup of extra cameras it may wortk or not, but I guess you 
could try it.

Cheers,
Wojtek Lewandowski
 

  - Original Message - 
  From: Emmanuel Roche 
  To: OSG Users 
  Sent: Friday, January 29, 2010 1:08 PM
  Subject: [osg-users] uniform update question


  Hi everyone,

  I'm facing a problem I cannot solve by myself here, I thought I could just 
ask:

  - I have a scene (so a scene graph)
  - I use multiple View on this single scene

  --> Currently I have an "homemade" mixture of customized osgViewer::Viewer 
objects to deal with everything so basically, for each View, I go through a 
complete (EventTraversal(), UpdateTraversal(), RenderingTraversals() ) loop 
sequentially.

  - Now I would like to switch to a CompositeViewer and thus go through the 
event/update traversals only once per Scene (If I understand the 
CompositeViewer design properly).

  But I have a very specific problem to solve here:

  In my scene graph I use shaders and uniforms. those uniforms have update 
callbacks, and in those update callbacks, I retrieve my currently rendering 
View and then the View matrix to generate eye coordinates.

  --> I assume using the osg_ViewMatrix uniform is not an option for me because 
I need to convert very big position vector and very big view matrix 
translation, and I would clearly get a problem here if I don't have double 
precision. 
  --> With the CompositeViewer I can't access the individual "View" anymore in 
the update traversal() since this process is "View agnostic" I would say.


  --> Since my views will need different settings for the uniforms, I was 
thinking I would just need to do something in the cull traversal, but here I 
realized something which seems strange to me: there is no such method as 
uniform::setCullCallback(...) 

  So, the question is, how would you update your uniforms properly in that case 
?

  I mean, I could still put a cullcallback on the node owning the stateset 
containing the uniform for instance and "update" from here (assuming I can 
retrieve the Viewmatrix I need somehow in that Cullcallback...) but is this 
really the best option ??

  - And generally speaking, would a uniform::setCullCallback() not make sense 
for some reason I'm apparently missing for now ?

  Bonus question by the way: How would I access the "master camera" ViewMatrix 
in a cullcallback ? i've seen we have osgUtil::CullVisitor::getCurrentCamera() 
but would this return the Master camera of the View or just the current camera 
in the scene graph (as I use DepthPartitionNode I have many sub cameras in my 
scene...)

  Thanks in advance is someone has any tip/advise/complete solution on those 
questions!

  Regards,
  Manu.




--


  ___
  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] uniform update question

[Wojciech Lewandowski]

Hi Manu,

I always thought update callback gets called only once. Update visitor differs 
from cull visitor in this regard. 

Wojtek

  - Original Message - 
  From: Emmanuel Roche 
  To: OpenSceneGraph Users 
  Sent: Friday, January 29, 2010 3:01 PM
  Subject: Re: [osg-users] uniform update question


  Hello Wojtek,

  thanks for the tips !!
  I will try with getRenderStage()->getCamera() and let you know if it works 
for me too.

  But concerning the cull callback for uniforms, isn't it already the case for 
the update callback you can put on them ? (if you use the same uniform in 
multiple statesets/nodes, then the update callback is called multiple times per 
frame... [or is there some kind of "security system" to prevent this I'm not 
aware of ? ]

  Cheers,
  Manu.



  2010/1/29 Wojciech Lewandowski 

Hi Manu,

IMHO I can offfer tips for 2 or your questions: 

Why no cull calback for uniform ?
I guess there is no cull calback for state attribs/uniforms because they 
could be used many times and located in many statesets/nodes. So cull visitor 
can traverse them couple times per one frame.

How to obtain master camera view matrix ?
In ViewDependentShadowTechniques I used following method to obtain master 
view or slave view camera:
cullVisitor->getRenderStage()->getCamera() 

Depending on your setup of extra cameras it may wortk or not, but I guess 
you could try it.

Cheers,
Wojtek Lewandowski


  - Original Message - 
  From: Emmanuel Roche 
  To: OSG Users 
  Sent: Friday, January 29, 2010 1:08 PM
  Subject: [osg-users] uniform update question


  Hi everyone,

  I'm facing a problem I cannot solve by myself here, I thought I could 
just ask:

  - I have a scene (so a scene graph)
  - I use multiple View on this single scene

  --> Currently I have an "homemade" mixture of customized 
osgViewer::Viewer objects to deal with everything so basically, for each View, 
I go through a complete (EventTraversal(), UpdateTraversal(), 
RenderingTraversals() ) loop sequentially.

  - Now I would like to switch to a CompositeViewer and thus go through the 
event/update traversals only once per Scene (If I understand the 
CompositeViewer design properly).

  But I have a very specific problem to solve here:

  In my scene graph I use shaders and uniforms. those uniforms have update 
callbacks, and in those update callbacks, I retrieve my currently rendering 
View and then the View matrix to generate eye coordinates.

  --> I assume using the osg_ViewMatrix uniform is not an option for me 
because I need to convert very big position vector and very big view matrix 
translation, and I would clearly get a problem here if I don't have double 
precision. 
  --> With the CompositeViewer I can't access the individual "View" anymore 
in the update traversal() since this process is "View agnostic" I would say.


  --> Since my views will need different settings for the uniforms, I was 
thinking I would just need to do something in the cull traversal, but here I 
realized something which seems strange to me: there is no such method as 
uniform::setCullCallback(...) 

  So, the question is, how would you update your uniforms properly in that 
case ?

  I mean, I could still put a cullcallback on the node owning the stateset 
containing the uniform for instance and "update" from here (assuming I can 
retrieve the Viewmatrix I need somehow in that Cullcallback...) but is this 
really the best option ??

  - And generally speaking, would a uniform::setCullCallback() not make 
sense for some reason I'm apparently missing for now ?

  Bonus question by the way: How would I access the "master camera" 
ViewMatrix in a cullcallback ? i've seen we have 
osgUtil::CullVisitor::getCurrentCamera() but would this return the Master 
camera of the View or just the current camera in the scene graph (as I use 
DepthPartitionNode I have many sub cameras in my scene...)

  Thanks in advance is someone has any tip/advise/complete solution on 
those questions!

  Regards,
  Manu.




--


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

[osg-users] Lets slowly update extension gl symbols to latest OpenGL specification with each submission.

[Wojciech Lewandowski]

Hi Everyone,

Lots of older OpenGL extensions are now included in OpenGL specification (rel. 
3.2). I'd like to propose a small cleaning movement of OSG sources
 
Every time we submit a change of some OSG file we could also check for obsolete 
GL extension:  EXT, ARB, NV, ATI etc symbols and replace them with most current 
OpenGL names.

Idea is to take it easy and slow. Lets change only these header and source 
files which would get submitted anyways. Changing and submitting all OSG source 
at once could easily swamp Robert.

Cheers,
Wojtek Lewandowski


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

Re: [osg-users] Lets slowly update extension gl symbols tolatestOpenGL specification with each submission.

[Wojciech Lewandowski]

Hi Gordon,

What about when I'm on a machine and graphics card that only supports say 
OpenGL 2.1,  

I guess this is an argument for reverse approach ie  to use common denominator 
and use extension versions in their earliest forms 
It is a valid point, I must admit I have not thought about it. Maybe chnging 
_EXT, _ARB  to non suffix versions is not such a good idea after all. Maybe it 
was too early to come up with this proposal... 

Wojtek


- Original Message - 
  From: Tomlinson, Gordon 
  To: OpenSceneGraph Users 
  Sent: Monday, February 01, 2010 2:47 PM
  Subject: Re: [osg-users] Lets slowly update extension gl symbols 
tolatestOpenGL specification with each submission.


  Would these only be obsolete if your using Opengl 3.2 ?

  What about when I'm on a machine and graphics card that only supports say 
OpenGL 2.1,  

  this is a very common case for us were users are in very controlled 
environments and running on older equipment that is unlikely to get upgraded or 
new drivers etc.

  Gordon Tomlinson
  Product Manager 3d Technology & Future Products
  Overwatch®
  An Operating Unit of Textron Systems




--
  From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wojciech 
Lewandowski
  Sent: Monday, February 01, 2010 6:24 AM
  To: osg-users@lists.openscenegraph.org
  Subject: [osg-users] Lets slowly update extension gl symbols to latestOpenGL 
specification with each submission.


  Hi Everyone,

  Lots of older OpenGL extensions are now included in OpenGL specification 
(rel. 3.2). I'd like to propose a small cleaning movement of OSG sources

  Every time we submit a change of some OSG file we could also check for 
obsolete GL extension:  EXT, ARB, NV, ATI etc symbols and replace them with 
most current OpenGL names.

  Idea is to take it easy and slow. Lets change only these header and source 
files which would get submitted anyways. Changing and submitting all OSG source 
at once could easily swamp Robert.

  Cheers,
  Wojtek Lewandowski





--


  ___
  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] Lets slowly update extension glsymbolstolatestOpenGL specification with each submission.

[Wojciech Lewandowski]

The longer I think of it the more I agree with your earlier post. I realized we 
could start such extension cleanning but only if OSG had defined bottom line 
requiremnt for OGL version. As long as its not clealy defined, such clean up 
practice may be more problematic than frutiful. 

Wojtek

- Original Message - 
  From: Tomlinson, Gordon 
  To: OpenSceneGraph Users 
  Sent: Monday, February 01, 2010 4:30 PM
  Subject: Re: [osg-users] Lets slowly update extension glsymbolstolatestOpenGL 
specification with each submission.


  Nothing against the proposal, simplification and clean up is good ...

  I just know I fall into the situation where large groups of my end users will 
be on what we thinks of as very old cards ( and where they cannot update or 
update easily ) and my paranoia then takes me down the road of oh heck  :)


  Gordon Tomlinson
  Product Manager 3d Technology & Future Products
  Overwatch®
  An Operating Unit of Textron Systems




--
  From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wojciech 
Lewandowski
  Sent: Monday, February 01, 2010 10:24 AM
  To: OpenSceneGraph Users
  Subject: Re: [osg-users] Lets slowly update extension gl 
symbolstolatestOpenGL specification with each submission.


  Hi Gordon,

  What about when I'm on a machine and graphics card that only supports say 
OpenGL 2.1,  

  I guess this is an argument for reverse approach ie  to use common 
denominator and use extension versions in their earliest forms 
  It is a valid point, I must admit I have not thought about it. Maybe chnging 
_EXT, _ARB  to non suffix versions is not such a good idea after all. Maybe it 
was too early to come up with this proposal... 

  Wojtek


  - Original Message - 
From: Tomlinson, Gordon 
To: OpenSceneGraph Users 
Sent: Monday, February 01, 2010 2:47 PM
Subject: Re: [osg-users] Lets slowly update extension gl symbols 
tolatestOpenGL specification with each submission.


Would these only be obsolete if your using Opengl 3.2 ?

What about when I'm on a machine and graphics card that only supports say 
OpenGL 2.1,  

this is a very common case for us were users are in very controlled 
environments and running on older equipment that is unlikely to get upgraded or 
new drivers etc.

Gordon Tomlinson
Product Manager 3d Technology & Future Products
Overwatch®
An Operating Unit of Textron Systems





From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wojciech 
Lewandowski
Sent: Monday, February 01, 2010 6:24 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Lets slowly update extension gl symbols to 
latestOpenGL specification with each submission.


Hi Everyone,

Lots of older OpenGL extensions are now included in OpenGL specification 
(rel. 3.2). I'd like to propose a small cleaning movement of OSG sources

Every time we submit a change of some OSG file we could also check for 
obsolete GL extension:  EXT, ARB, NV, ATI etc symbols and replace them with 
most current OpenGL names.

Idea is to take it easy and slow. Lets change only these header and source 
files which would get submitted anyways. Changing and submitting all OSG source 
at once could easily swamp Robert.

Cheers,
Wojtek Lewandowski








___
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] osgCandidate::VirtualProgram performance

[Wojciech Lewandowski]

Hi Nick, 

I am curious whether this slowdown is due to CPU work (scanning shader maps and 
selecting used ones) or GPU work (shaders are recompiled or linked too often). 
Do you have any profiling data to share ?

I do expect some performance degredation while using it vs standard 
osg::program. Thats related to active shader selection process in 
Virtual::Program apply. I expect this could become nasty when one uses a lot of 
virtual programs with many shader changing frequently.

Lets say that VirtualProgram in current candidate release was mainly intended 
as working functional prototype. I expected that implementing this 
functionality in target osg version would also require some modifications and 
optimizations to program state handling and few modifications to speed it up by 
caching last used set of shaders and programs.

Cheers,
Wojtek

- Original Message - 
  From: Trajce Nikolov 
  To: OpenSceneGraph Users 
  Sent: Friday, February 12, 2010 10:30 AM
  Subject: [osg-users] osgCandidate::VirtualProgram performance


  Hi,


  I am using this in my app and facing really performance problems. When I 
replace it with osg::Program and Shaders, it is a huge difference. Like from 
30Hz to 100Hz. Any ideas why it is so slow ?



  -Nick



--


  ___
  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] Shader composition

[Wojciech Lewandowski]

Hi Everybody,

I am also deply interested in the topic ;-).

Current VirtualProgram implementation does not complie and relink shaders and 
programs each time they are applied. They are only generated and linked when 
certain new mix of shaders is encounterd in VirtualProgram::apply and used for 
the first time. Then, this set of shaders and corrsponding linked gl program is 
cached and reused later. Exactly the same case as when new osg::Program is 
compiled on first use. Difference is that osg::Program can be prebuilt in 
GLVisitor. Theoretically we could write a code to do the same with 
VirtuaProgram combinations. It will be much trickier, though... 

Wojtek Lewandowski


  - Original Message - 
  From: Robert Osfield 
  To: OpenSceneGraph Users 
  Sent: Thursday, February 25, 2010 10:59 AM
  Subject: Re: [osg-users] Shader composition


  Hi Lilith,


  On Thu, Feb 25, 2010 at 9:12 AM, Lilith Bryant  wrote:

I highly suggest you do some benchmarking on shader compiling/link times.  
We
investigated this a couple of years ago, and found that we couldn't avoid an
output glitch (due to compile/link time) whenever we needed a new shader.


  I agree that performance is critical.  When ever I make major changes to the 
OSG I do lots of benchmarking.

  In this specific case compilation, linking and uniform changes all have their 
own performance issues to be mindful of.  My expectation for shader composition 
was that we'd need to do upfront compilation, and linking as much as possible 
and select between complete programs rather than dynamically doing too much 
actual shader composition during draw dispatch on each frame.  

  Keeping the CPU overhead of doing selection of which program to make active 
is also something that I've been pondering about.

  Keeping this all in check is why I need to spend the time thinking about the 
design so deeply.

  Robert.

  I



--


  ___
  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] RefactoringDatabasePagerNeedToRemovestringflaggingtechnique

[Wojciech Lewandowski]

Thank You, 

I will check how our system performs after your changes. I will probably do the 
testing tomorrow or friday. I will let you know how it went.

Big Thanks,
Wojtek Lewandowski 
  - Original Message - 
  From: Robert Osfield 
  To: OpenSceneGraph Users 
  Sent: Wednesday, March 03, 2010 6:20 PM
  Subject: Re: [osg-users] 
RefactoringDatabasePagerNeedToRemovestringflaggingtechnique


  I'm just chipping back into this old thread to say that re-factor of the 
DatabasePager that I checked in today remove the usage of marking of the 
PagedLOD as being deleted using the node name.  The use of a custom 
observer_ptr<> rather than a ref_ptr<> internally in the DatabasePager makes 
the need to keep track of removals in the original way unnecessary.

  If you were having issues related to the issues discussed in this thread 
please check out the svn/trunk and see if the issues are now addressed.

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

Re: [osg-users] automatic pixel transparency adjustment

[Wojciech Lewandowski]

Hi Guy,

If classic multisample antialiasing does not work for you, have a look at 
centroid modified in GLSL ver 1.2 and upr. See this link for example:
http://www.opengl.org/pipeline/article/vol003_6/

Wojtek Lewandowski
  - Original Message - 
  From: Robert Osfield 
  To: OpenSceneGraph Users 
  Sent: Thursday, March 04, 2010 10:03 AM
  Subject: Re: [osg-users] automatic pixel transparency adjustment


  Hi Guy,

  I can't help but feel what you are asking for is full screen anti-aliasing...

  Robert.


  On Thu, Mar 4, 2010 at 4:43 AM, Guy  wrote:

Hi all,

 I need "OpenGL"/driver/fixed-pipeline/whatever I don’t need to code, to do 
the following thing:

When rasterizing an object, first never ignore any pixel the object is 
projected on (even if the area the object consume in that pixels is tiny). 
Second multiply the object transparency by the percents the object occupies in 
that pixel.



Is it possible? How can I achieve that?



Suppose I can achieve it (maybe with OpenGL3.0, or special flags for 
previous versions that prevent openGL from discarding pixels that the object 
occupies less than some threshold on that pixel), does it mean all the objects 
should be sent to the transparent bin and have blending enabled? What amount of 
performance impact should I expect?



If it is a major impact, do you have any other idea to achieve this effect 
for objects edges and for objects that are smaller than one pixel?



Btw, this is not because I'm crazy, this process is closer to the physical 
process that happens with camera and therefore more accurate.



Thanks,

 Guy.


___
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] automatic pixel transparency adjustment

[Wojciech Lewandowski]

errata: not centroid modified but centroid modifier. 

Wojtek

- Original Message - 
  From: Wojciech Lewandowski 
  To: OpenSceneGraph Users 
  Sent: Thursday, March 04, 2010 11:41 AM
  Subject: Re: [osg-users] automatic pixel transparency adjustment


  Hi Guy,

  If classic multisample antialiasing does not work for you, have a look at 
centroid modified in GLSL ver 1.2 and upr. See this link for example:
  http://www.opengl.org/pipeline/article/vol003_6/

  Wojtek Lewandowski
- Original Message - 
From: Robert Osfield 
To: OpenSceneGraph Users 
Sent: Thursday, March 04, 2010 10:03 AM
Subject: Re: [osg-users] automatic pixel transparency adjustment


Hi Guy,

I can't help but feel what you are asking for is full screen 
anti-aliasing...

Robert.


On Thu, Mar 4, 2010 at 4:43 AM, Guy  wrote:

  Hi all,

   I need "OpenGL"/driver/fixed-pipeline/whatever I don’t need to code, to 
do the following thing:

  When rasterizing an object, first never ignore any pixel the object is 
projected on (even if the area the object consume in that pixels is tiny). 
Second multiply the object transparency by the percents the object occupies in 
that pixel.



  Is it possible? How can I achieve that?



  Suppose I can achieve it (maybe with OpenGL3.0, or special flags for 
previous versions that prevent openGL from discarding pixels that the object 
occupies less than some threshold on that pixel), does it mean all the objects 
should be sent to the transparent bin and have blending enabled? What amount of 
performance impact should I expect?



  If it is a major impact, do you have any other idea to achieve this 
effect for objects edges and for objects that are smaller than one pixel?



  Btw, this is not because I'm crazy, this process is closer to the 
physical process that happens with camera and therefore more accurate.



  Thanks,

   Guy.


  ___
  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] Euler angles problem with showing

[Wojciech Lewandowski]

Czesc Andrzej,

After quick inspection I noticed that you use most popular set of Euler 
angles. So the code below should work for you. See MatrixGetRotation 
fumction. Feel free to useit and adopt it to osg::Matrices. Its easy to 
replace mat[3][3] with osg::Matrix. Indexing should be the same.


Cheers,
Wojtek

//
/* Euler angles : */
/* heading = rotz */
/* pitch = rotx */
/* roll = roty */
//
static void
MatrixSetRotation( double rz, double rx, double ry, double mat[3][3] )
{
// Build rotation matrix
// the matrix looks like this:
// r1 - (r4 * sin(x)) r2 + (r3 * sin(x)) -cos(x) * sin(y)
// -cos(x) * sin(z) cos(x) * cos(z) sin(x)
// r3 + (r2 * sin(x)) r4 - (r1 * sin(x)) cos(x) * cos(y)
//
// where:
// r1 = cos(y) * cos(z)
// r2 = cos(y) * sin(z)
// r3 = sin(y) * cos(z)
// r4 = sin(y) * sin(z)
double cx = cos(rx), sx = sin(rx);
double cy = cos(ry), sy = sin(ry);
double cz = cos(rz), sz = sin(rz);
double r1 = cy * cz;
double r2 = cy * sz;
double r3 = sy * cz;
double r4 = sy * sz;
mat[0][0] = r1 - (r4 * sx);
mat[0][1] = r2 + (r3 * sx);
mat[0][2] = -cx * sy;
mat[1][0] = -cx * sz;
mat[1][1] = cx * cz;
mat[1][2] = sx;
mat[2][0] = r3 + (r2 * sx);
mat[2][1] = r4 - (r1 * sx);
mat[2][2] = cx * cy;
}
//
/* Euler angles : */
/* heading = rotz */
/* pitch = rotx */
/* roll = roty */
//
static void
MatrixGetRotation( double mat[3][3], double &rz, double &rx, double &ry )
{
rx = asin( mat[1][2] );
// if( x != M_PI / 2 && x != -M_PI/2 )
if( -1.0 < mat[1][2] && mat[1][2] < 1.0 )
{
ry = atan2( -mat[0][2], mat[2][2] );
rz = atan2( -mat[1][0], mat[1][1] );
} else {
ry = 0.0;
rz = atan2( mat[0][1], mat[0][0] );
}
}

- Original Message - 
From: Andrzej Piatek

To: OpenSceneGraph Users
Sent: Friday, March 05, 2010 3:31 PM
Subject: [osg-users] Euler angles problem with showing


Hi!

I would like to show angles of rotation but i get some problems :

[...]
objMat = matrixTransform->getMatrix();
osg::Vec3 rot;
rot[0] = v3->z-hpr.z(); // value taken from widget and difference 
between old and new value;

rot[1] = v3->x-hpr.x();
rot[2] = v3->y-hpr.y();

   osg::Matrix H;
   H.makeRotate(osg::DegreesToRadians(rot[0]), osg::Vec3(0,0,1)); // 
attitude

   osg::Matrix P;
   P.makeRotate(osg::DegreesToRadians(rot[1]), osg::Vec3(1,0,0)); // pitch
   osg::Matrix R;
   R.makeRotate(osg::DegreesToRadians(rot[2]), osg::Vec3(0,1,0)); // roll
   rotMat = H*P*R;

   matrixTransform->setMatrix(rotMat*objMat);
[..]

For example i write 45 degrees for pitch and my box rotates nice and next i 
use osgMatrixToHpr(hpr, mat) to convert from matrix and get x = 45 y = 0 z = 
0 so it's good.
Later i wrote 45 for roll and my box transforms (pitch = 45, roll = 45 , 
attitude =0)  but i get values like that : x = 54.73560 , y = 30 , z 
=35.264389 and i wanted smth like this x= 45, y=45, z =0


What should i do to show them properly or transform properly ?

A.P






___
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] Shadows and negative renderbin?

[Wojciech Lewandowski]

Hi J-S,

I suppose its caused by crude scene bounds computation. LispsmVB does not do 
any magic: it simply computes view frustum and intersects it with scene 
bounds to find visible part of shadow volume. I guess the problem is related 
to second part of the math ie scene bounds computation which is done in 
MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds(). Depending 
on ShadowReceivingCoarseBoundsAccuracy it may either take whole scene 
bounding sphere or run computeBoundingBox visitor. Check which path you 
take. How exactly render bins would be related to finding Bounding bounds is 
hard for me to explain and you will probably need to trace it with debugger. 
MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds() is good 
place to start looking. Check what are the dimension of returning volume. 
Good hunting ;-)


Let me know if you find somethig that could be fixed in MSM and related 
code.


Wojtek Lewandowski




- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Friday, March 05, 2010 5:45 PM
Subject: [osg-users] Shadows and negative renderbin?



Hi all,

I was wondering if someone has had problems with objects which are in 
negative-numbered renderbins with shadows (in my case, 
osgShadow::LightSpacePerspectiveShadowMapVB).


I had set up my skydome in renderbin -100 to make really sure it was 
rendered before other things, and set its node mask so it would not be 
included in shadow traversal - setNodeMask(getNodeMask() & ~CAST_SHADOW & 
~RECEIVE_SHADOW) but for some reason it seems like it was still being used 
for the bounds of the shadow map, because shadows did not show up on near 
objects and were very aliased far out. I isolated the problem to the 
renderbin setting, and setting it to a positive value fixed the problem - 
the skydome is not considered at all for the shadows now.


I'm surprised the renderbin would have any effect. I haven't delved into 
the code but if someone (Wojtek? :-) ) could explain this or provide some 
pointers I would appreciate...


Thanks in advance,

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


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

Re: [osg-users] Shadows and negative renderbin?

[Wojciech Lewandowski]

I don't think such backporting should be an issue. Practically recent fixes 
were cosmetics, improved precision in first iteration of shadow camera 
projection setup and better handling of spot lights.
One more thing came to my mind: StandardShadowMap forces RenderBin override 
on all nodes rendered into shadow map. Maybe this somehow affects your case 
? You may comment RenderBin override and see if it changes anything...


Wojtek

- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Friday, March 05, 2010 6:10 PM
Subject: Re: [osg-users] Shadows and negative renderbin?



Hi again,


I was wondering if someone has had problems with objects which are in
negative-numbered renderbins with shadows (in my case,
osgShadow::LightSpacePerspectiveShadowMapVB).


I should have mentioned that this is using the view dependent shadow 
classes from OSG 2.8.x backported to OSG 2.6.x, so perhaps I'm asking for 
trouble. Any semi-recent changes to the code aren't being used. I'll try 
compiling our sim using OSG SVN and see if it makes a difference.


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


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

Re: [osg-users] Shadows and negative renderbin?

[Wojciech Lewandowski]

That looks like the problem with boundingBoxVisitor called inside
MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds() because it
takes node mask as an input.

Btw I started to suspect that there is an error inside above method. 
Possibly not involved in your investigation. BoundigBoxVisitor is run with 
Cast but should rather use Receive mask.  It may be deliberate choice but I 
suspect this raher an error which went unnoticed till now because I usually 
keep both masks equal.


Cheers,
Wojtek

- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Friday, March 05, 2010 6:15 PM
Subject: Re: [osg-users] Shadows and negative renderbin?



Hi Wojtek,


MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds() is
good place to start looking. Check what are the dimension of returning
volume. Good hunting ;-)


Thanks for the hint. I'll look there. In the mean time I did more testing
and found that even now that I've changed the renderbin to a non-negative
number, the skydome (which I remind you is set to NOT cast NOR receive
shadows) still interferes with shadows. From some angles, when the skydome
is active, the shadows on the crane (our main object) turn all black. If I
disable the skydome then the shadows are correct.

The turning on and off of the skydome is just switching the node mask of
its root node between 0 and ( & ~CAST & ~RECEIVE) which are
single-bit masks.

So I really think that there is somewhere that's traversing the skydome
where it shouldn't, and setting the mask to 0 makes it really not traverse
it... I'll check.

Thanks,

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


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

Re: [osg-users] RefactoringDatabasePagerNeedToRemovestringflaggingtechnique

[Wojciech Lewandowski]

Hi Robert,

Our testing shows that everything looks good now. We will be doing some more 
work on the sim next week and do more testing on this occasion. We will let you 
know in case something suspicious pop up. But lets keep finger crossed it won't.

Thanks a lot for Your Great Work
Wojtek
 
  - Original Message - 
  From: Wojciech Lewandowski 
  To: OpenSceneGraph Users 
  Sent: Wednesday, March 03, 2010 6:40 PM
  Subject: Re: 
[osg-users]RefactoringDatabasePagerNeedToRemovestringflaggingtechnique


  Thank You, 

  I will check how our system performs after your changes. I will probably do 
the testing tomorrow or friday. I will let you know how it went.

  Big Thanks,
  Wojtek Lewandowski 
- Original Message - 
From: Robert Osfield 
To: OpenSceneGraph Users 
Sent: Wednesday, March 03, 2010 6:20 PM
Subject: Re: [osg-users] 
RefactoringDatabasePagerNeedToRemovestringflaggingtechnique


I'm just chipping back into this old thread to say that re-factor of the 
DatabasePager that I checked in today remove the usage of marking of the 
PagedLOD as being deleted using the node name.  The use of a custom 
observer_ptr<> rather than a ref_ptr<> internally in the DatabasePager makes 
the need to keep track of removals in the original way unnecessary.

If you were having issues related to the issues discussed in this thread 
please check out the svn/trunk and see if the issues are now addressed.

Thanks,
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] Shadows and negative renderbin?

[Wojciech Lewandowski]

Hi Again,


That looks like the problem with boundingBoxVisitor called inside
MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds()
because it takes node mask as an input.


Can you elaborate?


Look inside the 
MinimalShadowMap::ViewData::computeShadowReceiveingCoarseBounds method. 
ComputeBoundingBox visitor has node mask set to cast shadow bitmask before 
visitor is run on ShadowedScene graph. I did not mean more than this.


Wojtek 


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

Re: [osg-users] problems about layer rendering

[Wojciech Lewandowski]

Hi Kai,

Disclaimer: I have not done anything like this. I did think about 
implementing such technique, though.  And I am deeply interested in the 
results You could get.  So I will try to provide few unproven suggestions in 
hope you will share them later ;-)


1. The way you attach texture layers will not work. This way you will have 
only one buffer active. Camera::atach in your usage scenario cause OSG to 
set up FBO using
glFramebufferTextureLayer( GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT, 
your_tex_array_gl_id,  0, layer ). Layer in this context does not define 
FRAMEBUFFER layer but layer of texture 2D array. Effectively you call attach 
3 times but two first calls are overriden with third so finally your three 
calls:


   shadowCamera->attach(osg::Camera::COLOR_BUFFER, ta, 0, 0);  //
   shadowCamera->attach(osg::Camera::COLOR_BUFFER, ta, 0, 1);
   shadowCamera->attach(osg::Camera::COLOR_BUFFER, ta, 0, 2);

are effectively equal to last one:

   shadowCamera->attach(osg::Camera::COLOR_BUFFER, ta, 0, 2);

I guess you may want to replace it with following three calls:

   shadowCamera->attach(osg::Camera::COLOR_BUFFER0, ta, 0, 0);
   shadowCamera->attach(osg::Camera::COLOR_BUFFER1, ta, 0, 1);
   shadowCamera->attach(osg::Camera::COLOR_BUFFER2, ta, 0, 2);

this will set up multiple render targets with 3 independent color buffers. 
However, I am not sure if this will propely work with gl_Layer produced in 
Geometry shader. These OpenGL examples I saw usually set up layered 
framebuffer rendering with one glFramebufferTexture call. For example see 
this link (its sample code to render 6 faces of cubemap simultaneously) 
http://pastie.org/796448: However, this brings another problem: 
glFramebufferTexture functinality is not used by OSG yet.


2. Even assuming that you may set each layer as multiple render targets 
using above suggestion I see another problem: Shadow maps are generated into 
depth maps and hence you should rather set up DEPTH_BUFFERS insted of 
COLOR_BUFFERS . I am not sure if support for multiple depth buffer targets 
is already available for OpenGL (I know its present in recent Direct3D). You 
will have to check it. But even if its available in OpenGL its not yet 
supported by OSG.


3. On few forums I saw that people trying to set similar up rendering were 
able to get it to work on COLOR_BUFFERS but even then only one DEPTH_BUFFER 
layer was used. It looked like bugs in the drivers.


So the prospects are not too bright. I looks like you need to modify OSG FBO 
code to get what your are after. I have no idea, how deep these 
modifications should be


In one of my concepts, instead of depth buffers  I was considering using one 
32 floating point color buffer (each channel would represent one depth 
layer) with BlendEquation set to RGBA_MIN. This way one could effectively 
replicate depth buffer behaviour with color buffer. Early Z -test is gone 
though


Dont forget to post your results ;-)

Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Kai Xia" 

To: 
Sent: Monday, March 08, 2010 9:01 AM
Subject: [osg-users] problems about layer rendering



Hi,

I have some problems while using geometry shader and TextureArray to 
optimize PSSM shadow, the test code is like following:

C++ code:
osg::TextureArray *ta = new osg::TextureArray;
ta->setTextureSize(1024, 1024, 3); //3 layer texture
...
shadowCamera->attach(osg::Camera::COLOR_BUFFER, ta, 0, 0);  //
shadowCamera->attach(osg::Camera::COLOR_BUFFER, ta, 0, 1);
shadowCamera->attach(osg::Camera::COLOR_BUFFER, ta, 0, 2);

Geometry shader code:

#extension GL_EXT_geometry_shader4 : require

varying vec4 color;

void main()
{
   //Route to Layer 0
   for (int i = 0; i < 3; i++)
   {
   // You will recieve 3 positions since we set the input type to 
Triangles

   gl_Position = 0.5*gl_PositionIn[i] - vec4(0.5, 0.0, 0.0, 1.0);
   gl_FrontColor = vec4(1.0, 0.0, 0.0,1.0);
   gl_Layer = 0;
   EmitVertex();
   }
   EndPrimitive();

   //Route to Layer 1
   for (int i = 0; i < 3; i++)
   {
   gl_Position = 0.5*gl_PositionIn[i];
   //Just to see a difference in Layer 1
   gl_FrontColor = vec4(0.0, 1.0, 0.0,1.0);
   gl_Layer = 1;
   EmitVertex();
   }
   EndPrimitive();
   //Route to Layer 2
   for (int i = 0; i < 3; i++)
   {
   gl_Position = 0.5*gl_PositionIn[i] + vec4(0.5, 0.0, 0.0, 1.0);
   //Just to see a difference in Layer 1
   gl_FrontColor = vec4(0.0, 1.0, 0.0,1.0);
   gl_Layer = 2;
   EmitVertex();
   }
   EndPrimitive();
}

during the testing , only the 1st layer of texture have avaliable 
context(scene with red color), other 2 layers are undefined. Has some one 
sucessed in layer rendering? please give some advise, thanks a lot!



Cheers,
xiakai

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





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

Re: [osg-users] problems about layer rendering

[Wojciech Lewandowski]

Nope. I meant glFramebufferTexture(..). And no, this particular function is not 
called there. Go check this. 
glFramebufferTexture1D(..), glFramebufferTexture2D(..), 
glFramebufferTexture3D(..), glFramebufferTextureLayer(..) are not the same 
thing...

Wojtek Lewandowski

- Original Message - 
  From: Tim Moore 
  To: OpenSceneGraph Users 
  Sent: Wednesday, March 10, 2010 2:05 PM
  Subject: Re: [osg-users] problems about layer rendering





  On Wed, Mar 10, 2010 at 12:21 PM, Wojciech Lewandowski 
 wrote:


this will set up multiple render targets with 3 independent color buffers. 
However, I am not sure if this will propely work with gl_Layer produced in 
Geometry shader. These OpenGL examples I saw usually set up layered framebuffer 
rendering with one glFramebufferTexture call. For example see this link (its 
sample code to render 6 faces of cubemap simultaneously) 
http://pastie.org/796448: However, this brings another problem: 
glFramebufferTexture functinality is not used by OSG yet.


  glFramebufferTexture calls are used in FrameBufferObject.cpp to attach a 
"FrameBufferAttachment." Are you thinking of another use for 
glFramebufferTexture?

  Tim




--


  ___
  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] problems about layer rendering

[Wojciech Lewandowski]

Hi Kai,


I checked RenderStage::runCameraSetUp() source code, and found that
bufferAttachments only have Texture1D, Texture2D, Texture3D,
TextureCubeMap, TextureRetangle, but without TextureArray, and I don`t
know weather OSG using glFramebufferTextureLayer or glFramebufferTexture
when bind TextureArray, cubeMap and Texture3D, if using
glFramebufferTexture, no layer rendering is available. I will try
Texture3D for layer rendering.

BTW,
shadowCamera->attach(osg::Camera::COLOR_BUFFER0, ta, 0, 0);
shadowCamera->attach(osg::Camera::COLOR_BUFFER1, ta, 0, 1);
shadowCamera->attach(osg::Camera::COLOR_BUFFER2, ta, 0, 2);
does not take effects, each color_buffer only accept the rastered
fragments of primitive in first layer, the other 2 in geometry shader does
not shown.


That seems to prove what I was afraid of. Using layered rendering ( 
glFramebufferTexture() with complex
texture and GLSL gl_Layer variable ) is bit differently  processed in OpenGL 
than multiple render targets.


You could probably emulate gl_Layer with custom extra vertex 
attribute/varying to store layer. Set the value in geometry shader and pass 
along to vertex & fragment shaders for selection of target draw buffer.
But I would rather try to modify OSG to do layered rendering in recommended 
way. This way you could post your work and others could benefit as well...


Cheers,
Wojtek

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

Re: [osg-users] texture2Darray problem

[Wojciech Lewandowski]

Hi,

I had the same issue. Its a warnig while applying texture mode.  Do not use 
setTextureAttributeAndModes(). Use setTextureAttribute() instead. There is not 
such mode like GL_TEXTURE_2D_ARRAY. Texture2DArrays do not work with fixed 
pipeline. They are accessible only with shaders.

Wojtek Lewandowski
  - Original Message - 
  From: Riccardo Corsi 
  To: OpenSceneGraph Users 
  Sent: Friday, March 12, 2010 1:03 PM
  Subject: [osg-users] texture2Darray problem


  Hi All,

  I have tried a sample application to make use of texture2Darray and 
associated sampler2DArray Uniform.
  I wrote my code based on some previous discussions on the mailing list 
archives.

  Unfortunately I keep on having GL errors during execution, in particular and 
"invalid enumerator" after applying the extension:
  GL_TEXTURE_2D_ARRAY_EXT   0x8C1A

  Attached you find the sample program producing the error.

  Can someone provide any hints?
  I'm on Win7 + nVidia gtx295, using osg-2.8.2

  Thank you,
  Ricky



--


  ___
  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] Support vendor specific 3D APIs - any interest here?

[Wojciech Lewandowski]

Hi Christian,

I am interested. Subject intersts me mostly as a hobby, perhaps someday more 
comercially. I am glad you pointed out this API. I was not aware of it. I am 
however, bit dubious about possibility to use it with OpenGL on consumer 
GeForce cards. Which NVAPI functions would allow to implement 3D 
stereovision with OpenGL ?


Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Christian Buchner" 

To: "OpenSceneGraph Users" 
Sent: Monday, April 05, 2010 2:48 PM
Subject: [osg-users] Support vendor specific 3D APIs - any interest here?



Hi,

So quad buffered stereo only works with professional graphics cards,
and I have used that feature with success at my work place. At home I
do not have access to such devices. But I do have a 120 Hz capable
monitor and those nVidia 3D Vision shutter glasses, which
unfortunately only support DirectX gaming and stereo viewing of video
and still images. This is mostly targeted at a gaming audience and
OpenGL is no longer relevant enough to be supported (what a shame!).

But nVidia have created a proprietary API (NVAPI) with which it is
possible to display pretty much anything with shuttered glasses. Would
there be any interest to fit OpenSceneGraph with a capability to
render to 3DVision enabled displays with non-Quadro graphics cards?

Is support for proprietary APIs and extensions frowned upon in this
community? (I hear ATI have a similar vendor specific shutter glasses
API in their latest drivers)

Christian
___
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] Support vendor specific 3D APIs - any interest here?

[Wojciech Lewandowski]

Hi Christian,

[..]

NVAPI as found here
http://developer.download.nvidia.com/NVAPI/NVAPI_May2009.zip describes
details in the "Stereoscopic 3D APIs" section how to turn on 3D mode
and even how to swap left/right eyes on stereoscopic surfaces with
NvAPI_Stereo_ReverseStereoBlitControl()

Unfortunately OpenGL surfaces do not seem to be supported. So one
would have to take a slow code path reading the pixel data from an
OpenGL surface and writing it into a DirectX9 surface. Ouch. This
might not be feasible at high frame rates at all.


That was my impression as well. 3D stereoscopic api seems to be created for 
Direct3D developers to check if  Stereo is running and override/modify its 
parameters. The API is probably used to provide native 3D Vision support 
from a DirectX game. I guess its used by recently advertrised S3D aware 
Unreal.


I am curiouse if  NVAPI gives access to shutter glasses. If shutter control 
is possible and possible is 120 hz refresh rate through display settings, 
one could try emulate 3D stereo effect by alternate eye view rendering. But 
thats a quite tricky solution either.


Cheers,
Wojtek 


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

Re: [osg-users] Support vendor specific 3D APIs - any interest here?

[Wojciech Lewandowski]

Hi Jan,

Have you seen most recent NVAPI release specs Christian mentioned about ? 
There is definitely more interesting stuff for Direct3D game developers. 
Some of the stereovison stuff in there, seems useful only when accessed from 
inside Direct3D application.  Unfortunately this does not help us much in 
OpenGL.


Cheers,
Wojtek

--
From: "Jan Ciger" 
Sent: Wednesday, April 07, 2010 7:30 PM
To: "OpenSceneGraph Users" 
Subject: Re: [osg-users] Support vendor specific 3D APIs - any interest 
here?



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 2010-04-06 14:30, Wojciech Lewandowski wrote:


That was my impression as well. 3D stereoscopic api seems to be created
for Direct3D developers to check if  Stereo is running and
override/modify its parameters. The API is probably used to provide
native 3D Vision support from a DirectX game. I guess its used by
recently advertrised S3D aware Unreal.


Not really - the API is intended for tools like the NVIDIA control
panel, allowing you to tweak settings of the driver. It has nothing to
do with stereo as such, it actually predates the 3D Vision glasses by
quite a bit. It is used by the NVIDIA tools.


I am curiouse if  NVAPI gives access to shutter glasses. If shutter
control is possible and possible is 120 hz refresh rate through display
settings, one could try emulate 3D stereo effect by alternate eye view
rendering. But thats a quite tricky solution either.


No, there are, if I recall correctly, only 3 functions allowing you to
change anything stereo-related: turn stereo on/off, set the eye
separation and set the focal distance (the distance of the eye from the
image plane). That is all.

The rest of the API is not related to 3D at all.

Regards,

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

iD8DBQFLvMFCn11XseNj94gRApEUAKDLdYBt52hVHa6M5vc4RjLd9geV/wCgqFhb
Vg3qUrRa4OKn4pcUZKcWqSk=
=VjSL
-END PGP SIGNATURE-
___
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] osgShadow and osgearth

[Wojciech Lewandowski]

Hi Sumit,

Have you tried LispSM ? I have not tested it with osgEarth but it works  with 
osgDEM data.  See osgShadow -4 --lispsm example. 

With large Dataset you will probably have to take advantage of two Lispsm 
methods inherited from MinimalShadowMap
void setModellingSpaceToWorldTransform( const osg::Matrix & 
modellingSpaceToWorld );  

and

void setMaxFarPlane( float maxShadowDistance );

to optimize shadow map resolution usage. Look how they are used in osgShadow 
example.

Cheers,

Wojtek Lewandowski




 
From: sumit 
Sent: Saturday, April 10, 2010 9:14 AM
To: 'OpenSceneGraph Users' 
Subject: [osg-users] osgShadow and osgearth


Hi all, 

I m trying to get the shadows on earth(rendered by osgEarth). I 
have just inserted the earth node in osgShadow example. I could not get any 
shadow of mountains on terrain(self shadowing) by any shadowmap technique. I 
have tried to increase texture resolution but it's still not working. It was 
working for small terrain(created in osgShadow example model 2). Am I missing 
something?

 

Cheers

Sumit






___
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] CubeMap-Reflection and ShadowMap don't work togehter?

[Wojciech Lewandowski]

Hi Martin,

I am afraid you will have to touch GLSL. All shadow map techniques are 
shader based. What you will have to do is: replace base texture 2D sampler 
with your textureCube sampler and will have to process tex coords 
accordingly.  If you have not yet learnded GLSL, this moment have just come. 
Don't hesitate, with shaders the fun really starts ;-)


Wojtek Lewandowski

- Original Message - 
From: "Martin Großer" 

To: "OpenSceneGraph Users" 
Sent: Friday, April 16, 2010 11:21 AM
Subject: [osg-users] CubeMap-Reflection and ShadowMap don't work togehter?



Hello,

short question. I have a Node with a cube map reflection like the 
osgcubemap example. Now I use the "StandardShadowMap". Only the shadow 
works. Only the cube map works. But when I use it together only the shadow 
works. Override the shadow settings my cube map settings?


But what can I do to fix it in my application without writing a glsl 
shader?


Cheers

Martin
___
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] texture2Darray issue with different image format

[Wojciech Lewandowski]

Hi Ricardo,

Current texture2DArray implementation does not handle loading and generation 
of mipmaps for compressed formats. If you can rebuild OSG you may try 
attached patch to Texture2DArray class. I intend to post it ultimately to 
submissions list, but lets say its in "alpha" version and I want to make one 
more review before posting and other tasks prevented me from doing it, yet. 
You may test it. There is a chance it will solve your problem.


Cheers,
Wojtek Lewandowski



- Original Message - 
From: "Robert Osfield" 

To: "OpenSceneGraph Users" 
Sent: Friday, April 23, 2010 10:24 AM
Subject: Re: [osg-users] texture2Darray issue with different image format



Hi Riccardo,

On Fri, Apr 23, 2010 at 8:27 AM, Riccardo Corsi
 wrote:

as a follow-up I discovered that the limitation seems to depend on the
"internalTextureFormat" of the images loaded.
I succeded in fixing the TGA settings but not the DDS.
Here the setting for the different image types as read from the plugins:


I'm afraid I don't have an specific answers on this topic as I haven't
use texture arrays and compression, but the inconsistency in how the
internal texture format us used, i.e. something that works OK for
Texture2D doesn't work for Texture2DArray, makes me wonder if there is
either a bug in osg::Texture2DArray or with the OpenGL driver.

As an aside one of the things I found with the GLES port was GLES was
a bit more picky about the internal format not being one of the 1,2,3
or 4 values that some of the plugins still use.


Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
*
* This library is open source and may be redistributed and/or modified under  
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
* (at your option) any later version.  The full license is in LICENSE file

* included with this distribution, and on the openscenegraph.org website.
* 
* This library is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
* OpenSceneGraph Public License for more details.

*/
#include 
#include 
#include 
#include 

#include 


using namespace osg;

Texture2DArray::Texture2DArray():
   _textureWidth(0),
   _textureHeight(0),
   _textureDepth(0),
   _numMipmapLevels(0)
{
}

Texture2DArray::Texture2DArray(const Texture2DArray& text,const CopyOp& copyop):
   Texture(text,copyop),
   _textureWidth(text._textureWidth),
   _textureHeight(text._textureHeight),
   _textureDepth(text._textureDepth),
   _numMipmapLevels(text._numMipmapLevels),
   _subloadCallback(text._subloadCallback)
{
   // copy all images by iterating through all of them
   for (int i=0; i < text._textureDepth; i++)
   {
   _images.push_back(copyop(text._images[i].get()));
   _modifiedCount.push_back(ImageModifiedCount());
   }
}

Texture2DArray::~Texture2DArray()
{
}

int Texture2DArray::compare(const StateAttribute& sa) const
{
   // check the types are equal and then create the rhs variable
   // used by the COMPARE_StateAttribute_Parameter macro's below.
   COMPARE_StateAttribute_Types(Texture2DArray,sa)

   bool noImages = true;
   for (int n=0; n < _textureDepth; n++)
   {
   if (noImages && _images[n].valid()) noImages = false;
   if (noImages && rhs._images[n].valid()) noImages = false;
   
   if (_images[n]!=rhs._images[n]) // smart pointer comparison.

   {
   if (_images[n].valid())
   {
   if (rhs._images[n].valid())
   {
   int result = _images[n]->compare(*rhs._images[n]);
   if (result!=0) return result;
   }
   else
   {
   return 1; // valid lhs._image is greater than null. 
   }

   }
   else if (rhs._images[n].valid()) 
   {
   return -1; // valid rhs._image is greater than null. 
   }

   }
   }

   
   if (noImages)

   {
   int result = compareTextureObjects(rhs);
   if (result!=0) return result;
   }

   int result = compareTexture(rhs);
   if (result!=0) return result;

   // compare each parameter in turn against the rhs.
   COMPARE_StateAttribute_Parameter(_textureWidth)
   COMPARE_StateAttribute_Parameter(_textureHeight)
   COMPARE_StateAttribute_Parameter(_textureDepth)
   COMPARE_StateAttribute_Parameter(_subloadCallback)

   return 0; // passed all the above comparison macro's, must be equal.
}

void Texture2DArray::setImage(unsigned int layer, Image* image)
{
   // check if the layer exceeds the texture depth
   if (static_cast(layer) >= _textureDepth)
   {
   // print warning and do no

Re: [osg-users] texture2Darray issue with different image format

[Wojciech Lewandowski]

It was based on the trunk. What were the problems ? I'll recheck if the code 
still compiles later today. 

WL


From: Riccardo Corsi 
Sent: Monday, April 26, 2010 1:38 AM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] texture2Darray issue with different image format


Hi Wojtek,

I didn't manage to compile your patch with neither osg 2.8.2 nor the trunk.
What osg revision is needed?

Ricky


On Fri, Apr 23, 2010 at 12:08, Riccardo Corsi  
wrote:

  Hi Wojtek and Robert,

  thanks for your replies. 
  I'll try the patch in the evening and let you know if it fixes the problem on 
my side.

  Robert, the restricion on the values 1, 2, 3 or 4 that you mention is related 
to ES profile only, or even to openGL 3.x and 4.x ??
  That might be an issue to address when reviewing the different plugins.

  Cheers,
  Ricky




  On Fri, Apr 23, 2010 at 11:08, Wojciech Lewandowski  
wrote:

Hi Ricardo,

Current texture2DArray implementation does not handle loading and 
generation of mipmaps for compressed formats. If you can rebuild OSG you may 
try attached patch to Texture2DArray class. I intend to post it ultimately to 
submissions list, but lets say its in "alpha" version and I want to make one 
more review before posting and other tasks prevented me from doing it, yet. You 
may test it. There is a chance it will solve your problem.

Cheers,
Wojtek Lewandowski



- Original Message - From: "Robert Osfield" 

To: "OpenSceneGraph Users" 
Sent: Friday, April 23, 2010 10:24 AM
Subject: Re: [osg-users] texture2Darray issue with different image format 




  Hi Riccardo,

  On Fri, Apr 23, 2010 at 8:27 AM, Riccardo Corsi
   wrote:

as a follow-up I discovered that the limitation seems to depend on the
"internalTextureFormat" of the images loaded.
I succeded in fixing the TGA settings but not the DDS.
Here the setting for the different image types as read from the plugins:


  I'm afraid I don't have an specific answers on this topic as I haven't
  use texture arrays and compression, but the inconsistency in how the
  internal texture format us used, i.e. something that works OK for
  Texture2D doesn't work for Texture2DArray, makes me wonder if there is
  either a bug in osg::Texture2DArray or with the OpenGL driver.

  As an aside one of the things I found with the GLES port was GLES was
  a bit more picky about the internal format not being one of the 1,2,3
  or 4 values that some of the plugins still use.


  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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] texture2Darray issue with different image format

[Wojciech Lewandowski]

Hi Ricky,

I have just succesfully compiled osg trunk with this file. I am on windows and 
have not checked GLES compatibility though. Texture2DArray.cpp attached (the 
same as before)

Wojtek
  - Original Message - 
  From: Wojciech Lewandowski 
  To: OpenSceneGraph Users 
  Sent: Monday, April 26, 2010 7:58 AM
  Subject: Re: [osg-users] texture2Darray issue with different image format


  It was based on the trunk. What were the problems ? I'll recheck if the code 
still compiles later today. 

  WL


  From: Riccardo Corsi 
  Sent: Monday, April 26, 2010 1:38 AM
  To: OpenSceneGraph Users 
  Subject: Re: [osg-users] texture2Darray issue with different image format


  Hi Wojtek,

  I didn't manage to compile your patch with neither osg 2.8.2 nor the trunk.
  What osg revision is needed?

  Ricky


  On Fri, Apr 23, 2010 at 12:08, Riccardo Corsi  
wrote:

Hi Wojtek and Robert,

thanks for your replies. 
I'll try the patch in the evening and let you know if it fixes the problem 
on my side.

Robert, the restricion on the values 1, 2, 3 or 4 that you mention is 
related to ES profile only, or even to openGL 3.x and 4.x ??
That might be an issue to address when reviewing the different plugins.

Cheers,
Ricky




On Fri, Apr 23, 2010 at 11:08, Wojciech Lewandowski  
wrote:

  Hi Ricardo,

  Current texture2DArray implementation does not handle loading and 
generation of mipmaps for compressed formats. If you can rebuild OSG you may 
try attached patch to Texture2DArray class. I intend to post it ultimately to 
submissions list, but lets say its in "alpha" version and I want to make one 
more review before posting and other tasks prevented me from doing it, yet. You 
may test it. There is a chance it will solve your problem.

  Cheers,
  Wojtek Lewandowski



  - Original Message - From: "Robert Osfield" 

  To: "OpenSceneGraph Users" 
  Sent: Friday, April 23, 2010 10:24 AM
  Subject: Re: [osg-users] texture2Darray issue with different image format 




Hi Riccardo,

On Fri, Apr 23, 2010 at 8:27 AM, Riccardo Corsi
 wrote:

  as a follow-up I discovered that the limitation seems to depend on the
  "internalTextureFormat" of the images loaded.
  I succeded in fixing the TGA settings but not the DDS.
  Here the setting for the different image types as read from the 
plugins:


I'm afraid I don't have an specific answers on this topic as I haven't
use texture arrays and compression, but the inconsistency in how the
internal texture format us used, i.e. something that works OK for
Texture2D doesn't work for Texture2DArray, makes me wonder if there is
either a bug in osg::Texture2DArray or with the OpenGL driver.

As an aside one of the things I found with the GLES port was GLES was
a bit more picky about the internal format not being one of the 1,2,3
or 4 values that some of the plugins still use.


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



--


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

#include 


using namespace osg;

Texture2DArray::Texture2DArray():
_textureWidth(0),
_textureHeight(0),
_textureDepth(0),
_numMipmapLevels(0)
{
}

Tex

Re: [osg-users] texture2Darray issue with different image format

[Wojciech Lewandowski]

Hi Ricky,

I am sorry I don't have more to offer. I was hoping that my changes would help 
you, but PNG loader most certainly uses uncompressed formats so your problem 
might something else. Try OSG_NOTIFY_LEVEL=DEBUG_INFO or even better run it 
with some GL  debugger to see what is going on under the OSG hood.

Cheers,
Wojtek

  - Original Message - 
  From: Riccardo Corsi 
  To: OpenSceneGraph Users 
  Sent: Monday, May 03, 2010 2:09 AM
  Subject: Re: [osg-users] texture2Darray issue with different image format


  Hi Wojtek,

  sorry but I had a deadline last week and had no time to check you file.

  I mysteriously solved the compiling issue I had =)
  Unfortunately, it doesn't seem to solve my problems, and I seem to have 
issues with the png as well.
  Here is the GL error message:
  Warning: detected OpenGL error 'invalid enumerator' at After Renderer::compile

  Should I use specific image/texture settings to get it working?

  Thank you,
  Ricky


  On Mon, Apr 26, 2010 at 13:17, Wojciech Lewandowski  
wrote:

Hi Ricky,

I have just succesfully compiled osg trunk with this file. I am on windows 
and have not checked GLES compatibility though. Texture2DArray.cpp attached 
(the same as before)

Wojtek
  - Original Message - 
  From: Wojciech Lewandowski 
  To: OpenSceneGraph Users 
  Sent: Monday, April 26, 2010 7:58 AM
  Subject: Re: [osg-users] texture2Darray issue with different image format


  It was based on the trunk. What were the problems ? I'll recheck if the 
code still compiles later today. 

  WL


  From: Riccardo Corsi 
  Sent: Monday, April 26, 2010 1:38 AM
  To: OpenSceneGraph Users 
  Subject: Re: [osg-users] texture2Darray issue with different image format


  Hi Wojtek,

  I didn't manage to compile your patch with neither osg 2.8.2 nor the 
trunk.
  What osg revision is needed?

  Ricky


  On Fri, Apr 23, 2010 at 12:08, Riccardo Corsi 
 wrote:

Hi Wojtek and Robert,

thanks for your replies. 
I'll try the patch in the evening and let you know if it fixes the 
problem on my side.

Robert, the restricion on the values 1, 2, 3 or 4 that you mention is 
related to ES profile only, or even to openGL 3.x and 4.x ??
That might be an issue to address when reviewing the different plugins.

Cheers,
Ricky




On Fri, Apr 23, 2010 at 11:08, Wojciech Lewandowski 
 wrote:

  Hi Ricardo,

  Current texture2DArray implementation does not handle loading and 
generation of mipmaps for compressed formats. If you can rebuild OSG you may 
try attached patch to Texture2DArray class. I intend to post it ultimately to 
submissions list, but lets say its in "alpha" version and I want to make one 
more review before posting and other tasks prevented me from doing it, yet. You 
may test it. There is a chance it will solve your problem.

  Cheers,
  Wojtek Lewandowski



  - Original Message - From: "Robert Osfield" 

  To: "OpenSceneGraph Users" 
  Sent: Friday, April 23, 2010 10:24 AM
  Subject: Re: [osg-users] texture2Darray issue with different image 
format 




Hi Riccardo,

On Fri, Apr 23, 2010 at 8:27 AM, Riccardo Corsi
 wrote:

  as a follow-up I discovered that the limitation seems to depend 
on the
  "internalTextureFormat" of the images loaded.
  I succeded in fixing the TGA settings but not the DDS.
  Here the setting for the different image types as read from the 
plugins:


I'm afraid I don't have an specific answers on this topic as I 
haven't
use texture arrays and compression, but the inconsistency in how the
internal texture format us used, i.e. something that works OK for
Texture2D doesn't work for Texture2DArray, makes me wonder if there 
is
either a bug in osg::Texture2DArray or with the OpenGL driver.

As an aside one of the things I found with the GLES port was GLES 
was
a bit more picky about the internal format not being one of the 
1,2,3
or 4 values that some of the plugins still use.


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








--


  _

Re: [osg-users] Render to texture memory usage

[Wojciech Lewandowski]

Hi,

Multithreading modes allocate two instances of  OpenGL resources to speed up 
rendering .
Default implicit buffer attachment policy adds depth buffer to FBOs if only 
color buffer was attached.


Try running your app in SingleThreaded mode with Camera 
implicitBufferAttachmentRenderMask set to zero.


Cheers,
Wojtek

- Original Message - 
From: "Martin Aasen" 

To: 
Sent: Wednesday, May 05, 2010 3:32 PM
Subject: [osg-users] Render to texture memory usage



Hi,

I am rendering to a texture using a FBO:

camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
camera->attach(osg::Camera_COLOR_BUFFER, texture, 0, 0, false, 0, 0);

The consumption of GPU memory is about three times higher than I would 
expect: about 800 MB for a 8192 x 8192 GL_RGBA texture.


Is this due to allocation of a depth buffer and others?

I don't need depth testing so that could be disabled, but I don't 
understand how to... I was hoping that the memory consumption of the 
texure was all that was needed.


Any help is much appreciated!

Cheers,
Martin

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





___
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] Problem with projection

[Wojciech Lewandowski]

Czolem,

I took a brief look. There might be other issues but one thing seems suspect 
to me.  720/568 in makePerspective call is computed on ints and hence is 
equal to 1. I am sure its not what you are after. Replace it with 720.f/568.


Cheers,

Wojtek
--
From: "Tomek Krze" 
Sent: Monday, May 10, 2010 11:43 AM
To: 
Subject: [osg-users] Problem with projection


Hi,
I have problem draw a points correctly on image. I want to manualy doing 
projection of vertex and draw on image.

I set a camera position:

Code:

osg::Matrixf l; l.makeLookAt(osg::Vec3(0, 0, 500), osg::Vec3(0,0,0), 
osg::Vec3(0,1,0));




Projection matrix:

Code:

osg::Matrixf p; p.makePerspective(osg::DegreesToRadians(50.0f), 720/568, 
1, 1000);




and next i compute new vertex cordinate (vertex is osg::Vec3):

Code:

vertex = vertex*l;



next i multiple new vertex cordinate by perspective matrix

Code:

vertex4 = osg::Vec4(vertex, 1);
vertex4 = vertex4*p;
vertex4.set(vertex4.x()/vertex4.w(), vertex4.y()/vertex4.w(), 
vertex4.z()/vertex4.w(), vertex4.w());





Now I draw vertex to image but result is diffrent with image with i get 
from 3dmax with this same camera parametr.

I think I need multiple with viewport matrix

Code:

osg::Matrixf v ;
osg::Viewport* viewport = new osg::Viewport(0,0,720,568);
v = viewport->computeWindowMatrix();



But when i do it vertex cordinate is too big.
Could someone tell what i doing wrong?
...

Thank you!

Cheers,
Tomek

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





___
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] Development Environment

[Wojciech Lewandowski]

At the moment VS2010 Express seems to not work well with CMake 2.8.1 and 
OSG. Its too fresh probably... Maybe your result will vary but I would 
rather try 2008 Express to be on safe side.


Cheers
Wojtek Lewandowski

--
From: "Frank Henard" 
Sent: Saturday, May 15, 2010 4:34 PM
To: 
Subject: Re: [osg-users] Development Environment


Hi Torben,

That is extremely kind of you.  I just downloaded Visual C++ Express 2010 
last night.  I will see if I can get VS 2008, and follow the instructions 
for that.  Hopefully I won't need too much help.  Thanks!


Frank

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





___
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] Development Environment

[Wojciech Lewandowski]

Hi Guys,

FYI: Yesterday I tried to build OSG with 2010. Last stable CMake 2.8.1 is 
generating some cryptic errors so I checked most recent CMake 2.9.x from 
nightly builds. That version seems to work, so if you want to work with OSG 
under VS 2010 try nightly builds CMake version.


Cheers,
Wojtek

- Original Message - 
From: "Torben Dannhauer" 

To: 
Sent: Sunday, May 16, 2010 10:24 AM
Subject: Re: [osg-users] Development Environment



Hi J-S,

oops, you are right, I marked it as optional. I always integrate it, so I 
forgot that it is optional :)



Thank you!

Cheers,
Torben

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





___
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] Development Environment

[Wojciech Lewandowski]

Nope ;-) With VS2010 Express Beta  I was using dependencies for 2008 + 2008 
runtime.  I intend to do the same before 3rd pary libs appear for VS 2010.


WL

- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Monday, May 17, 2010 4:05 PM
Subject: Re: [osg-users] Development Environment



Hi Wojtek,


FYI: Yesterday I tried to build OSG with 2010. Last stable CMake 2.8.1
is generating some cryptic errors so I checked most recent CMake 2.9.x
from nightly builds. That version seems to work, so if you want to work
with OSG under VS 2010 try nightly builds CMake version.


Are you going to submit a basic set of 3rd party dependencies compiled for 
VS 2010? :-)


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


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

Re: [osg-users] Set fog in the canera StateSet

[Wojciech Lewandowski]

Hi Cristina,

Take it with the grain of salt, as I am not completely sure if this is 
similar problem, but we saw a cases where some StateAttributes set in graph 
nested cameras did not work. Usually solution was adding a group to the 
camera and setup the stateset and scene there. Can you check if this works 
for you ?


If I recall correctly I did small research and noticed that stateset in the 
camera are applied before camera is switched to its rendering surface. I 
don't exactly understand why this could cause problems but the method 
described above was usually avoiding the trouble.


Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC" 


To: 
Sent: Monday, June 01, 2009 10:31 PM
Subject: Re: [osg-users] Set fog in the canera StateSet



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



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

Re: [osg-users] How to apply LISPSM shadows to a scene with differentshaders - Part 3

[Wojciech Lewandowski]

Miguel,

I am not sure whats the problem. Shadows on the ground look ok. So the 
matrices must be ok as well. All I can notice is improper self shadowing on 
soldier models. If this is the case then look at following thread:

http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26683.html

Cheers,
Wojtek


- Original Message - 
From: "Michael Guerrero" 

To: 
Sent: Wednesday, June 03, 2009 11:35 PM
Subject: [osg-users] How to apply LISPSM shadows to a scene with 
differentshaders - Part 3



Hi guys, I'm back to work on getting shadows in my scene only this time 
with
LISPSM.  For some history on integrating your own custom shaders with 
osgShadow

see the following threads:

http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/31360
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/33259/focus=33409

The technique used previously does not work correctly with LISPSM.  In my 
vert
shaders I use the eye planes to transform the view position into texture 
space

like so:

vec4 viewPosition = gl_ModelViewMatrix * gl_Vertex;

gl_TexCoord[3].s = dot(viewPosition, gl_EyePlaneS[1]);
gl_TexCoord[3].t = dot(viewPosition, gl_EyePlaneT[1]);
gl_TexCoord[3].p = dot(viewPosition, gl_EyePlaneR[1]);
gl_TexCoord[3].q = dot(viewPosition, gl_EyePlaneQ[1]);

Then I sample the shadow texture in the frag shader like this:

float shadow = shadow2DProj(osgShadow_shadowTexture, gl_TexCoord[3]).r;

Here's an image showing what I get as a result:
http://img269.imageshack.us/img269/5712/shadowerror.jpg

Has anyone gotten this to work?
Is there an extra step that I'm missing?

Thanks,
Michael Guerrero

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


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

Re: [osg-users] How to apply LISPSM shadows to a scene with differentshaders - Part 3

[Wojciech Lewandowski]

Try this:

http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26683.html

Wojtek

--
From: "Michael Guerrero" 
Sent: Thursday, June 04, 2009 6:22 PM
To: 
Subject: Re: [osg-users]How to apply LISPSM shadows to a scene 
withdifferentshaders - Part 3


Wojciech Lewandowski  writes:



Miguel,

I am not sure whats the problem. Shadows on the ground look ok. So the
matrices must be ok as well. All I can notice is improper self shadowing 
on

soldier models. If this is the case then look at following thread:
http://www.mail-archive.com/osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF 


public.gmane.org/msg26683.html


Cheers,
Wojtek



Thanks Wojciech, this is a self shadowing issue.  However, that link 
doesn't

work for me.  Could you repost?



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


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

Re: [osg-users] How to apply LISPSM shadows to a scene withdifferent shaders - Part 3

[Wojciech Lewandowski]

Michael,

Sorry I am not sure whats going on but it looks like forum/osgmail server 
abbreviates this link somehow. I checked what I sent and it looks like part 
of link is missing.  I attach this link as text file. I hope it will work 
now.


If text attachment gets mangled: Address is following (replace " COLON " 
with ":" and each " SLASH "with "/" )


http COLON SLASH SLASH www.mail-archive.com SLASH 
osg-users@lists.openscenegraph.org SLASH msg26683.html


I hope this goes right this time.

Wojtek



--
From: "Michael Guerrero" 
Sent: Monday, June 08, 2009 6:45 PM
To: 
Subject: Re: [osg-users] How to apply LISPSM shadows to a scene 
withdifferent shaders - Part 3


Sorry, that link just isn't working at all for me.  Could you give me a 
different one or someone relay that information here?


Thanks for your help,
Michael

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





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

http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26683.html___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Multidisplay FBO performance

[Wojciech Lewandowski]

Hi Bryan,

I have similar setup. 8800 GTS Windows XP 32 bit driver version. Drivers 
185.85. Default (undefined USE_FBO) osgviewer cow.osg on two 1280x1024 
screens runs at 600 hz. When graph stats are turned on (second 's' keypress) 
framerate drops to 60-70 hz. When running your modified osgviewer cow.osg I 
see empty blue screen (I assume its ok as cow is drawn to FBO). With USE_FBO 
results vary depending on multithreading mode: singlethreaded is most 
consitent - 300-400 hz. Other modes sometimes run at 700 hz and drop to 60 
hz for a second or two to get back to 700 and drop again after few more 
seconds. Sometimes its stable at 700 sometimes it starts at 60+ hz. All 
tests done only with Hz counter. Invoking graph stats usually drops 
framerate below 100hz.


When 'Single display performance' invoked osgviewer runs on one screen in 
XP. I suppose you are on Vista because I saw drivers work on both screeens 
there.


HTH,
Wojtek Lewandowski


- Original Message - 
From: "Thrall, Bryan" 

To: "OpenSceneGraph Users" 
Sent: Tuesday, June 09, 2009 5:02 PM
Subject: [osg-users] Multidisplay FBO performance



I have a multiple display system with an NVIDIA 8800 GT (driver version
181.20) that has performance problems when I use FBOs (see attached test
case, modified from osgviewer.cpp). My draw times jump from about 7
milliseconds to 14, and my GPU times jump from less than 1ms to 7ms.

The problem goes away when I switch from "Multiple display performance
mode" to "Single display performance mode" in the NVIDIA Control Panel,
so this looks like a driver bug, but I was wondering if anyone was aware
of this problem and any ways around it (I didn't find any discussion of
such a bug via google)?

I'm running on Windows MSVC 2005 using OSG svn rev 10273.

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



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

Re: [osg-users] how to deploy osg application

[Wojciech Lewandowski]

Alena,

There are two versions of VS 2005. VS 2005 and VS 2005 SP1. The same with 
runtime redistributables. If you used VS 2005 SP1 make sure you have installed 
SP1 redist.  Its unfortuante but MS makes them available in the packages named 
exactly the same. So its possible to install older one when newer is needed. 
Google for "Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)" to be 
sure. Maybe this helps

Cheers,
Wojtek   


From: Alena Bacova 
Sent: Wednesday, June 10, 2009 9:08 PM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] how to deploy osg application


Todd,
yes, still no luck.

Alena



2009/6/10 Todd J. Furlong 

  Alena,

  Did you install the Visual Studio 2005 runtime redistributable?

  -Todd 


  On 6/10/2009 2:39 PM, Alena Bacova wrote:

Hi folks,
first of all great forum, I learn new things every day.

My question is: I made an osg ( well osgart) application on my laptop,
with vs 2005 installed and all development environment with it. I
compiled it successfully and now I would like to move it to more
comfortable tablet ( Samsung Q1EX).
I tried to move my build directory with dll libraries but it is giving
me an error: " This application has failed to start because the
application configuration is incorrect. Reinstalling the application may
fix this problem."

Then I tried to copy build directory with osg ( particulary lib and bin
(bin with all the dlls, exe, idb, ilk...)) but I'm getting same error.

I tried to look into cmake configuration files, and also vs.net

 project configurtion files, if I can remove hard links 

to libraries, but nothing helped.

I have never done application deployment so any instructions are more
then welcome.

Thanks.

Alena.


  ___
  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] osgShadow question

[Wojciech Lewandowski]

Serge,

I have no access to the code now. All techniques derived from 
osgShadow::ShadowMap share this limitation. If my memory serves me right they 
all ignore ReceivesShadowTraversalMask. 
But many tricks  or graph rearangments were discussed earlier. For example look 
at this thread:  
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16581.html If 
you look carefully you should be able to find more such posts.  Unfortunately I 
cannot offer more help at this time. 

Cheers,
Wojtek Lewandowski 


From: Serge Lages 
Sent: Wednesday, June 24, 2009 6:31 PM
To: OpenSceneGraph Users 
Subject: [osg-users] osgShadow question


Hi all,

I am currently using osgShadow with the MinimalShadowMap technique. It works 
great but I have a question :

- In my ShadowedScene, I set the children's nodemasks accordingly with the 
CastsShadowTraversalMask and ReceivesShadowTraversalMask properties, but it 
seems to not work, everything cast shadows on everything. Anyone knows if there 
is a way to force an object to not receive the shadows ? Even with a "dirty" 
method (reseting it's tex coords on the drawable or something like that).

Thanks !
Best regards,

-- 
Serge Lages
http://www.tharsis-software.com






___
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] Integrating shadows with osgOcean

[Wojciech Lewandowski]

Hi J-S,

Scenario you described is quite common. My collegue had similar problem 
recently while mixing shadows with soem animation techniques. He was trying 
to come up with similar identification scheme.


Simplest method I can think of: is modification of osgShadow:: LisPSM 
techniques and related to give well defined unique names to rtt cameras they 
create. Its maybe not particularly bright idea but its simple and effective.


I think names like "osgShadow_StandardShadowMapCamera" and 
"osg_MinimalDrawBoundsAnalisisCamera" could do the trick...


Cheers,
Wojtek



- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Thursday, July 09, 2009 10:51 PM
Subject: [osg-users] Integrating shadows with osgOcean



Hi all,

I'm currently trying to integrate osgOcean into our application and I'm 
having trouble combining it with shadows. We're using 
osgShadow::LightSpacePerspectiveShadowMap (and derivatives). The problem 
seems to be that they both do additional RTT passes, and they seem to 
interfere with each other.


I've placed the OceanScene under the ShadowedScene. I'd like to know, in 
OceanScene::traverse(), whether the current traversal is the shadow pass, 
and if so, don't do any reflections or refractions (because that would be 
quite wasteful). The only way I've thought of is doing:


if (cv->getCurrentCamera()->isRenderToTextureCamera())
{
// Shadow pass, don't do reflections etc.
osg::Group::traverse(nv);
}
else
{
// Do the rest as normal.
}

That works, but it strikes me as a blanket check - there may be RTT passes 
where we'll want to have reflections/refractions (i.e. which are not just 
depth buffer passes)...


I wonder if someone would have any suggestion for a better test that would 
be able to detect the shadow pass only...


Thanks in advance,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/

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


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

Re: [osg-users] Integrating shadows with osgOcean

[Wojciech Lewandowski]

Hi J-S,


I was sure you would answer my question :-)


You got me. Say magic word "shadow" and I will crawl up from my den  ;-)

Simplest method I can think of: is modification of osgShadow:: LisPSM 
techniques and related to give well defined unique names to rtt cameras 
they create. Its maybe not particularly bright idea but its simple and 
effective.


I think names like "osgShadow_StandardShadowMapCamera" and 
"osg_MinimalDrawBoundsAnalisisCamera" could do the trick...


Heh... Matching by name always strikes me as a hack. :-) It will work of 
course. The cameras are actually already named "ShadowCamera" and 
"AnalysisCamera".


I have forgotten they are named already.

I thought of something else, perhaps not that much better but a bit more 
general: adding the ShadowTechnique as the UserData of the camera(s). Then 
if the camera has userdata and the userdata's libraryName matches 
osgShadow / ViewDependentShadow then it's a shadow camera. It will work 
for all shadow techniques...


I bet if we think about it we could come up with something even better. 
But for now it will do. Thanks,


Actually,  I like the approach with node names and I don't think this is a 
hack. Node naming is possible in many modelling tools and this is what make 
them quite useful. We often use names to mark special nodes. When such 
models are loaded we run traversals, find special nodes and do some extra 
work there. So names work well as simple link between modelers and 
programmers. I don't see a reason programmers should avoid to use them in 
the same way.


Cheers,
Wojtek

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

Re: [osg-users] Integrating shadows with osgOcean

[Wojciech Lewandowski]

Hi J-S,

Looks to me more like texture/sampler conflict than texgen conflict. I think 
so because shadow on second pictutre looks like some text. I can discern 
letters e and K. Its a long shot but I have no other ideas. You may verify 
if its texgen issue by modifying shaders to display shadow map tex coords 
instead of shadow map texels. If two pictures match then it will mean that 
shadow map got broken or replaced somehow.
Changing shadow map unit and texture coord unit to other number may help as 
well. At leat in this that shadwo map contents will change again, if this is 
a conflict with some ocean shaders/samplers.
One should remember about texgennode/clipnode/lightnode limitation which 
allows only one such node with unit n to be present in sccene graph. If 
there are more at the same unit there will be conflicts.


I doubt it, but maybe this helps ?

Cheers,
Wojtek




- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Tuesday, July 14, 2009 4:31 AM
Subject: Re: [osg-users] Integrating shadows with osgOcean



Hi again Wojtek,

The previous fix of choosing the right camera based on the name worked a
treat. Now I'm grappling with another problem.

It seems that if the ocean surface is in the scene, the texgen used to
lookup in the shadow texture goes all screwy. Of course, I have set the
ocean surface to not cast shadows, so it is not traversed in the shadow
pass. But then, when comes the time to lookup in the shadow texture, I
get shadows all over the place and they move when the camera moves. A
bit hard to describe, but you've probably seen the effect before...

Turning on the shadow debugging camera, I can verify that the shadow
camera is aimed correctly and the bounds seem good. I have also added
control over the ocean surface's node mask in my application, and if I
just set that node mask to 0, the shadows are correct. But if I set it
to its original value (which I also verified contains neither the
CastsShadowTraversalMask nor the ReceivesShadowTraversalMask) then I get
the symptom I tried to describe above.

I've included screenshots of the two situations - with the ocean
surface, and when I set its node mask to 0. In both, you'll see the
shadow camera sees the same thing, but in the first one the shadows are
not applied correctly.

Of course, the near-far settings will be vastly different in the shadow
pass than in the main pass, because the ocean surface is very large but
the shadow casting scene is pretty small. Could that cause this problem?

Any idea about what I could do to solve the problem?

Just a reminder, I'm using the DrawBounds version of LiSPSM.

Thanks in advance,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/








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



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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi J-S and Michele,

As I was summoned by "shadow" spell, I will drop my two cents in this 
discussion. Last time I checked OSG was also creating accompanying color 
buffer for the depth shadow map. Which usually multiplies GPU memory 
alocation by two (assuming RGBA is 32 bit and Z is 32 bit). Considering the 
fact that default multithreaded modes create "double buffered" SceneViews 
which again effectively duplicate all RTT buffers, original size requirement 
for shadow buffer is often 4 times more. If for example you create 4kx4k RTT 
shadow map - OSG will actually allocate 256 MB (!). If your app allocates 
aditional buffers and board has not enough memory this may be the cause of 
the problems. SingleThreaded mode does not utilize double buffered 
SceneViews so this multiplier drops to factor 2.


Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Jean-Sébastien Guay" 

To: 
Sent: Tuesday, July 21, 2009 5:19 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs



Hi Michele,

It seems the issue was caused by using shadow maps that were too large. I 
switched back to 4096 x 4096 and all is well.


4096^2 is already large... Some of our cards here (9800GT) don't support 
them (rendering slows down to ~3fps when at 4096^2, when it's at 60fps 
steady at 2048^2). Others support it well though (9800GTX+, etc.)


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


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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi, J-S

Last time I checked OSG was also creating accompanying color buffer for 
the depth shadow map. Which usually multiplies GPU memory alocation by 
two (assuming RGBA is 32 bit and Z is 32 bit).


Wow, isn't that a bug? It surprises me that no one has tried to fix that, 
it seems pretty critical to me...


I am not sure... I believe that it was impossible to use depth only FBO when 
they were initially introduced into OpenGL . But now it seems possible at 
least on NVidia's because I made such modificattion and it works ( in fact 
it gave me shadowing speedup improvements). But I did not try to submit this 
because I have not bothered to make it safe and  I did not test whether mod 
does not break other RTT code. I may send this "as is" if you are 
interested.


Cheers,
Wojtek 


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

Re: [osg-users] osgShadow::ShadowedScene + multiple parental node paths

[Wojciech Lewandowski]

Daniel,

Frankly, I have never thought about such usage. I must admit that  LispSM 
was not prepared for such scenario. All ViewDependentShadowTechniques 
(LispSM included) make assumption that there is one technique per View.  I 
suppose that even if you use the same ShadowTechnique object but create two 
parental paths it will work like there were two independent instances 
rivalling for the same resources (shadow map /shadow cam view & projection 
matrices/ texgen). So it will not work either.


I am not sure  if this is possible with your app but you may solve the 
problem by adding separate slave  cameras (like HUD cams) for each extra 
ShadowedScene. But it will only work with extra slave or extra view. Nesting 
RTT camera in graph will not be enough. Each ViewDependentTechnique (and 
derived classes) use ptr to CullVisitor to identify View and create separate 
set of resources for this view. Graph nested cams use the same visitor as 
their parent View so it will be impossible to identify which cam is actually 
rendering and conflicts will be still present.



Cheers,
Wojtek Lewandowski

--
From: "Daniel Lazaroff" 
Sent: Tuesday, July 21, 2009 6:23 PM
To: 
Subject: [osg-users] osgShadow::ShadowedScene + multiple parental node paths


Hi guys,

I have been using the LSPSM technique with great visual results so far, 
but I seem to be having an issue with the osgShadow::ShadowedScene node 
and multiple parental node paths.


If the ShadowedScene node is deep into my scene graph and has a single 
getParentalNodePaths() there are no problems. But once I have more than 
one, the shadowing seems to be gone in the simplest of sg designs.


Probably there is a simple explanation or I am missing an important point, 
thanks for any response !


Cheers,
Daniel

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





___
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] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi J-S,

I think if it gives a verifiable gain (less video memory used for depth 
component RTT) then you can submit it. As you know, submission does not 
mean that you need to be confident that it does not break anything, it 
means that you are sending it for review. Robert will check it out, if 
there are problems he might see them or if he's not sure then he'll call 
for more testing by others who use that functionality.


I saw direct improvement on GF 7800. On newer boards its smaller unless the 
OSG application is GPU memory bound. Which happens quite often in our 
practice.


At least it would mean that some progress is being made in the right 
direction :-)


I hope you consider sending your changes,


Code attached. Changes are quite simple. You may as well test them. 
Considering Robert tight schedules I doubt he will be eager to play with it.


Cheers,
Wojtek 
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
*
* This library is open source and may be redistributed and/or modified under  
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
* (at your option) any later version.  The full license is in LICENSE file

* included with this distribution, and on the openscenegraph.org website.
* 
* This library is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
* OpenSceneGraph Public License for more details.

*/
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 


using namespace osg;
using namespace osgUtil;

// register a RenderStage prototype with the RenderBin prototype list.
//RegisterRenderBinProxy s_registerRenderStageProxy;

RenderStage::RenderStage():
   RenderBin(getDefaultRenderBinSortMode()),
   _disableFboAfterRender(true)
{
   // point RenderBin's _stage to this to ensure that references to
   // stage don't go tempted away to any other stage.
   _stage = this;
   _stageDrawnThisFrame = false;

   _drawBuffer = GL_NONE;
   _readBuffer = GL_NONE;
   _clearMask = GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT;
   _clearColor.set(0.0f,0.0f,0.0f,0.0f);
   _clearAccum.set(0.0f,0.0f,0.0f,0.0f);
   _clearDepth = 1.0;
   _clearStencil = 0;

   _cameraRequiresSetUp = false;
   _camera = 0;
   
   _level = 0;

   _face = 0;
   
   _imageReadPixelFormat = GL_RGBA;

   _imageReadPixelDataType = GL_UNSIGNED_BYTE;
}

RenderStage::RenderStage(SortMode mode):
   RenderBin(mode),
   _disableFboAfterRender(true)
{
   // point RenderBin's _stage to this to ensure that references to
   // stage don't go tempted away to any other stage.
   _stage = this;
   _stageDrawnThisFrame = false;

   _drawBuffer = GL_NONE;
   _readBuffer = GL_NONE;
   _clearMask = GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT;
   _clearColor.set(0.0f,0.0f,0.0f,0.0f);
   _clearAccum.set(0.0f,0.0f,0.0f,0.0f);
   _clearDepth = 1.0;
   _clearStencil = 0;

   _cameraRequiresSetUp = false;
   _camera = 0;
   
   _level = 0;

   _face = 0;
   
   _imageReadPixelFormat = GL_RGBA;

   _imageReadPixelDataType = GL_UNSIGNED_BYTE;
}

RenderStage::RenderStage(const RenderStage& rhs,const osg::CopyOp& copyop):
   RenderBin(rhs,copyop),
   _stageDrawnThisFrame(false),
   _preRenderList(rhs._preRenderList),
   _postRenderList(rhs._postRenderList),
   _viewport(rhs._viewport),
   _drawBuffer(rhs._drawBuffer),
   _readBuffer(rhs._readBuffer),
   _clearMask(rhs._clearMask),
   _colorMask(rhs._colorMask),
   _clearColor(rhs._clearColor),
   _clearAccum(rhs._clearAccum),
   _clearDepth(rhs._clearDepth),
   _clearStencil(rhs._clearStencil),
   _cameraRequiresSetUp(rhs._cameraRequiresSetUp),
   _camera(rhs._camera),
   _level(rhs._level),
   _face(rhs._face),
   _imageReadPixelFormat(rhs._imageReadPixelFormat),
   _imageReadPixelDataType(rhs._imageReadPixelDataType),
   _disableFboAfterRender(rhs._disableFboAfterRender),
   _renderStageLighting(rhs._renderStageLighting)
{
   _stage = this;
}


RenderStage::~RenderStage()
{
}

void RenderStage::reset()
{
   _stageDrawnThisFrame = false;
   
   if (_renderStageLighting.valid()) _renderStageLighting->reset();


   for(RenderStageList::iterator pre_itr = _preRenderList.begin();
   pre_itr != _preRenderList.end();
   ++pre_itr)
   {
   pre_itr->second->reset();
   }

   RenderBin::reset();

   for(RenderStageList::iterator post_itr = _postRenderList.begin();
   post_itr != _postRenderList.end();
   ++post_itr)
   {
   post_itr->second->reset();
   }

   _preRenderList.clear();
   _postRenderList.clear();
}

void RenderStage::sort()
{
   for(RenderStageList::iterator pre_itr = _preRenderList.begin();
   pre_itr != _preRenderList.end();
   ++pre_itr)
   {
   pre_itr->second->sort();
   }

   RenderBin::sort();

   for(RenderStageList::iterator post_itr = _postRenderList.beg

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi J-S,

> Looking at the code, it seems like the same thing happens with the depth
buffer, i.e. a depth attachment will be created if none is present. IMHO, 
a depth buffer is not mandatory - you could want to do an RTT pass on a 
single fullscreen quad, in which case you don't need depth and can disable 
depth test. In that case, wouldn't it make sense to only attach a color 
buffer? An added depth buffer will only add to the video memory 
requirements.


In other words, can't we trust the user to have set up their FBO 
attachments correctly? In these two cases, the code checks if there's a 
given attachment (depth or color) and if not, unconditionally adds one 
whether the user needs it or not. The code can't know exactly what the 
user needs, but isn't it better to be conservative instead of creating 
everything in case the user needs it but doesn't know it?


GL_EXT_framebuffer_object spec allows FBOs without color attachments. 
http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt see issue 
(45) ). Its only an intutition but I suspect there were times that despite 
the specs both attachments were required by the drivers and FBO would not 
work without them.


Cheers,
Wojtek Lewandowski 


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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi ,

The code in osgUtil/RenderStage.cpp (as it stands now) automatically 
attaches a depth buffer if there is none, and a color buffer if there is 
none. Perhaps this code should be removed. If this causes problems to 
applications on some drivers/cards, I think it's up to the application to 
implement the workaround of adding a dummy color or depth buffer in those 
cases, instead of forcing all OSG applications to use that workaround and 
the associated video memory usage increase, even when it's not needed on 
the driver/card...




I agree. We may raise this subject when Robert comes back. He probably knows 
why RenderStage does this.


WL. 


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

Re: [osg-users] question about available feature support for DirectDraw Surface

[Wojciech Lewandowski]

Hi Andreas,

DDS is flexible container format capable of storing 2D, 3D, Cube and Array 
Textures (with or without mipmaps) in many pixel formats. Block compressed 
pixel formats like DXTn, RGTC (3Dc) and LATC are supported. Of course I 
don't know all existing image formats but I learned about a few and I guess 
this is the only format capable to store every type of texture with every 
type of pixel format used nowadays.


DDS files are not compressed for file storage and they don't require 
decompression which means they load quite quicly. PNG and JPG require this. 
DDS in OSG has support for a number of most used pixel formats (but not all) 
and 2D & 3D textures. I am not 100% sure here but CubeMaps and Texture 
Arrays are not supported yet by OSG DDS reader writer.


But there is one issue you should be aware about. DDS is simple wrap of 
DirectDrawSurface texture. DirectDraw and Direct3D assume that surface 
origin is in upper left corner while OpenGL assumes lower left. To maintain 
orientation its neccessary to flip DDS files that were built for DD, D3D 
use. This flip does require some software work after image was loaded. Or 
alternatively one may flip the image in authoring tools before saving as 
DDS.


But if you generate these DDSes with OSG and later load them with OSG 
problem disappers because you use the same oritentation they were created 
in.


Cheers,
Wojtek Lewandowski

- Original Message - 
From: 

To: 
Sent: Friday, July 24, 2009 11:03 AM
Subject: [osg-users] question about available feature support for DirectDraw 
Surface




Hello OpenSceneGrapher!

I want to texture by shading some geodes that are sticked together as a 
huge landscape. I wonder what file format for the textures is most 
suitable. Usually I take squared JPG. But short while ago I read about 
Direct Draw Surface (DDS) which supports mipmaps.


Does anybody here has experience in using DDS? I'm interested in the OSG 
support of the DDS features and if it's worth using this file format 
instead of the classic one's like JPG or PNG.

Looking forward to your suggestions.

Regards,
--
Andreas Richter
___
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] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi Robert,


One problem that this change might introduce is that if users make not
explicitly specified both a depth and colour buffers in their Camera
settings, but instead have relied upon this behavior of RenderStage.


I think a solution could be adding default COLOR_BUFFER and DEPTH_BUFFER 
attachments to FBO Cameras. They are not set currently and thus dirty work 
of setting them is done by RenderStage. If they were set by default in 
Camera users could directly override or remove them.


If they were set by default it should also work for those who relied on 
their presence.


Cheers,
Wojtek Lewandowski


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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Thanks Robert,


I think a solution could be adding default COLOR_BUFFER and DEPTH_BUFFER
attachments to FBO Cameras. They are not set currently and thus dirty 
work

of setting them is done by RenderStage. If they were set by default in
Camera users could directly override or remove them.

If they were set by default it should also work for those who relied on
their presence.


I think this would be a good solution, although I'd rather user code
explicitly enables this stuff rather than make assumptions about
defaults as defaults can always change...


I agree. Such camera attachment defaults make situation much more 
unpredicable. We don't know what issues it may bring. On the other hand, 
forcing users to explicitly define attachments is only a small one time pain 
for those users who relied on current RenderStage behaviour.


Cheers,
Wojtek


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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi J-S,



Is this really needed? I know we don't want to break users' existing apps, 
but in general, we should assume they know what they're doing right?


The solution above would mean that someone who knows what they're doing 
would need to remove attachment(s) instead of adding just the ones they 
need (which is counter-intuitive IMHO). If nothing is set by default then 
the programmer has to think about what attachments they need, and using no 
attachments could result in a clear error message that you need to add the 
attachments you need to your FBO camera...


What do you think?


We all agree. Lets make atachment selection explicit.  My proposal was just 
an rhetoric response (if I may say so;-) to rhetoric question Robert asked.


Wojtek 


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

Re: [osg-users] question about available feature support for DirectDraw Surface

[Wojciech Lewandowski]

Hi Andreas,


First thanks for the quick response. You wrote:


DDS files are not compressed for file storage and they
don't require decompression which means they load quite
quicly. PNG and JPG require this.


If you say, DDS files are not compressed, the DXTn compression doesn't 
matter, because the algorithms are hardware accelerated?
Did this features (being not compressed) pays off even if I write my scene 
into an IVE-file and load this file later on in another OSG application? I 
would say no, because PNG and JPG textures will also be stored 
decompressed, isn't it?


Let me make it clear: I deliberately made a distinction between compressed 
pixel and compressed image. Few DDS supported ixel formats like DXTn use 
block compression (packing). Its something bit different than image file 
compression. Such image resides in the same packed pixel format on disk and 
in the texture memory.


PNG and JPG usually take less space on disk but while loading into RAM are 
decompressed to 8 bit per component RGB or RGBA, L, LA. So in practice their 
compression is used to make their file representation on disk smaller but 
images in memory occupy as much space as uncompressed images.


Since DDS suports many pixel formats,  you can for example use DDS to store 
unpacked 8 bit per component RGBA which effectively takes 32 bits per pixel. 
But you may also use DDS for DXT1 or DXT3 or DXT5 packed pixels so that 
effectively 1 pixel takes 4(DXT1) or 8(DXT3/DXT5) bits.


All depends on application type. I would say that Web app should rather use 
JPG or PNG because they are smaller and load faster from remote URLs. But if 
your app is hard vis sim which tries to make best use of available GPU 
memory then go for DXT1 or DXT3/DXT5 because startup file loading does not 
matter that much as target framerates.


W.r.t IVE, lets suppose you load a model with textures stored as DXTn DDS 
and save it to ive. The textures will remain packed in IVE ie they will 
still be stored as DXTn. Now lets do the same with model with textures in 
JPG. The textures will be unpacked to 8 bit per component and as such stored 
in IVE.

So second model will be bigger than first one.

When creating IVE with osgconv you can use the option to convert textures to 
DXTn format:  --compressed-dxt1  --compressed-dxt3  --compressed-dxt5


HTH,
Cheers,
Wojtek 


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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi J-S,

We all agree. Lets make atachment selection explicit.  My proposal was 
just an rhetoric response (if I may say so;-) to rhetoric question Robert 
asked.


OK, so who does it? :-)


Smart move. I can do this. But only if you take the "evangelization" part 
;-)


If you have the time, I'd be more comfortable if you made the change, as I 
haven't touched that code (only read it) so it may have other implications 
I won't think of.


I will do it somewhere in next week. However, I doubt I will be able to 
forese all implications. Of course others will help when we merge the 
changes ;-)


Cheers,
Wojtek Lewandowski

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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi Robert,


I've just has a look at your changed RenderStage. The changed code is
below.  Is there a reason why the #if !FORCE_COLOR_ATTACHMENT which
disables the draw and read buffer is done after the FBO apply?  I
looks to me that one could simply have an #ifdef/#else.  I do also
wonder whether this is glDrawBuffer( GL_NONE ); etc. is even needed as
well - as wouldn't the Camera provide the appropriate settings via the
Read and DrawBuffer fields.


Frankly, this is something that puzzles me as well. I wrote this code only 
to test  if color attachment enforcement could be easily removed. It was 
never  intended as formal submission. It did it a year ago and I do not 
remember why I have added glDrawBuffer( GL_NONE ); glReadBuffer( GL_NONE ) 
calls. I suppose I did it because original attempt did not work as intended.


Ok I think I recall what was my goal. If there was no color attachment I 
wanted to make sure glDrawBuffer and glReadBuffer are set to NONE because 
otherwise OpenGL would  assume that they are set to colorbuffers of 
backbuffer/frontbuffer. And I did it after fbo->apply because I thought that 
fbo->apply may call these functions with other flags.


It needs to be verified if I was right and this part was really needed. As I 
said before this was not intended as submission and I had not make serious 
study of its implications. I may try to look at this topic again in next 
week.


Wojtek

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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

I meant "evangelism" as "spreading the word".  In other words you do the PR 
for this modification.  ;-)


Wojtek

- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Friday, July 24, 2009 4:21 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs



Hi Wojtek,

Smart move. I can do this. But only if you take the "evangelization" part 
;-)


I don't know what evangelism means in this context... It seems to me that 
it just allows users to make better use of the resources they have.


But yeah, if you equate evangelism with being opinionated, I can do that 
:-)


I will do it somewhere in next week. However, I doubt I will be able to 
forese all implications. Of course others will help when we merge the 
changes ;-)


Whenever you want, it's not an urgent feature... Just an interesting 
improvement.


Thanks a lot,

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


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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi Robert,

I made a check yesterday. glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT) 
fails if glDrawBuffer & glReadBuffer are not set ot GL_NONE.
Look at GL_EXT_framebuffer_object extension description 
http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt


Usage Example (7):
(7) Render to depth texture with no color attachments

   // Given:  depth_tex - TEXTURE_2D depth texture object
   // fb- framebuffer object

   // Enable render-to-texture
   glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fb);

   // Set up depth_tex for render-to-texture
   glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
 GL_DEPTH_ATTACHMENT_EXT,
 GL_TEXTURE_2D, depth_tex, 0);

   // No color buffer to draw to or read from
   glDrawBuffer(GL_NONE);
   glReadBuffer(GL_NONE);

   // Check framebuffer completeness at the end of initialization.
   CHECK_FRAMEBUFFER_STATUS();

   

   // Re-enable rendering to the window
   glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

   glBindTexture(GL_TEXTURE_2D, depth_tex);
   
Cheers,
Wojtek


- Original Message - 
From: "Wojciech Lewandowski" 

To: "OpenSceneGraph Users" 
Sent: Friday, July 24, 2009 4:25 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs



Hi Robert,


I've just has a look at your changed RenderStage. The changed code is
below.  Is there a reason why the #if !FORCE_COLOR_ATTACHMENT which
disables the draw and read buffer is done after the FBO apply?  I
looks to me that one could simply have an #ifdef/#else.  I do also
wonder whether this is glDrawBuffer( GL_NONE ); etc. is even needed as
well - as wouldn't the Camera provide the appropriate settings via the
Read and DrawBuffer fields.


Frankly, this is something that puzzles me as well. I wrote this code only 
to test  if color attachment enforcement could be easily removed. It was 
never  intended as formal submission. It did it a year ago and I do not 
remember why I have added glDrawBuffer( GL_NONE ); glReadBuffer( GL_NONE ) 
calls. I suppose I did it because original attempt did not work as 
intended.


Ok I think I recall what was my goal. If there was no color attachment I 
wanted to make sure glDrawBuffer and glReadBuffer are set to NONE because 
otherwise OpenGL would  assume that they are set to colorbuffers of 
backbuffer/frontbuffer. And I did it after fbo->apply because I thought 
that fbo->apply may call these functions with other flags.


It needs to be verified if I was right and this part was really needed. As 
I said before this was not intended as submission and I had not make 
serious study of its implications. I may try to look at this topic again 
in next week.


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] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi Robert & J-S,

Sorry if I am bit late with the answers. I have browsed the code to know 
what we are talking about ;-)



[...] right thing to do would be to refactor
this code so it allowed the setting of the draw and read buffer values
directly even with the value is GL_NONE.  As things stand by filtering
out GL_NONE the code is effectively inheriting the state from the
previous Camera.



[...], but if apps are making assumptions in
their osg::Camera setup about the current inheritance of state when
GL_NONE then we could break existing apps.  I do rather prefer
explicit setting of Draw/ReadBuffer value in apps though, as assuming
default will always work for you is dangerous.


I cannot imagine how such explicit setting of glDrawBuffer/glReadBuffer 
could be done without  setDrawBuffer / setReadBuffer methods in osg::State 
(and/or in osg::Camera) ... If you suggest refactoring, I think the best way 
to tackle it would be adding such methods and corresponding variables to 
osg::State and allow the State to handle lazy update of buffers when needed. 
It seems to me that these complex checks in RenderStage are trying to 
accomplish the same as lazy update: change the buffers only when this is 
neccessary.


I think we should remove _drawBuffer / _readBuffer variables and part of 
corresponding logic from RenderStage and move it to osg::State. In the same 
refactorization let GL_NONE to be set. Then let all OSG code liberally set 
buffers with state.setDrawBuffer() and state.setReadBuffer() calls. Lazy 
update will control when they really change.


I also think we shouldn't worry about users who rely on sideffects of 
current code. We earlier decided we are going to blow up user comfort of 
default ColorAttachments/DepthAttachments. So now its just a consequence. We 
should feel free to to the same with DrawBuffers/ReadBuffers. J-S will 
simply have more to explain to frustrated users for whom OSG stopped working 
;-)



The solution that you took of forcing glDrawBuffer & glReadBuffer to
GL_NONE in the case when no colour buffer is applied should probably
wrapped up in the above glDrawBuffer/glReadBuffer code rather than in
it's own block as otherwise the logic will get hard to follow if we
are setting the same state in multiple places.


I agree. But instead of RenderStage::setDrawBuffer( ) & 
RenderStage::setReadBuffer( ) I would rather call  State::setDrawBuffer() 
State::setReadBuffer( ).


I suppose corresponding getDrawBuffer/getReadBuffer plus similar set of 
calls for multiple DrawBuffers should probably be added to State.


What do you think ?

Cheers,
Wojtek




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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Hi Robert,


In terms of the existing RenderStage::_draw/_renderBuffers values,
this is currently set by the CullVisitor + SceneView, so rather than
being their for lazy state updating it's there as means of passing
values for high level set up to the lower level draw traversal so
would need to remain.


I think we are pretty much on the same page. Question (which J-S asked) is 
who does this ? I may not uderstand all the intricacies, but I promised to 
look at the code and come up with submission proposal in next few days. I ll 
try do to my best, but let me know, if You feel like its better to leave the 
problem for You to solve.


Cheers,
Wojtek



On Mon, Jul 27, 2009 at 1:17 PM, Wojciech
Lewandowski wrote:

Hi Robert & J-S,

Sorry if I am bit late with the answers. I have browsed the code to know
what we are talking about ;-)


[...] right thing to do would be to refactor
this code so it allowed the setting of the draw and read buffer values
directly even with the value is GL_NONE. As things stand by filtering
out GL_NONE the code is effectively inheriting the state from the
previous Camera.



[...], but if apps are making assumptions in
their osg::Camera setup about the current inheritance of state when
GL_NONE then we could break existing apps. I do rather prefer
explicit setting of Draw/ReadBuffer value in apps though, as assuming
default will always work for you is dangerous.


I cannot imagine how such explicit setting of glDrawBuffer/glReadBuffer
could be done without setDrawBuffer / setReadBuffer methods in osg::State
(and/or in osg::Camera) ... If you suggest refactoring, I think the best 
way

to tackle it would be adding such methods and corresponding variables to
osg::State and allow the State to handle lazy update of buffers when 
needed.

It seems to me that these complex checks in RenderStage are trying to
accomplish the same as lazy update: change the buffers only when this is
neccessary.

I think we should remove _drawBuffer / _readBuffer variables and part of
corresponding logic from RenderStage and move it to osg::State. In the 
same

refactorization let GL_NONE to be set. Then let all OSG code liberally set
buffers with state.setDrawBuffer() and state.setReadBuffer() calls. Lazy
update will control when they really change.

I also think we shouldn't worry about users who rely on sideffects of
current code. We earlier decided we are going to blow up user comfort of
default ColorAttachments/DepthAttachments. So now its just a consequence. 
We

should feel free to to the same with DrawBuffers/ReadBuffers. J-S will
simply have more to explain to frustrated users for whom OSG stopped 
working

;-)


The solution that you took of forcing glDrawBuffer & glReadBuffer to
GL_NONE in the case when no colour buffer is applied should probably
wrapped up in the above glDrawBuffer/glReadBuffer code rather than in
it's own block as otherwise the logic will get hard to follow if we
are setting the same state in multiple places.


I agree. But instead of RenderStage::setDrawBuffer( ) &
RenderStage::setReadBuffer( ) I would rather call State::setDrawBuffer()
State::setReadBuffer( ).

I suppose corresponding getDrawBuffer/getReadBuffer plus similar set of
calls for multiple DrawBuffers should probably be added to State.

What do you think ?

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


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

Re: [osg-users] Frame rates vary dramatically across runs

[Wojciech Lewandowski]

Robert,

I'll try to do it.
Enjoy your vacations,

Wojtek

- Original Message - 
From: "Robert Osfield" 

To: "OpenSceneGraph Users" 
Sent: Monday, July 27, 2009 4:37 PM
Subject: Re: [osg-users] Frame rates vary dramatically across runs



Hi Wojtek,

On Mon, Jul 27, 2009 at 3:23 PM, Wojciech
Lewandowski wrote:
I think we are pretty much on the same page. Question (which J-S asked) 
is
who does this ? I may not uderstand all the intricacies, but I promised 
to
look at the code and come up with submission proposal in next few days. I 
ll
try do to my best, but let me know, if You feel like its better to leave 
the

problem for You to solve.


I'm just about to head off on another weeks family holiday so I won't
be able to take on work right away, so please feel free in diving in
and making the required changes.  Any changes it'd be worth pushing on
to the list to get them tried out.

Cheers,
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] FBOs without color or depth attachments / DrawBuffer / ReadBuffer

[Wojciech Lewandowski]

Hi Robert, hi J-S

I'll remind the conclusions of our discussion in case someone new to the 
topic is interested:


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

Cheers,
Wojtek Lewandowski 


___
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] osgShadow and nested RTT-cams

[Wojciech Lewandowski]

Hi Felix,

Felix Heide wrote:

no one has an idea ?
  
Unfortunately, I don't have much to offer as I have no access to OSG 
source currently. But my intuition tells me that your case was not 
widely tested. I think you may have better chances when you setup your 
RTT rendering as separate slave camera instead of nested in the graph 
cam. See  osg hud examples on how to setup RTT cam as osgViewer slave (I 
don't remeber exactly which one). Hope this helps


Wojtek Lewandowski

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

Hi Mathias,



[..]. I noticed that when DEPTH_ATTACHMENT is not
forced, depth tests in Prerender fail and Cow.osg or Cessna.osg are
displayyed with "holes". So it would be necccesary to test all examples
using FBOs and check if they require exlpicit setting of depth
attachments. Once examples are fixed one may turn off
FORCE_DEPTH_ATTACHMENT in RenderStage.cpp.

This sounds exactly like the issue I'm currently experiencing. I've 
already tried to find some help in this topic: 
http://forum.openscenegraph.org/viewtopic.php?t=3322
I had to create/manage my own FBO since I need a handle to it for 
various reasons. Basically I'm trying to do RTT. This means my FBO has 
just a texture2d attached to it (as GL_COLOR_ATTACHMENT).
Do you know what the reason for this behaviour is? Am I right that 
attaching a depth attachment to an FBO solves the issue? What is 
different in your implementation when FORCE_DEPTH_ATTACHMENT is set?
The screenshot you posted on the forum shows exactly the same result I 
had with osgPrerender when FBO had no depth buffer attached. So, yes, I 
would bet that attaching depth renderbuffer or texture should help in 
your trouble. No depth attachment has the same result as  GL_DEPTH_TEST 
mode turned to off. So faces of the model are not z-sorted properly.


Hope this helps,
Wojtek Lewandowski
___
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]

Thanks, Robert

I tested the changes on Windows and NVidia GF 8800. osghadow -4 --lispsm 
looked correct on my system. But I understand other systems may be 
different.


I am curious if setting ShadowCamera->attach( COLOR_BUFFER,  GL_RGB ) would 
have the same effect as forcing COLOR_ATTACHMENT on ATI. I suppose it 
should. From the former discussion with J-S I come up with opinion that the 
best would be to not define OSG color/depth attachment policy but put the 
decision on application developers. If their application is run with 
troublesome drivers, programmers would explicitly attach missing buffer to 
be sure everything works on target platform. I think that adding a line: 
camera->attach( COLOR_BUFFER,  GL_RGB );  is as easy as changing 
DisplaySettings flags for FBO buffer attachment policy.


On the other hand, it will also work for me if OSG majority decides to 
introduce such FBO attachments policy and will use DisplaySettings for this 
task. I have not used .cfg files and DisplaySettings extensively yet (at 
least not under various OSes)  so I will leave question about DisplaySetting 
script format for more opinionated users ;-)


Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" 

To: "OpenSceneGraph Users" 
Sent: Friday, August 21, 2009 11:39 AM
Subject: Re: [osg-users] FBOs without color or depth attachments/DrawBuffer/ 
ReadBuffer




Hi Wojtek et. al,

I have just checked in the changes but to avoid regression on some
users systems I've temporarily reverted the disabling of the forcing
on of colour and depth buffer. But setting:

#define FORCE_COLOR_ATTACHMENT  1
#define FORCE_DEPTH_ATTACHMENT  1

At the top of src/osgUtil/RenderStage.  I say temporarily as I believe
we'll need to come up with a runtime override scheme that allows users
to set the defaults for the above at runtime, perhaps via the the
standard osg::DisplaySettings class that is used right now for various
global settings, with env vars available to customize the defaults.

It could be that we need to come up with a simple file format for
specifying these types defaults for various hardware/OS targets, and
make it possible to load this file at runtime to configure things.
This is a more general issue than just FBOs, but this FBO issue is
probably a good catlyst for getting some kind of solution.

Thoughts? Suggestions?
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

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

[Wojciech Lewandowski]

Hi again,

I realized there is gap in my argumentation in my former post. OSG user may 
chose to add camera->attach( MISSING_BUFFER, FORMAT) in their application, 
but OSG nodekits like osgShadow  have to be safe and prepared even for bad 
cases. So it looks like flags defining policy for forcing missing buffer 
attchments may be neccessary after all. So I must agree that adding buffer 
atttcahment flags to DisplaySetings sounds like the best approach.


Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Wojciech Lewandowski" 

To: "OpenSceneGraph Users" 
Sent: Friday, August 21, 2009 3:08 PM
Subject: Re: [osg-users] FBOs without color or depth 
attachments/DrawBuffer/ReadBuffer





Thanks, Robert

I tested the changes on Windows and NVidia GF 8800. osghadow -4 --lispsm 
looked correct on my system. But I understand other systems may be 
different.


I am curious if setting ShadowCamera->attach( COLOR_BUFFER,  GL_RGB ) 
would have the same effect as forcing COLOR_ATTACHMENT on ATI. I suppose 
it should. From the former discussion with J-S I come up with opinion that 
the best would be to not define OSG color/depth attachment policy but put 
the decision on application developers. If their application is run with 
troublesome drivers, programmers would explicitly attach missing buffer to 
be sure everything works on target platform. I think that adding a line: 
camera->attach( COLOR_BUFFER,  GL_RGB );  is as easy as changing 
DisplaySettings flags for FBO buffer attachment policy.


On the other hand, it will also work for me if OSG majority decides to 
introduce such FBO attachments policy and will use DisplaySettings for 
this task. I have not used .cfg files and DisplaySettings extensively yet 
(at least not under various OSes)  so I will leave question about 
DisplaySetting script format for more opinionated users ;-)


Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" 

To: "OpenSceneGraph Users" 
Sent: Friday, August 21, 2009 11:39 AM
Subject: Re: [osg-users] FBOs without color or depth 
attachments/DrawBuffer/ ReadBuffer




Hi Wojtek et. al,

I have just checked in the changes but to avoid regression on some
users systems I've temporarily reverted the disabling of the forcing
on of colour and depth buffer. But setting:

#define FORCE_COLOR_ATTACHMENT  1
#define FORCE_DEPTH_ATTACHMENT  1

At the top of src/osgUtil/RenderStage.  I say temporarily as I believe
we'll need to come up with a runtime override scheme that allows users
to set the defaults for the above at runtime, perhaps via the the
standard osg::DisplaySettings class that is used right now for various
global settings, with env vars available to customize the defaults.

It could be that we need to come up with a simple file format for
specifying these types defaults for various hardware/OS targets, and
make it possible to load this file at runtime to configure things.
This is a more general issue than just FBOs, but this FBO issue is
probably a good catlyst for getting some kind of solution.

Thoughts? Suggestions?
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] world space to screen space & matrices understanding

[Wojciech Lewandowski]

Hi Harold,

OSG uses standard C arrays to store matrices. Which means these are row major 
matrices. This changes order of operands. You should multiply point by matrix 
not matrix by point. In your code you should rather preMultiply the matrices. 

example: 

osg::Matrix viewMatrix = camera->getViewMatrix();

osg::Vec3d viewSpacePoint = worldSpacePoint * viewMatrix;

Cheers,
Wojtek Lewandowski

  - Original Message - 
  From: Harold Comere 
  To: osg-users@lists.openscenegraph.org 
  Sent: Friday, September 04, 2009 1:30 PM
  Subject: [osg-users] world space to screen space & matrices understanding


  Hi all,

  I'm trying to simply project any 3D point ,which is already in world space, 
into screen space.

  I know how to do it without osg :
  screen space coords = bias matrix * camera projection matrix * camera view 
matrix * world space coordinates
  Those coordinates are in [0, 1] range, so multiply by viewport dimensions to 
get window coordinates.

  but i do not succeed doing it with osg because i m still not familiar with 
it...
  My current code is 

 osg::Camera * cam = _view->getCamera();
 osg::Matrix viewMatrix = cam->getViewMatrix();
 osg::Matrix projectionMatrix = cam->getProjectionMatrix();
 osg::Matrix windowMatrix = cam->getViewport()->computeWindowMatrix();

 osg::Vec4d screenCoords = windowMatrix.postMult (projectionMatrix.postMult 
(viewMatrix.postMult (_refPoint)));

  I saw windowMatrix is the bias matrix and the viewport scale.
  refPoint is a Vec4d with w = 1. ( the 3D point i want to project into screen 
space )  and as operator * is not defined to multiply a Matrix with an Vec4d, i 
use postMult function.

  But i dont get a valid result... what did i missed ? :-x
  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] world space to screen space & matrices understanding

[Wojciech Lewandowski]

Hi Harold,

> osg::Vec3d screen Coords = _refPoint * viewMatrix * projectionMatrix * 
> windowMatrix;

If model matrix is identity, above formula should work. Are you sure your point 
is in the frustum ? Do you see it ? If you do, then maybe you skipped model 
matrix (are there any Transforms set as ancestors?) Or maybe one of the 
matrices in your formula (most probably view or projection) has changed since 
you retrieved it ? View matrix is updated by manipulators in event traversal, 
if you read it before there is a chance it got updated. I guess auto NEAR/FAR 
projection adjustment should not matter here, but to be really safe, check if 
DO_NOT_COMPUTE_NEAR_FAR camera flag changes anything. Also, to be 100% sure I 
would check windowMatrix under debugger if it really corresponds to your 
expected viewport.

You should get the same results with vec4 and vec3. If you use 4d coords make 
sure to divide xyz by w before retrieving 3d coord part. 

Wojtek
  - Original Message - 
  From: Harold Comere 
  To: OpenSceneGraph Users 
  Sent: Friday, September 04, 2009 2:45 PM
  Subject: Re: [osg-users] world space to screen space & matrices understanding


  Hi Wojciech,

  Thanks for your answer.
  I did what you suggest at my first try following an old topic about this 
subject. But as i had not understand why it uses a premult i changed it, thanks 
for explanation.

  If i use this code, i get near good result, using Vec3d instead of Vec4d with 
homogeneous coordinates
 osg::Vec3d screenCoords = _refPoint * viewMatrix * projectionMatrix * 
windowMatrix;

  i get screen coords (  1069,  970, 1. ) but my viewport is ( 0, 0, 1024, 768 
).
  The refPoint is in the view frustum so this result is not valid too :-x

  If i use a Vec4d to have homogeneous coordinates, i get a worth result ... 
i'm a bit confused.

  Regards,
  Harold



  2009/9/4 Wojciech Lewandowski 

Hi Harold,

OSG uses standard C arrays to store matrices. Which means these are row 
major matrices. This changes order of operands. You should multiply point by 
matrix not matrix by point. In your code you should rather preMultiply the 
matrices. 

example: 

osg::Matrix viewMatrix = camera->getViewMatrix();

osg::Vec3d viewSpacePoint = worldSpacePoint * viewMatrix;

Cheers,
Wojtek Lewandowski

  - Original Message - 
  From: Harold Comere 
  To: osg-users@lists.openscenegraph.org 
  Sent: Friday, September 04, 2009 1:30 PM
  Subject: [osg-users] world space to screen space & matrices understanding


  Hi all,

  I'm trying to simply project any 3D point ,which is already in world 
space, into screen space.

  I know how to do it without osg :
  screen space coords = bias matrix * camera projection matrix * camera 
view matrix * world space coordinates
  Those coordinates are in [0, 1] range, so multiply by viewport dimensions 
to get window coordinates.

  but i do not succeed doing it with osg because i m still not familiar 
with it...
  My current code is 

 osg::Camera * cam = _view->getCamera();
 osg::Matrix viewMatrix = cam->getViewMatrix();
 osg::Matrix projectionMatrix = cam->getProjectionMatrix();
 osg::Matrix windowMatrix = cam->getViewport()->computeWindowMatrix();

 osg::Vec4d screenCoords = windowMatrix.postMult 
(projectionMatrix.postMult (viewMatrix.postMult (_refPoint)));

  I saw windowMatrix is the bias matrix and the viewport scale.
  refPoint is a Vec4d with w = 1. ( the 3D point i want to project into 
screen space )  and as operator * is not defined to multiply a Matrix with an 
Vec4d, i use postMult function.

  But i dont get a valid result... what did i missed ? :-x
  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






--


  ___
  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] GL_SCISSOR_TEST error

[Wojciech Lewandowski]

Hi Brad,

Does it happen in state.applyMode( GL_SCISSOR_TEST ) call inside 
RenderStage::drawImplementation method ? I saw such errors when RenderStage 
buffer  (FBO/PBuffer) initialization went wrong. It just happens that 
GL_SCISSOR_TEST is first mode that is applied after RenderStage buffer 
intialization and apparently error during the buffer initalization may be 
mistakenly interpreted as glScissor issue when scissor is applied and tests 
glError. In fact, if RenderBuffer was not applied correctly it may be the case 
where passed scissor area rectangle may not match previously set RenderBuffer 
and will produce an error as well, but even then, it will be secondary issue to 
Render Buffer inititalization failure. 

I often use glIntercept to see what really happen in OpenGL under OSG wrapping. 
glIntercept does not work with multithreading but produces fairly well, 
informal logs when osgViewer is run in --SingleThreaded mode.

Cheers,
Wojtek

- Original Message - 
  From: Brad Huber 
  To: osg-users@lists.openscenegraph.org 
  Sent: Wednesday, September 09, 2009 10:27 PM
  Subject: [osg-users] GL_SCISSOR_TEST error


  Hello,

   

  I seem to be getting the error "Warning: detected OpenGL error 'invalid 
value' after applying GLMode" which has been mentioned in other threads.  After 
setting the OSG_GL_ERROR_CHECKING environment variable to ONCE_PER_ATTRIBUTE I 
get the more descriptive string "Warning: detected OpenGL error 'invalid value' 
after applying GLMode 0xc11"

   

  This code corresponds to GL_SCISSOR_TEST mode.  When this warning is printed 
I traced up the call stack to see that it's from the call state.applyMode( 
GL_SCISSOR_TEST, true ); in osg::RenderStage::drawImplementation.

   

  My question is does anyone know why I would be getting this message with 
GL_SCISSOR_TEST?  This test is being run on an older machine with an Intel 815 
GM graphics chip.  Is it possible scissor isn't supported or something?

   

  PS I'm using rev 10555 of OSG from the trunk

   

  Thanks in advance,

   

  -Brad



--


  ___
  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] GL_SCISSOR_TEST error

[Wojciech Lewandowski]

Hi Brad,

Both names are OK. Wojtek is for friends. Wojciech is what I have in my id. 
As far as I remember OpenGL does not change error flag until its read thorugh 
glError. So its very probable that the error was set by an OpenGL function that 
was invoked few calls before glScissor. glIntrcept should show which call was 
really responsible for the error.

Cheers,
Wojtek


From: Brad Huber 
Sent: Thursday, September 10, 2009 7:19 PM
To: 'OpenSceneGraph Users' 
Subject: Re: [osg-users] GL_SCISSOR_TEST error


EDIT - Wojciech, not sure where I got Wojtek from.  Sorry about that. 

 

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Brad Huber
Sent: Thursday, September 10, 2009 10:52 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] GL_SCISSOR_TEST error

 

Wojtek,

 

Thanks.  Yes I think this is along the lines of what I'm seeing.  It is the 
glScissor within RenderStage::drawImplementation.  I am not using osg::Scissor 
or any sort of Stencil buffering.

 

According to the Man page: 
http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/scissor.html
 invalid value happens when either width or height is negative.  I turned on 
the debug print in RenderStage::drawImplementation and I get the following:

 

clearing 0B0C7DC8  0,0,800,600

clearing 0B0FC118  0,0,800,600

clearing 0BFE0290  0,0,800,600

clearing 0B110638  0,0,260,180

Warning: detected OpenGL error 'invalid value' after applying GLMode 0xc11



 

So apparently the scissor fails when setting the width and height to 260 and 
180 (which obviously aren't negative).  Though those dimensions tell me that 
the failure happens for my Render to Texture (RTT) pass.

 

I'm not quite sure what you mean by the FBO/PBuffer being initialized wrong.  
I'll have a look at that and also try glIntercept.

 

PS The exact same code works on one machine but not on another OLD machine.

 

Thanks!

 

-Brad

 

From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wojciech 
Lewandowski
Sent: Thursday, September 10, 2009 3:06 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] GL_SCISSOR_TEST error

 

Hi Brad,

 

Does it happen in state.applyMode( GL_SCISSOR_TEST ) call inside 
RenderStage::drawImplementation method ? I saw such errors when RenderStage 
buffer  (FBO/PBuffer) initialization went wrong. It just happens that 
GL_SCISSOR_TEST is first mode that is applied after RenderStage buffer 
intialization and apparently error during the buffer initalization may be 
mistakenly interpreted as glScissor issue when scissor is applied and tests 
glError. In fact, if RenderBuffer was not applied correctly it may be the case 
where passed scissor area rectangle may not match previously set RenderBuffer 
and will produce an error as well, but even then, it will be secondary issue to 
Render Buffer inititalization failure. 

 

I often use glIntercept to see what really happen in OpenGL under OSG wrapping. 
glIntercept does not work with multithreading but produces fairly well, 
informal logs when osgViewer is run in --SingleThreaded mode.

 

Cheers,

Wojtek

 

- Original Message - 

  From: Brad Huber 

  To: osg-users@lists.openscenegraph.org 

  Sent: Wednesday, September 09, 2009 10:27 PM

  Subject: [osg-users] GL_SCISSOR_TEST error

   

  Hello,

   

  I seem to be getting the error "Warning: detected OpenGL error 'invalid 
value' after applying GLMode" which has been mentioned in other threads.  After 
setting the OSG_GL_ERROR_CHECKING environment variable to ONCE_PER_ATTRIBUTE I 
get the more descriptive string "Warning: detected OpenGL error 'invalid value' 
after applying GLMode 0xc11"

   

  This code corresponds to GL_SCISSOR_TEST mode.  When this warning is printed 
I traced up the call stack to see that it's from the call state.applyMode( 
GL_SCISSOR_TEST, true ); in osg::RenderStage::drawImplementation.

   

  My question is does anyone know why I would be getting this message with 
GL_SCISSOR_TEST?  This test is being run on an older machine with an Intel 815 
GM graphics chip.  Is it possible scissor isn't supported or something?

   

  PS I'm using rev 10555 of OSG from the trunk

   

  Thanks in advance,

   

  -Brad


--

  ___
  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] NULL Options passed to readImageFile()

[Wojciech Lewandowski]

Hi Joe,

If I correctly assume that you tried to run Debug from VS 2005 environment 
then it must be pre SP1 VS 2005. Install Service Pack 1 for VS 2005 and you 
should be fine.
Or... if you have VC SP1, this might be the recent "Microsoft VC 2005 Redist 
with ATL fixes" update issue.  Microsoft has recently made an update to VC 
redistributables which breaks existing programs. There were many reports 
everywhere. If this is the case google for "Microsoft Visual C++ 2005 
Service Pack 1 Redistributable Package ATL Security Update". ( I do not 
provide link to microsoft site because it usually expires faster then I 
click send)


Cheers,
Wojtek

--
From: "Joe Abreu" 
Sent: Thursday, September 10, 2009 10:27 PM
To: 
Subject: Re: [osg-users] NULL Options passed to readImageFile()

I have realised that it works fine if i select release build in VS 2005. 
So I guess my problem technically must lie in the fact that I cannot get 
the debug binaries to work:


openscenegraph-all-2.8.0-win32-x86-vc80sp1-Debug.tar.gz

I uncompressed these in exactly the same way that I have the release 
binaries. But when running any of the debug executables I get an error:



C:\OpenSceneGraph\bin\osg2cppd.exe

This application has failed to start because the application configuration 
is incorrect...


My first inclination is that the dependant .dll's are not found. But the 
debug versions of all dependancies are in the same location as the release 
versions. So I do not know why the release versions work but the debug 
ones do not.


Does anyone have any idea why I cannot get the debug versions to work.

I used this tutorial to attempt to install OSG:

http://dwightdesign.com/2009/05/installing-openscenegraph-280/

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





___
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