Re: [osg-users] Problem with multi monitor with NVIDIA card

[Wojciech Lewandowski]

Hi,

Thats the problem I described yesterday as "complete garbage" in my NVIDIA / 
Windows / multi monitor / mulit threaded post. Will not appear in single 
screen mode or single threaded. Run examples with --SingleThreaded option to 
test it. All recent 169.xx and 174.47 show the same issue.

Cheers,
Wojtek


- Original Message - 
From: "Björn Blissing" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, April 03, 2008 1:12 PM
Subject: [osg-users] Problem with multi monitor with NVIDIA card


I recently got the SVN release of OSG 2.3.7. When I compile and run the 
examples in single monitor mode they all work fine. But when I go to multi 
monitor mode some of them look really wierd. I have attached a picture of 
how this artifact looks like (In this case the osgKeyboardMouse example, but 
all looks pretty much the same).

I run these examples on a Windows XP computer with a Inter Core 2 Duo CPU 
and 4GB ram and a NVIDIA GeForce 8800 GTX card running forceware 169.21 
drivers. I have tried to change the multi monitor GPU acceleration setting 
to compability mode without any success (although it works if I set this to 
SingleScreenPerformance mode but then I only get the image on one of my 
screens).

Is this a known NVIDIA error? Are there any known workarounds?

Examples tested in multi monitor configuration (all work in single monitor 
configuration):
osgAnimate - Wierd
osgAutoTransform - OK
osgBillboard - Ok
osgBlendEquation - Wierd
osgCallback - Wierd
osgClip - Wierd
osgCubeMap - Wierd
osgDelaunay - Ok
osgDepthPartition - Ok
osgDistortion - Ok
osgFadeText - Ok
osgForest - Wierd
osgFxBrowser - Ok
osgGeometry - Wierd
osgGeometryShaders - Ok
osgHangglide - Wierd
osgHud - Wierd
osgKeyboard - Ok
osgKeyboardMouse - Wierd
osgLight - Wierd

/Björn
 <>







> ___
> 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] Windows / NVidia / multi monitor / muti threading (/FBO) problems

[Wojciech Lewandowski]

Hi Paul,

There is well known timing issue with AMD CPUs. Have you seen this document:
http://developer.amd.com/assets/TSC_Dual-Core_Utility.pdf

Btw I have these AMD timing patches installed. But also tried to run without
them. They don't affect the issues I descried earlier. Frankly, I do not
really care about timing precision. My concern is the fact that application
crashes or freezes and I cannot use FBO with multi monitor and multi
threaded modes. All the CPUs these days are multicore so this is a big
issue. Sure I can force SingleThreading but it would mean loosing power of
aditional cores.

Cheers,
Wojtek


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Paul Speed
Sent: Wednesday, April 02, 2008 6:54 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Windows / NVidia / multi monitor / muti threading
(/FBO) problems


One thing... have you tried with a fresh reboot or had the machine been
running for a while?

The reason I ask is because I see odd timing behavior on my Athlon 64 X2
(also running XP).  The clearest example of the oddity is querying the
high resolution timers.  Occasionally the value jumps around... but only
after the machine has been running a while.  This really messes with
some of the timing/profiling stuff in one of our applications and
sometimes causes some odd system stability when running timing sensitive
applications (music recorders, etc.)

The working theory (and I have not been able to prove it) is that each
core has its own time but that they get out of sync.  So if a thread
switches cores the high res timers go crazy.

It's not just my apps that show this either.  CPU monitors, etc. all
exhibit this problem.  The monitoring application that came with my
motherboard even shows the CPU speed jumping around on occasion.

But only after running for a while.  Note: I haven't tried bios
refreshes or anything like that.  I have no idea if there is a fix for
this issue but thought it might be something to check before condemning
nVidia, etc..

I like AMD a lot but my dual core intel does not have this problem.
-Paul

Wojciech Lewandowski wrote:
> Hi All,
>
> Few threads touched the same subject recently so I decided to share
> my observations and maybe provoke some discussion on the problem. Maybe
> together we can get it fixed. I said "got it fixed" because I am afraid
> that it might be difficult without driver changes.
>
> Problems are related to OSG on Windows XP & Vista with fairly recent
> NVidia boards (6x00-9x00) / dual view / multi threading modes. I don't
> want to discuss single monitor (or horizontal span) issues in this post.
>
> In my testing I went through following GeForce driver versions: 94.24,
> 97.94, 162.65, 169.21, 163.75, 169.28, 169.44, 169.61, 174.74.
> Tests done in DUAL VIEW /  MULTITHREADING modes. Athlon62  X2 (DUAL
> CORE). OSG latest SVN  from last 2 weeks (2.3.x).
>
> OBSERVED ISSUES:
>
> All pre 169.xx drivers:
> - Statistics does not show GPU stats. Draw timings are growing till the
> moment when framerate hz start to drop. This issue is present with
> number of examples. Use osgviewer dumptruck.osg to reproduce it.
>
> 169.xx and 174.74 drivers:
> - GPU stats seem ok. But osgviewer dumptruck.osg shows complete garbage.
> Things get better when osgviewer is started  with --SingleThreaded
> option and Threading modes are later changed with Threading handler.
>
> All driver versions:
> - FBO use problems. Number of examples using RTT cameras (prerender,
> shadow, simulation) show erratic behaviour. Usually one screen is
> incorrect, sometimes apllication freezes. Output console prints FBO
> error messages. FBO apply fails on one screen. Whats interesting both
> screens are correctly drawn for the first frame, error appears in
> consecutive frames.
>
> - FBO problems are also present in SINGLE monitor mutithreaded
> configurations. Examples usually start correctly but freeze or FBO
> textures stop to update when Threading handler changes mode. One
> exception: I noticed that oldest (94.24) drivers tested here are working
> correctly in single monitor mode (no matter what threading mode is
> selected). They are so old that they may be single threaded
> internally. Unfortunately they do show the same erratic behaviour as the
> other versions in multi monitor mode.
>
> All above problems dissapear when examples are run with --SingleThreaded
> option. Most of the problems also dissapear when run with One monitor.
> There are exceptions but they seem to vary with driver versions.
>
> SOLUTIONS (or rather lack of them):
>
> Driver Release Notes, number of posts on the WEB, posts on the OSG forum
> suggest that many OpenGL problems might be related to
> multithreaded usage. There is a number of CPU fixes available on the

[osg-users] Windows / NVidia / multi monitor / muti threading (/FBO) problems

[Wojciech Lewandowski]

Hi All, 

Few threads touched the same subject recently so I decided to share my 
observations and maybe provoke some discussion on the problem. Maybe together 
we can get it fixed. I said "got it fixed" because I am afraid that it might be 
difficult without driver changes.

Problems are related to OSG on Windows XP & Vista with fairly recent NVidia 
boards (6x00-9x00) / dual view / multi threading modes. I don't want to discuss 
single monitor (or horizontal span) issues in this post. 

In my testing I went through following GeForce driver versions: 94.24, 97.94, 
162.65, 169.21, 163.75, 169.28, 169.44, 169.61, 174.74. 
Tests done in DUAL VIEW /  MULTITHREADING modes. Athlon62  X2 (DUAL CORE). OSG 
latest SVN  from last 2 weeks (2.3.x). 

OBSERVED ISSUES:

All pre 169.xx drivers:
- Statistics does not show GPU stats. Draw timings are growing till the moment 
when framerate hz start to drop. This issue is present with number of examples. 
Use osgviewer dumptruck.osg to reproduce it.

169.xx and 174.74 drivers:
- GPU stats seem ok. But osgviewer dumptruck.osg shows complete garbage. Things 
get better when osgviewer is started  with --SingleThreaded option and 
Threading modes are later changed with Threading handler. 

All driver versions:
- FBO use problems. Number of examples using RTT cameras (prerender, shadow, 
simulation) show erratic behaviour. Usually one screen is incorrect, sometimes 
apllication freezes. Output console prints FBO error messages. FBO apply fails 
on one screen. Whats interesting both screens are correctly drawn for the first 
frame, error appears in consecutive frames.

- FBO problems are also present in SINGLE monitor mutithreaded configurations. 
Examples usually start correctly but freeze or FBO textures stop to update when 
Threading handler changes mode. One exception: I noticed that oldest (94.24) 
drivers tested here are working correctly in single monitor mode (no matter 
what threading mode is selected). They are so old that they may be single 
threaded internally. Unfortunately they do show the same erratic behaviour as 
the other versions in multi monitor mode.

All above problems dissapear when examples are run with --SingleThreaded 
option. Most of the problems also dissapear when run with One monitor. There 
are exceptions but they seem to vary with driver versions. 

SOLUTIONS (or rather lack of them):

Driver Release Notes, number of posts on the WEB, posts on the OSG forum 
suggest that many OpenGL problems might be related to multithreaded usage. 
There is a number of CPU fixes available on the net. Some from microsoft, some 
from AMD or Intel. NVidia recommends registry tweaks or turning off the 
Threaded optimization. I tried all them without success. 

Only one method did change the situation. When I disabled second core on the 
CPU, allmost all above problems vanished. In other words I could use 
MULTIMONITOR and MULTITHREADED OSG on one core CPU. In my opinion this is the 
strongest argument for the claim that there are NVidia driver isuses with 
mutithreaded OpenGL. The only case where FBO was still freezing on single core 
machine was when Threading mode was changed to 
CullThreadPerCameraDrawThreadPerContext. 

Unfortunatelly, disabling all the cores except one is no solution at all. I 
guess its better to run --SingleThreaded. I am curious what are the others' 
observations ? Maybe someone found some real solutions ? Maybe some workarounds 
could be made in OSG ?

DISCLAIMERS:

- I made all my testing on NVidia boards and have no idea how ATI boards would 
behave in similar scenarios. 

- Most of the tests were done on Windows XP SP2 / Athlon 64 X2 / NVidia GeForce 
7800 GTX. In a number of cases I changed graphics board to 8800 GTS or tested 
on my collegues Vista 64 bit Athlon Quad core or  Intel Core 2 Duo with 8800 
GTS. In none of this cases I have  noticed that switch to other archtiecture 
would change observed issues that I had with my primary configuration. Thats 
why I claim that problems are wider and repeatable but your results may still 
vary.

- Attempts to change "Threaded optimization" or "Multi-display/mixed-GPU 
acceleration" in NVidia Control Panel either didn't help or made it worse 
(instant freeze or no display). So I generally keept them at defaults: ie  
Multiple display performance mode and Threaded optimization set to Auto. 


Thanks for the  attention, 
Do you have similar or different observations ? Hopefully solutions ?

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

Re: [osg-users] Threading Problem after transfering application fromosg 2.0 to osg 2.2

[Wojciech Lewandowski]

Hi Tobias,

What graphics board and what driver revision ?

Do you know what threading model you have selected ? If its standard osg viewer 
try running with --SingleThreaded option and see if it helps.

I was investigating some Windows / NVidia / multi-monitor / multi-threading 
problems recently and observations are rather sad. I was unable to get it to 
work without either setting OSG to SingleThreading, switching off one monitor 
or turning off one core on the CPU. So it looks like mutimonitor/multithreading 
issues in the OpenGL drivers.

Do you still have OSG 2.0 can you check what mutlithreading option is selected 
? If its not SingleThreaded then it might be interesting because it may mean 
that some changes in OSG trigger these probles somehow.

Cheers,
Wojtek



  - Original Message - 
  From: Tobias Münch 
  To: OpenSceneGraph Users 
  Sent: Wednesday, April 02, 2008 12:36 PM
  Subject: [osg-users] Threading Problem after transfering application fromosg 
2.0 to osg 2.2


  Hello at all osg-users

  I have an application with two graphical output windows which are running 
each in an own thread. Using OSG 2.0 there isnt any problem. Using OSG 2.2 to 
compile the project, the second output window suffers from enormous performance 
loss and produces only small framerates (>1fps). When I minimize the first 
window, the second window runs with full performance. I think it is a 
thread-management-problem in windows XP (SP2) based on specific settings in OSG 
2.2.

  Does anybody know a solution?
  Thanks, 
  Tobias



--


  ___
  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] Multiple Render Targets - Request forComments/Testing

[Wojciech Lewandowski]

I tried to compile it and link on Windows with latest SVN. Compiled and 
linked fine.I ran osg prerender and shadow exmples with fbo. Again no 
problems. But frankly haven't tested MRT functionality at all.

Cheers,
Wojtek


- Original Message - 
From: "J.P. Delport" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, April 01, 2008 12:29 PM
Subject: Re: [osg-users] Multiple Render Targets - Request 
forComments/Testing


> Hi,
>
> is anyone looking at this, or should I assume no news is good news and
> just submit it as a patch?
>
> rgds
> jp
>
> J.P. Delport wrote:
>> Hi,
>>
>> over the weekend I have consolidated previous hacks to enable MRT into
>> what I hope would be an acceptable patch for OSG.
>>
>> I would like to have it tested a bit before sending it to submissions.
>>
>> Attached are the changes to OSG's Camera and RenderStage.
>>
>> Camera got a new method called setDrawBuffers (instead of the normal
>> setDrawBuffer), which mirrors the OpenGL extension glDrawBuffers.
>>
>> setDrawBuffers takes a vector of BufferComponents and this vector is
>> then translated in RenderStage to a vector of GLenums that is passed to
>> glDrawBuffers.
>>
>> The new calls are orthogonal to current use cases, so hopefully no other
>> code/examples would be affected.
>>
>> The attached example shows sample usage. The example is very contrived,
>> but I hope it explains the concept. I have some other examples that I
>> can contribute later.
>>
>> Please let fly with comments/observations.
>>
>> regards
>> jp
>>
>> PS. How do I add an example to OSG? The CMakelists in the examples
>> directory contains a list of directories, but when is the CMakelists in
>> a specific example directory created?
>>
>>
>> 
>>
>> ___
>> 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

Re: [osg-users] Performance drop & higherRAMusageafterswitchingfrom OSG 1.2 to latest SVN

[Wojciech Lewandowski]

Ooops, I did not notice you have your own Viewer. Sorry for the noise.
Cheers,

Wojtek



- Original Message - 
From: "Marco Jez" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 31, 2008 5:45 PM
Subject: Re: [osg-users] Performance drop & higherRAMusageafterswitchingfrom 
OSG 1.2 to latest SVN


> Hi Wojtek,
>
>> Have you tested with --SingleThreaded option ? In my configuration
>> multithreaded configs usually eat more RAM. However its not twice as in
>> SingleThreaded.
>
> I'm using my own single-threaded viewer, so I don't even have to choose. 
> :-)
>
>> I have read somewhere that NVidia OpenGL dirver creates shadow threads 
>> for
>> each thread of  the application. Maybe these threads duplicate some
>> resources...
>
> This could be an hint *if* OSG (in particular, SceneView and anything
> controlled by it) were spawning threads behind the scene, but since I'm
> running a single GL context I don't think this is the case. Maybe Robert
> could add a word here.
>
> Marco
>
>
> ___
> 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] Performance drop & higher RAM usageafterswitchingfrom OSG 1.2 to latest SVN

[Wojciech Lewandowski]

Hi Marco,

Since I am currently struggling with Windows/ OSG & FBO / multi monitor / 
mutlti threaded problems here are my 2 cents:

Have you tested with --SingleThreaded option ? In my configuration 
multithreaded configs usually eat more RAM. However its not twice as in 
SingleThreaded.

I have read somewhere that NVidia OpenGL dirver creates shadow threads for 
each thread of  the application. Maybe these threads duplicate some 
resources...

Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Marco Jez" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 31, 2008 4:54 PM
Subject: Re: [osg-users] Performance drop & higher RAM 
usageafterswitchingfrom OSG 1.2 to latest SVN


> Hi Robert,
>
>> To avoid
>> threading problems apparent in 1.2 the OSG-2.x versions initialization
>> the GL objects arrays to a larger default, if you app isn't setting
>> the number of context down to the number you are using then perhaps
>> this is where the discrepancy is occurring.
>
> My viewer is already setting the maximum number of contexts to one, so
> that's not the case... I keep debugging.
>
> Cheers,
> Marco
>
>
> ___
> 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] TexGenNode vs Group with TexGen attribute

[Wojciech Lewandowski]

Hi Robert and Mathias,

Thanks for the anwers. Let me reassume, from my perspective, to make sure I 
understood correctly what the problems are.

1. There is no use in TexGen as a texture state attribute with EYE_LINEAR, 
because no one knows with what modelview matrix it will be applied.

2. For EYE_LINEAR one have to use TexGenNode. But its then global for whole 
render stage and may conflict with other TexGenNodes and TexGens as 
attributes if they use the same stage ...

Is this correct ?

Mathias, thanks for suggestions on solutions, I don't have much time for 
such elaborate work now. I have a conflict on 0 stage texture coords, but 
fortunatelly I can switch to other stages. So I will probably leave stage 0 
alone and will use other stage with global TexGenNode.

Thanks,
Wojtek


- Original Message - 
From: "Mathias Fröhlich" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Thursday, March 27, 2008 1:14 PM
Subject: Re: [osg-users] TexGenNode vs Group with TexGen attribute



Hi,

On Thursday 27 March 2008 12:00, Wojciech Lewandowski wrote:
> I think I understand these nuances when it refers to TexGenNode. But what
> bothers me is a question what modelview matrix  is used while applying
> TexGen to OpenGL when I use TexGen as an attribute ? Is this the modelview
> that CullVisitor accumulated when processing the group with texgen state
> attribute ? Or is it a "random" modelview which is current when render
> stage aplies texgen attribute before rendering renderleafs using this
> stateset ?
You cannot rely on a specific modelview matrix to be applied when these
attributes are applied.

What you can do is to fiddle with draw callbacks in render stages and
additional render stages that you introduce in the cull callback to make 
that
work with the current code.
I do so with flightgear and clip planes.
That does not work in every case and raises the need to habe a well defined
render bin hierarchy around that nodes, but it works well enough.
See SGClipGroup in SimGear (www.simgear.org) ...

> I wish to use TexGen as attribute because TexGenNode behaviour seems
> globally superfluous. Tex coords are generated for children as well as
> sibling subgraphs of  TexGenNode (I am not sure what about ancestors). I
> would rather want to limit tex coord generation to children subgraphs. But
> I can't sort out how to modify texgen matrix to produce exactly the same
> coords as TexGenNode used to...
Yep, I would like to do so too.

And I would like to do so without the need to introduce a new render stage 
for
that.

> Few more questions: what happens if I set two or more TexGenNodes on the
> same stage somewhere in the graph. Is it allowed ? What will be their 
> scope
> ? And what happens if there is TexGenNode and some other node with TexGen
> attribute on the stateset ?
Well you can, but the behaviour ist undefined I believe :).
It depends on which TexGen Node you enter last when you do the cull 
traversal.
It depends how much stateset chareing you do, that is it is affected of the
state grap that is built in the rendering backend and so on ...

I was thinking about solutions to that problem several times now. But I did
not see something really valuable up to now ...

GReetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196


___
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] TexGenNode vs Group with TexGen attribute

[Wojciech Lewandowski]

Hi Robert,

I think I understand these nuances when it refers to TexGenNode. But what 
bothers me is a question what modelview matrix  is used while applying 
TexGen to OpenGL when I use TexGen as an attribute ? Is this the modelview 
that CullVisitor accumulated when processing the group with texgen state 
attribute ? Or is it a "random" modelview which is current when render stage 
aplies texgen attribute before rendering renderleafs using this stateset ?

I wish to use TexGen as attribute because TexGenNode behaviour seems 
globally superfluous. Tex coords are generated for children as well as 
sibling subgraphs of  TexGenNode (I am not sure what about ancestors). I 
would rather want to limit tex coord generation to children subgraphs. But I 
can't sort out how to modify texgen matrix to produce exactly the same 
coords as TexGenNode used to...

Few more questions: what happens if I set two or more TexGenNodes on the 
same stage somewhere in the graph. Is it allowed ? What will be their scope 
? And what happens if there is TexGenNode and some other node with TexGen 
attribute on the stateset ?

We had the occasion to test this last case and observed some TexGen 
coordinate bleeding. We had TexGenNode in the graph root and one node with 
environment mapping texgen attribute positioned somewhere down the graph. 
For simplicity lets name this node a ENV_MAP_NODE.

I would expect that TexGenNode coords would be used for all the drawables 
except those that inherit TexGen attribute from ENV_MAP_NODE. But we saw 
that ENV_MAP_NODE TexGen attribute was overriding coord generation for nodes 
above in graph hierarchy whenever the ENV_MAP_NODE entered the frustum. 
Should this happen ?

Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Thursday, March 27, 2008 10:27 AM
Subject: Re: [osg-users] TexGenNode vs Group with TexGen attribute


> Hi Wojtek,
>
> You've come across the wacky world of position OpenGL state.  Normal
> OpenGL state like modes and textures etc are invarient of the current
> modelview matrix, not so for positional state these use the current
> modelview matrix to position themselves so its become crucial that you
> apply a specific modelview matrix before you apply the state otherwise
> it's position will vary widely according to what modelview matrices
> just so happens to be applied.
>
> Examples of positional state are glLight, glClipPlane and glTexGen
> EYE_LINEAR.  glTexGen OBJECT_LINEAR is not positional though so it
> doesn't matter when its applied - its just like ordinary OpenGL state.
> So how does the scene graph handle this positional state?  We have to
> anchor in space using a special node, osg::LightSource, osg::ClipLane
> and osg::TexGenNode all exist for this purpose.
>
> Robert.
>
> On Thu, Mar 27, 2008 at 9:16 AM, Wojciech Lewandowski
> <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hi,
>>
>> Whats the difference in coord generation (in practice) between TexGenNode
>> and Group with TexGen attribute. Suppose I have the same subgraph 
>> attached
>> to either such TexGenNode or such Group with TexGen. In both cases 
>> TexGens
>> are eye linear and use the same texture stage.
>>
>> I expected them to produce the same tex coords but results different. So 
>> I
>> am bit puzzled. What did I miss ?
>>
>> 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

[osg-users] TexGenNode vs Group with TexGen attribute

[Wojciech Lewandowski]

Hi,

Whats the difference in coord generation (in practice) between TexGenNode and 
Group with TexGen attribute. Suppose I have the same subgraph attached to 
either such TexGenNode or such Group with TexGen. In both cases TexGens are eye 
linear and use the same texture stage.

I expected them to produce the same tex coords but results different. So I am 
bit puzzled. What did I miss ?

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] Shadow Map and threading mode

[Wojciech Lewandowski]

J-S,

I have found few minutes to do the test again at work. Only thing I changed 
was the drivers. I went back to antique 94.24 version.

Test WORKS with these drivers.

Only case when it fails is when I run on two monitors. But two monitor 
issues are even worse than multithreading issues and here I am almost 99% 
sure, fault is in the drivers part. I don't event want to talk about all the 
problems with dual view I had in the past ;-)

Cheers,
Wojtek

- Original Message - 
From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Thursday, March 20, 2008 2:28 PM
Subject: Re: [osg-users] Shadow Map and threading mode


> Hello Wojtek,
>
>> I did the test at home. I have really crappy machine there. WinXP Athlon 
>> XP
>> 1700 and AGP GeForce 6200 (drivers ver 169.28). And guess what ? It works
>> ;-).
>
> Hmmm. I wonder if I went back to similar drivers here and tried it... I
> might try that early next week (I have a deadline to meet today, and
> tomorrow is off in Canada for Easter).
>
> Thanks for continuing your testing! I'm still not discounting the
> possibility that it's a combination of something to tweak in OSG *and*
> some driver weirdness that causes this, but at least we're getting some
> data about the problem (and I'm relieved to not be the only one seeing 
> it).
>
> J-S
> -- 
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>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] Shadow Map and threading mode

[Wojciech Lewandowski]

Hi J-S,

> That may be a problem because we're always in multiscreen mode here,
> both simulators and developers. On Windows XP we use horizontal span
> mode, but on Vista it doesn't exist anymore so we use DualView...

> It's a bit disturbing to see that the behaviour is so wildly different
> from one driver to another. I'd have thought that if games work (and all
> games have shadows nowadays) then we'd be able to make it work too, but
> I guess it might be up to better support for DirectX than for OpenGL in
> the drivers...

Plus normal user usually has one monitor :-(. It would be good If we could
get some NVidia support for OSG. Maybe we should try to write to their
developers forum but this is particularly difficult problem and my personal
experience with them isn't too encouraging. Some time ago I reported few
issues - got the reply only once. So I stopped trying. I am sure it would be
different if I was from Epic or ID software, though... I am curious what are
other users opinions. I guess some folks on this forum might had worked with
some of NVidia engineers in the past. Maybe they can do something about
this...

Cheers,
Wojtek

PS. Hey, I am ready to swallow my words and apologize if someone from NVIdia
is eager to help ;-)

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

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi J-S,

I bet that historically osgshadow had SingleThreading initialized for the 
reason Robert mentioned. But notice that it was also possible to change it 
by command arguments.

Then osgViewer got the argument parser and started to initilize threading 
model. But this functionality was being overwirtten by explicit 
SingleThreading setting left from earlier times.

And ThreadingHandler was developed later thats why it was not added to 
osgshadow example.

Sure, I might be wrong. Robert can tell us about passed development 
milestones or svn history could shed some light on this problem.. But I 
doubt that continuing this disucssion would be productive. Whatever was the 
flow of changes we both agree we should try to make it work with 
ThreadingHandler and other ThreadingModes.

Cheers,
Wojtek

- Original Message - 
From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Thursday, March 20, 2008 2:22 PM
Subject: Re: [osg-users] osgShadow example and gerneral question


> Hi Wojtek,
>
>> I believe that setting threading model to SingleThreaded was not 
>> deliberate
>> but was done as a default. Consecutive lines of code check arguments and
>> switch to other Threading modes accordingly.
>
> Well, it sets the threading model to SingleThreaded and does not add a
> ThreadingHandler... So once the example is started, you're stuck in the
> threading mode that was set (SingleThreaded by default) and cannot
> change it at runtime.
>
> I think that's the more telling element.
>
> IMHO, all examples should have the standard event handlers (Threading
> mode, stateset manipulator, stats, window size/fullscreen, etc.). Most
> do, but not all. (I can help with that soon) And if an example doesn't
> play well with an event handler, the problem should be fixed instead of
> just omitting the handler...
>
> J-S
> -- 
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>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] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi Robert,

 > In the early days of osgShadow it certainly wasn't thread safe.  This
> is why the SingleThreaded option is there.
>
> Now I haven't recently reviewed all the osgShadow implemententations
> too see if they are thread safe so can't confirm if we can safely do
> it yet.

If you admit it was not thread safe then - I guess the whole problem J-S 
reported does not make much sense. Does it ?

What about prerender example then ? Maybe we should talk about this one ? Is 
it  thread safe ? It behaves similarly after adding ThreadingHandler().

Cheers,
Wojtek

PS. I suggest we switch to thread J-S started "ShadowMap and threading mode" 
its more appropriate for this discussion. 

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

Re: [osg-users] Shadow Map and threading mode

[Wojciech Lewandowski]

Hi J-S,

I did the test at home. I have really crappy machine there. WinXP Athlon XP 
1700 and AGP GeForce 6200 (drivers ver 169.28). And guess what ? It works 
;-). Since its single core machine and agp it still does not bring us closer 
to answering the question whether OSG or Driver fails, but at least there is 
one case when it works ;-)

Since this machine is single core osgshadow starts with SingleThreaded mode. 
But I did aditional test - I forced it to start with 
CullDrawThreadPerContext. And in this case problem appears again. After 
pressing 'm' couple times shadow map freezes. So reasumming when is start in 
SingleThreaded mode it works. When it starts in CullDrawThreadPerContext it 
stops working. Interesting isn't it ? Had no more time to continue 
experiments maybe will do more on weekend.

It would be interesting if somebodey with single core machine and decent PCI 
express GeForce did the test...

Cheers,
Wojtek



- Original Message - 
From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, March 18, 2008 4:45 PM
Subject: Re: [osg-users] Shadow Map and threading mode


> Hi Wojtek,
>
>> I was on vactions. But if you are still interested I did the test you
>> wanted.
>
> Of course I am interested. :-) Thanks for testing. Seems like the more
> recent nVidia drivers give problems when switching threading modes, and
> older ones are OK. Unfortunately I am on Vista so using old drivers
> usually gives me other problems :-(
>
> Anyways, I think we'll chalk it down to a driver bug until more
> information is available. Thanks again for testing.
>
> J-S
> -- 
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>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] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi Raymond,

[..]

> Ok, I did not mean to test the recent changes explicitly, I just did the
> test that I did recently, since the issue is hot now. Please look at the
> attached modified osgshadow.cpp. It is good to notice that the svn
> osgshadow.cpp explicitly sets the threading model to SingleThreaded.

I believe that setting threading model to SingleThreaded was not deliberate 
but was done as a default. Consecutive lines of code check arguments and 
switch to other Threading modes accordingly.

However, this piece of shadow example become redundant when 
osgViewer::Viewer started to parse Threading arguments. And this section 
could be now removed from osgshadow example - I will send a proper 
submission.

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 example and gerneral question

[Wojciech Lewandowski]

Hi Robert,

>>  [..] And due to lack of other supects I agree with J-S: we
>>  should put the blame on NVidia drivers ;-(.
>
> The threading issue is clearly a different problem entirely.
>
> I haven't had the chance to go look into this topic so can't comment
> on whether its an OSG problem or a driver one.  With threading I'd
> generally be inclined towards looking at the OSG side first, then once
> everything is confirmed to be clean look towards the driver.

I did not mean to be dead serious about drivers fault. I have worked too 
long as a programmer to ignore the experience - from thousands of claims 
that some issue was a driver or compiler bug only few turned out to be true 
;-)

Btw I have new observations but will present them in the thread J-S started.

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 example and gerneral question

[Wojciech Lewandowski]

Hi Robert and Raymond,

I have tested latest changes (rev 7975). Inheritance problem that looked 
like invisible polygon casting shadow for half of the scene vanished. So 
far, so good ;-).

IMHO, the problem J-S noticed with ThreadingModeHandler is different. Its 
not related to inheritance mask changes and does not affect only Shadow 
example. It can be also seen with Prerender example with RTT camera using 
FBOs and PixelBuffers. And due to lack of other supects I agree with J-S: we 
should put the blame on NVidia drivers ;-(.

Wojtek

- Original Message - 
From: "Raymond de Vries" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Wednesday, March 19, 2008 3:08 PM
Subject: Re: [osg-users] osgShadow example and gerneral question


> btw ShadowTexture (command line arg --st) is not producing any shadows
> at all, for each threading model.
>
> Raymond
>
>
> Raymond de Vries wrote:
>> Hi,
>>
>> A quick test report: I just did a test on WinXP, using rev 7975 changing
>> the threading model as J-S suggested. Results are different for
>> different shadow techniques:
>> --sv: crash
>> --ssm: artifact
>> --sm: artifact
>> --pssm: artifact
>> --pssm -NVidia: artifact
>>
>> Artifact:  initially the rendering is ok but the artifacts still occur
>> when the threading model is changed, see the images in this message:
>> http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-March/008294.html
>>
>> This is tested on a multi core machine.
>>
>> Best regards
>> Raymond
>>
>>
>> Wojciech Lewandowski wrote:
>>
>>> Robert,
>>>
>>> I understand. As I earlier said,  I did not mean to push it. In fact I 
>>> have
>>> sent my post in just the same time I received your post that you already
>>> implented option #4. I would not do this if the timing was different ;-) 
>>> I
>>> am OK with your current solution.
>>>
>>> Cheers,
>>> Wojtek
>>>
>>> - Original Message - 
>>> From: "Robert Osfield" <[EMAIL PROTECTED]>
>>> To: "OpenSceneGraph Users" 
>>> Sent: Wednesday, March 19, 2008 2:20 PM
>>> Subject: Re: [osg-users] osgShadow example and gerneral question
>>>
>>>
>>>
>>>
>>>> Hi Wojteck,
>>>>
>>>> On Wed, Mar 19, 2008 at 11:20 AM, Wojciech Lewandowski
>>>> <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>>  So in practice there are 3 cases of usage and I think that they can 
>>>>> be
>>>>>  served with option #5:
>>>>>
>>>>>  setAttribute( ) would always clear inheritance flag.
>>>>>
>>>>>  but also add a method:
>>>>>
>>>>>  inheritAttribute( ) which would set the inheritance flag and reset
>>>>> attribute
>>>>>  to default.
>>>>>
>>>>>
>>>> Adding an inherit*() method would require us to add a number of extra
>>>> methods that most/perhaps all would never be called.  Also having
>>>> multiple places that set the default value would be a maintenance
>>>> problem.
>>>>
>>>> If there was a need for enabling inheritance then it'd be better done
>>>> via a general inerihitance setting method, but then we already have a
>>>> setInheritinceMask() method.
>>>>
>>>> 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 

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

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Robert,

I understand. As I earlier said,  I did not mean to push it. In fact I have 
sent my post in just the same time I received your post that you already 
implented option #4. I would not do this if the timing was different ;-) I 
am OK with your current solution.

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Wednesday, March 19, 2008 2:20 PM
Subject: Re: [osg-users] osgShadow example and gerneral question


> Hi Wojteck,
>
> On Wed, Mar 19, 2008 at 11:20 AM, Wojciech Lewandowski
> <[EMAIL PROTECTED]> wrote:
>>  So in practice there are 3 cases of usage and I think that they can be
>>  served with option #5:
>>
>>  setAttribute( ) would always clear inheritance flag.
>>
>>  but also add a method:
>>
>>  inheritAttribute( ) which would set the inheritance flag and reset 
>> attribute
>>  to default.
>
> Adding an inherit*() method would require us to add a number of extra
> methods that most/perhaps all would never be called.  Also having
> multiple places that set the default value would be a maintenance
> problem.
>
> If there was a need for enabling inheritance then it'd be better done
> via a general inerihitance setting method, but then we already have a
> setInheritinceMask() method.
>
> 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] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi, Robert

Fourth method looks good to me.


I have difficulties in imagining the situation when one calls 
setAttribute( SOME_NON_DEFAULT_VALUE ) and does not change inheritance mask. 
It does not make much sense to me, because not setting mask does effectively 
ignore the attribute.

On the other hand if someone wants to reset attribute:
 he may set it either with setAttribute( DEFAULT_VALUE ) to safeguard 
from inheritance override
or
simply activating inheritance mask bit allowing inheritance override.

So in practice there are 3 cases of usage and I think that they can be 
served with option #5:

setAttribute( ) would always clear inheritance flag.

but also add a method:

inheritAttribute( ) which would set the inheritance flag and reset attribute 
to default.

But it is just a thought, I don't want to complicate things more : option #4 
works for me ;-)

Wojtek


- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Wednesday, March 19, 2008 10:55 AM
Subject: Re: [osg-users] osgShadow example and gerneral question


> Hi Mark, Wojtek et. al,
>
> On Wed, Mar 19, 2008 at 1:17 AM, Mark Sciabica <[EMAIL PROTECTED]> 
> wrote:
>> I think #3 is a good option, but I would like to suggest using an
>>  interface similar to that used for state attributes. I.e. use an
>>  enumeration for the possible values instead of a bool, even if only
>>  two values are needed initially. Having a more uniform interface for
>>  handling inheritance in the scene graph will lessen the learning
>>  curve.
>
> I have also been thinking about option #3 an use a enum.  And also
> been thinking about another option related to option #3.  A glimpse of
> the enum:
>
>enum InheritanceMaskActionOnAttributeSetting
>{
>DISABLE_ASSOCIATED_INHERITANCE_MASK_BIT,
>DO_NOT_MODIFY_INHERITANCE_MASK
>};
>
> And the set methods would be like:
>void setImpostorsActive(bool active,
> InheritanceMaskActionOnAttributeSetting
> action=DISABLE_ASSOCICATED_INHERITANCE_MASK_BIT);
>
> I take I'm not the only one that finds this a little too much of a
> mouthful, and kinda obscures the important bit - the set method name
> and its primary parameter.  One could go for a simpler enum name, but
> in the end the bool is far less intrusive.
>
> The other approach is to do modify the setAttribute() signature, but
> instead have a separate method so setting the action i.e
>
>  void 
> setInheritanceMaskActionOnAttributeSetting(InheritanceMaskActionOnAttributeSetting
> action);
>  InheritanceMaskActionOnAttributeSetting
> getInheritanceMaskActionOnAttributeSetting() const;
>
> Then in the set methods we'd have:
>
>   void setImpostorsActive(bool active)
>  {
>   _impostorActive = active;
>   if 
> (_inheritanceMaskActionOnAttributeSetting==DISABLE_ASSOCICATED_INHERITANCE_MASK_BIT)
>   {
>_inheritanceMask = _inheritanceMask & (~IMPOSTOR_ACTIVE);
>   }
>   }
>
> We'd let _inheritanceMaskActionOnAttributeSetting default to
> DISABLE_ASSOCICATED_INHERITANCE_MASK_BIT.
>
> This forth approach is currently my favoured as its least intrusive
> w.r.t setAttribute() method parameters, but... I'm not overly happy
> with the behind the scenes automatic setting of other parameters.
> Doxygen comments can come in to solve this one though.
>
> Thoughts?
>
> 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] osgShadow example and gerneral question

[Wojciech Lewandowski]

Thanks for the changes,

W.r.t. question you asked earlier I would vote for option #3. Ie:

CullSettings::setComputeNearFarMode( mode, bool disableInheritance=true);
CullSettings::setCullMask( mode, bool disableInheritance=true);
et cetera.

I remember I had once a problem with not working setCullMask. It turned out
I changed setCullMask but it was ignored because inheritance mask was not
set properly. Option #3 would make a life easier in such cases. So I think
that solution where cull settings variable setters modify appropriate
inheritance flags is actually quite reasonable from usage perspective.

If you want to make inheritance masks modification more explicit for users
just add second bool parameter without default initialization - this will
force compiler error for users code and will annoy some of them but
certainly will make community aware of the shift in inheritance policy ;-).

On a side note: it would be good to ask this question again in separate post
with more appropriate subject. I suppose lots of interested users who don't
read every forum email might have skipped it.

Cheers,
Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert
Osfield
Sent: Tuesday, March 18, 2008 7:29 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgShadow example and gerneral question


A little update.  To get osgShadow back working again I've applied a
tempory fix to ShadowMap, ParallelSplitShadowMap and SoftShadowMap
such that the setCullInheritance(0x0) is used.   Applying this same
change to ShadowTexture broke it so I've commented this change out.
These changes are now checked in.

I don't think these changes are perfect, and they don't solve the
other places in the OSG or in user code that might not have the
InheritanceMask set appropriately.  My current inclination is to
change CullSettings so that it when you set variables the associated
mask bit is disabled, this behaviour is something that would have to
be optional, even it were on by default.  My guess is that would give
us as close to the original behavior without breaking the rules of
inheritince.

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] osgShadow example and gerneral question

[Wojciech Lewandowski]

> I'm just tying up some other work, once this is done I'll do a quick
> review of Camera usage.

Thanks for explanations, I no longer disturb. Let me know if I could help.

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, March 18, 2008 3:37 PM
Subject: Re: [osg-users] osgShadow example and gerneral question


> On Tue, Mar 18, 2008 at 2:18 PM, Wojciech Lewandowski
> <[EMAIL PROTECTED]> wrote:
>>  > Items like back ground colour is certainly something that can be
>>  > useful to inherit, but... perhaps if the coder wants this then its
>>  > fair enough to actually require them to set it.  Clearly wel need to
>>  > have a good think about inheritance of settings in viewer and scene
>>  > graph Cameras, and SceneView which also uses CullSettings behind the
>>  > scenes in osgViewer.
>>
>>  If I understand correctly you opt for default NULL inheritance mask. 
>> Right ?
>>  I agree that this should solve this particular issue. Don't know how 
>> this
>>  would affect other cull settings, though.
>
> Other effects is what we need to be careful about and why making top
> level changes right now is probably a bit too quick.
>
> Without looking into further my guess is that SceneView needs to
> inherit all CullSettings, slave Cameras should inherit their
> CullSettings, but scene graph Cameras might be better off not
> inheriting settings.
>
> Or perhaps we always inherit unless one sets a variable locally - this
> would require an approach like in your extra parameter suggestion.
>
>> > Right now I think the thing to do is apply the fix to osgShadow, then
>>  > move on to a wider review of inheritance of CullSettings.
>>
>>  I think I understand your motives. Do you want me to add this second 
>> line
>>  and send a fix for osgShadow::ShadowMap ? I may try to update PSSM and 
>> SSM
>>  as well but I won't guarantee I will be able to fully test them.
>
> It may even be worth doing a setInheritanceMask(0x0) on all these
> osgShadow implements.  The right of the Camera usages needs look at as
> well.
>
> I'm just tying up some other work, once this is done I'll do a quick
> review of Camera usage.
>
> 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] Shadow Map and threading mode

[Wojciech Lewandowski]

Hi J-S,

I was on vactions. But if you are still interested I did the test you
wanted. I have added ThreadingHandler to shadow example. Pressing m does not
crash the program but freezes shadow map. Shadow map is no longer refreshed.
I did the same quick test with prerender example and results are similar. So
 the issue is wider and might be related to RTT camera usage. I also did
 prerender test with -fb (render to frame buffer switch) and everyting 
worked
 correctly.

 My machine is Athlon 64 X2, GeForce 7800 GTX, Windows XP (drivers ver
 169.44). Tested on Single Monitor and Dual Monitor with all possible
 multithreading optimization choices from NVidia control panel. None of the
 NVidia options seemed to fix the results.

 Cheers,
 Wojtek


> - Original Message - 
> From: "Jean-Sébastien Guay" 
> <[EMAIL PROTECTED]>
> Newsgroups: gmane.comp.graphics.openscenegraph.user
> To: "OpenSceneGraph Users" 
> <[EMAIL PROTECTED]>
> Sent: Monday, March 10, 2008 7:35 PM
> Subject: Re: Shadow Map and threading mode
>
>
>> Hi all,
>>
>> So since no one has replied, I gather no one else has had any problems
>> changing the threading mode when shadows are enabled (for example, in
>> the osgshadow example)?
>>
>> J-S
>>
>>
>>> Hello,
>>>
>>> I was wondering if there were any known problems related to using
>>> osgShadow::ShadowMap and changing the threading mode.
>>>
>>> In the osgshadow example (SVN), if I change the threading mode (I added
>>> a threading handler to it) my graphics driver crashes.
>>>
>>> In our own software based on OSG 2.2 and using a CompositeViewer, on
>>> some machines the problem is more interesting (after a fashion): when
>>> the threading mode is changed, the shadow stops moving with the mobile
>>> object which causes it (i.e. it stays where it was when the threading
>>> mode changed, apparently not updating anymore).
>>>
>>> On my own machine it just crashes as well, like the SVN version, but on
>>> others that's what happens. I haven't double-checked on those machines
>>> what happens with the osgshadow example though.
>>>
>>> So, I just want to know if I should expect it to work or if that's
>>> something that's expected not to work for now.
>>>
>>> This is on Windows (XP / Vista), nVidia 7900 and 8800 cards.
>>>
>>> Thanks,
>>>
>>> J-S
>>
>>
>> -- 
>> __
>> Jean-Sebastien Guay 
>> [EMAIL PROTECTED]
>>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

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi Robert,

>>  In other words from now when we want a fixed projection matrix we need 
>> to
>>  make two calls:
>>
>>  camera->setComputeNearFarMode( osg::Camera::DO_NOT_COMPUTE_NEAR_FAR );
>>
>> camera->setInheritanceMask( camera->getInheritanceMask() &
>>  ~osg::Camera::COMPUTE_NEAR_FAR_MODE );

> If we don't change the default setting then this is true.

> This is a general problem with inheritance of properties, if we set
> the value then it would imply that its important that we retain this
> value and to not inherit it, this in turn would suggest that we should
> have the inheritance mask set off by default.

> Items like back ground colour is certainly something that can be
> useful to inherit, but... perhaps if the coder wants this then its
> fair enough to actually require them to set it.  Clearly wel need to
> have a good think about inheritance of settings in viewer and scene
> graph Cameras, and SceneView which also uses CullSettings behind the
> scenes in osgViewer.

If I understand correctly you opt for default NULL inheritance mask. Right ? 
I agree that this should solve this particular issue. Don't know how this 
would affect other cull settings, though.

[...]
> I'm open to this approach, but having the two decoupled is cleaner
> interface wise.
[...]
> Right now I think the thing to do is apply the fix to osgShadow, then
> move on to a wider review of inheritance of CullSettings.

I think I understand your motives. Do you want me to add this second line 
and send a fix for osgShadow::ShadowMap ? I may try to update PSSM and SSM 
as well but I won't guarantee I will be able to fully test them.

Cheers,
Wojtek

PS. For the reference I attached a list of remaining files from search for 
"setComputeNearFarMode" below (removed PSSM, SSM, SM .and files with 
commented setComputeNearFarMode cases). They may require similar tweaks 
before you change default inheritance mask.

OpenSceneGraph\src\osgSim\OverlayNode.cpp(973):
overlayData._camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

OpenSceneGraph\examples\osgdepthpartition\DepthPartitionNode.cpp(219):
camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

OpenSceneGraph\examples\osgdepthpeeling\osgdepthpeeling.cpp(247):
viewer.getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

OpenSceneGraph\examples\osgfadetext\osgfadetext.cpp(129):
viewer.getCamera()->setComputeNearFarMode(osg::CullSettings::COMPUTE_NEAR_FAR_USING_PRIMITIVES);

OpenSceneGraph\examples\osgsimulation\osgsimulation.cpp(224):
viewer.getCamera()->setComputeNearFarMode(osg::CullSettings::COMPUTE_NEAR_FAR_USING_PRIMITIVES);

OpenSceneGraph\examples\osgslice\osgslice.cpp(162):
sceneView->setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR);
 

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

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi Robert,

>Since I think the actual rules of inheritance of settings are correct,
>and things worked before because of bug in the inheritance of
>settings, so its a matter of either changing the defaults in
>CullSettings so that less of the inherited state comes down into the
>local Camera, or we override the defaults locally.  I'd suggest we
>change the defaults locally and review the defaults in light of how
>many changes we make.

In other words from now when we want a fixed projection matrix we need to 
make two calls:

camera->setComputeNearFarMode( osg::Camera::DO_NOT_COMPUTE_NEAR_FAR );
camera->setInheritanceMask( camera->getInheritanceMask() & 
~osg::Camera::COMPUTE_NEAR_FAR_MODE );

This sounds like backward compatibility problems. I suspect there is a 
number of examples and users code that call setComputeNearFar method only.

Maybe Camera::setComputeNearFarMode() method could also change inheritance 
mask ?

Or maybe adding additional default adjustInheritanceMask = true parameter 
could be added to
setComputeNearFarMode to keep actual inheritance policy and not break 
compatibility ie:

osg::Camera::setComputeNearFarMode(  ComputeNearFarMode  cnfm, 
adjustInheritanceMask = true ); ?

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, March 18, 2008 12:40 PM
Subject: Re: [osg-users] osgShadow example and gerneral question


HI Wojtek,

Excellent detective work.  I'll have to raise my hand as the culprit
of the change to CullVisitor::apply(Camera&), done is response to a
discussion between Mathias Froehlich and myself about inheritance of
settings.  I believe the inheritance of settings is now correct, but
obviously in my testing after applying this change I didn't spot the
regression in osgshadow and the unforseen consequences.

Since I think the actual rules of inheritance of settings are correct,
and things worked before because of bug in the inheritance of
settings, so its a matter of either changing the defaults in
CullSettings so that less of the inherited state comes down into the
local Camera, or we override the defaults locally.  I'd suggest we
change the defaults locally and review the defaults in light of how
many changes we make.

Robert.

On Tue, Mar 18, 2008 at 9:18 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
>  I think I have found the cause of the problem. Problem is not only 
> related
>  to osgShadow::ShadowMap. All Shadow mapping techniques exhibit similar 
> issue
>  (SM, SSM, & PSSM). And it looks like problem could be wider and affected
>  other examples as well.
>
>  Problem appeared when SVN changelist 7912 was added . This submission
>  changes Cameras cull settings inheritance policy during Cull traversal.
>  After this modification Shadow camera DO_NOT_COMPUTE_NEAR_FAR flag gets
>  overriden with main camera COMPUTE_NEAR_FAR setting . This in effect
>  desynchronizes texgen and depth map. Texgen is calculated using not 
> adjusted
>  Shadow camera projection. Shadow depth map is rendered using Shadow 
> camera
>  projection that was additionaly near/far adjusted.
>
>  Problem could be avoided by adding following line to shadow camera
>  initialization.
> _camera->setInheritanceMask( _camera->getInheritanceMask() &
>  ~osg::Camera::COMPUTE_NEAR_FAR_MODE );
>
>  But this topic brings another question: up till 7912 changelist, we were
>  simply using setComputeNearFar( false ) to avoid clamping of  projection
>  matrix. Does it mean that from now we will also need to add above 
> aditional
>  line to protect it from inheritance overriding ? If yes then we got a lot 
> of
>  code to review and adjust ...;-(
>
>
>  Cheers,
>  Wojtek
>
>  - Original Message -
>  From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
>  To: "OpenSceneGraph Users" 
>
>
> Sent: Monday, March 17, 2008 12:29 PM
>  Subject: Re: [osg-users] osgShadow example and gerneral question
>
>
>  Robert,
>
>  I replicated the problem with osgShadow::ShadowMap. I will try to find 
> the
>  cause...
>
>  Cheers,
>  Wojtek
>
>  - Original Message -
>  From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
>  To: "OpenSceneGraph Users" 
>  Sent: Monday, March 17, 2008 11:57 AM
>  Subject: Re: [osg-users] osgShadow example and gerneral question
>
>
>  Hi Robert,
>
>  There are few versions from 2000-2002. I found earlier 2000 version on
>  NVidia site. But 2002 version has the PolygonOffset section extended in
>  comparison to 2000.  It looks like siggraph 2002 presentation could be 
> found
>  under this link:
>
>  http://www1.cs.columbia.ed

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi Robert,

I think I have found the cause of the problem. Problem is not only related 
to osgShadow::ShadowMap. All Shadow mapping techniques exhibit similar issue 
(SM, SSM, & PSSM). And it looks like problem could be wider and affected 
other examples as well.

Problem appeared when SVN changelist 7912 was added . This submission 
changes Cameras cull settings inheritance policy during Cull traversal. 
After this modification Shadow camera DO_NOT_COMPUTE_NEAR_FAR flag gets 
overriden with main camera COMPUTE_NEAR_FAR setting . This in effect 
desynchronizes texgen and depth map. Texgen is calculated using not adjusted 
Shadow camera projection. Shadow depth map is rendered using Shadow camera 
projection that was additionaly near/far adjusted.

Problem could be avoided by adding following line to shadow camera 
initialization.
_camera->setInheritanceMask( _camera->getInheritanceMask() & 
~osg::Camera::COMPUTE_NEAR_FAR_MODE );

But this topic brings another question: up till 7912 changelist, we were 
simply using setComputeNearFar( false ) to avoid clamping of  projection 
matrix. Does it mean that from now we will also need to add above aditional 
line to protect it from inheritance overriding ? If yes then we got a lot of 
code to review and adjust ...;-(

Cheers,
Wojtek

- Original Message - 
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 17, 2008 12:29 PM
Subject: Re: [osg-users] osgShadow example and gerneral question


Robert,

I replicated the problem with osgShadow::ShadowMap. I will try to find the
cause...

Cheers,
Wojtek

- Original Message - 
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 17, 2008 11:57 AM
Subject: Re: [osg-users] osgShadow example and gerneral question


Hi Robert,

There are few versions from 2000-2002. I found earlier 2000 version on
NVidia site. But 2002 version has the PolygonOffset section extended in
comparison to 2000.  It looks like siggraph 2002 presentation could be found
under this link:

http://www1.cs.columbia.edu/~ravir/6160/papers/shadowmaps.ppt

Slides 20-27 refer to PolygonOffset topic.

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 17, 2008 11:26 AM
Subject: Re: [osg-users] osgShadow example and gerneral question


Hi Wojtek,

Could you post a link, or the actual presentation, or put it up on the
wiiki, of Mark Kilgrads paper discussing PolygonOffset.

It would nice to isolate the actual differences in implementation of
PolygonOffset across hardware so we can pick appropriate settings for
different hardware.  There are already some factors set in
PolygonOffset itself to try and cope with this but the values where
just set from basic experience with osgText, and not done is rigorous
way.  I would to roll this back and do a rigorous testing of different
hardware so we can get more consistent results across and models
sizes.

Robert.

On Mon, Mar 17, 2008 at 9:47 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> Hi Robert and All,
>
>  I am back from vacations. Ready to take the responsibility for my changes
> in
>  osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with
>  PSSM or standard ShadowMap as well ? Its not obvious from forum emails
> and I
>  am unable to replicate it with standard ShadowMap.
>
>  I looked once again at the my submitted osgShadow::ShadowMap code and I
> have
>  NOT changed polygon offset.
>  PolygonOffset remains untoched in several latest revisions.
>
>  However, I do have my objections against default ShadowMap
> cullface/polygon
>  offset settings. I remember that former (pre 2.0 osgShadow nodekit)
>  DepthShadowMap example was using frontface culling and polygon offset
>  factor=1.1 and units = 4. These were the settings that were also
> recommended
>  by NVidia ShadowMaping presentations ("ShadowMapping with Today's OpenGL
>  Hardware" Mark J. Kilgard NVidia). I use this as defaults in my work and
> I
>  am quite happy with them. I also noticed that Terry Welsh PSSM example
> also
>  used similar defaults.
>
>  But for some reason these recommended settings were changed when
>  osgShadow::ShadowMap was introduced. Whats more, I don't know in which
>  version exactly, but at some moment self shadowing and negative offset
> was
>  added (front face culling remained). See line 210 in
>  osgShadow::ShadowMap.cpp. In my opinion this is bit unusual method but I
>  understand that different databases and different render approaches may
>  benefit from different cull face/polygon offset settings.
>
>  Currently I work only with NVidia boards but I know that ATI may require
> 

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Robert,

I replicated the problem with osgShadow::ShadowMap. I will try to find the 
cause...

Cheers,
Wojtek

- Original Message - 
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 17, 2008 11:57 AM
Subject: Re: [osg-users] osgShadow example and gerneral question


Hi Robert,

There are few versions from 2000-2002. I found earlier 2000 version on
NVidia site. But 2002 version has the PolygonOffset section extended in
comparison to 2000.  It looks like siggraph 2002 presentation could be found
under this link:

http://www1.cs.columbia.edu/~ravir/6160/papers/shadowmaps.ppt

Slides 20-27 refer to PolygonOffset topic.

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 17, 2008 11:26 AM
Subject: Re: [osg-users] osgShadow example and gerneral question


Hi Wojtek,

Could you post a link, or the actual presentation, or put it up on the
wiiki, of Mark Kilgrads paper discussing PolygonOffset.

It would nice to isolate the actual differences in implementation of
PolygonOffset across hardware so we can pick appropriate settings for
different hardware.  There are already some factors set in
PolygonOffset itself to try and cope with this but the values where
just set from basic experience with osgText, and not done is rigorous
way.  I would to roll this back and do a rigorous testing of different
hardware so we can get more consistent results across and models
sizes.

Robert.

On Mon, Mar 17, 2008 at 9:47 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> Hi Robert and All,
>
>  I am back from vacations. Ready to take the responsibility for my changes
> in
>  osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with
>  PSSM or standard ShadowMap as well ? Its not obvious from forum emails
> and I
>  am unable to replicate it with standard ShadowMap.
>
>  I looked once again at the my submitted osgShadow::ShadowMap code and I
> have
>  NOT changed polygon offset.
>  PolygonOffset remains untoched in several latest revisions.
>
>  However, I do have my objections against default ShadowMap
> cullface/polygon
>  offset settings. I remember that former (pre 2.0 osgShadow nodekit)
>  DepthShadowMap example was using frontface culling and polygon offset
>  factor=1.1 and units = 4. These were the settings that were also
> recommended
>  by NVidia ShadowMaping presentations ("ShadowMapping with Today's OpenGL
>  Hardware" Mark J. Kilgard NVidia). I use this as defaults in my work and
> I
>  am quite happy with them. I also noticed that Terry Welsh PSSM example
> also
>  used similar defaults.
>
>  But for some reason these recommended settings were changed when
>  osgShadow::ShadowMap was introduced. Whats more, I don't know in which
>  version exactly, but at some moment self shadowing and negative offset
> was
>  added (front face culling remained). See line 210 in
>  osgShadow::ShadowMap.cpp. In my opinion this is bit unusual method but I
>  understand that different databases and different render approaches may
>  benefit from different cull face/polygon offset settings.
>
>  Currently I work only with NVidia boards but I know that ATI may require
>  different settings. I used to play with Direct3D DepthBias on NVidia and
> ATI
>  some time ago and results were significantly different for the same depth
>  bias values. I guess its the same situation with PolygonOffset in OpenGL.
>
>  I am afraid that completely getting rid of PolygonOffset is impossible
>  because there is no substitute for slope bias (PolygonOffset factor). No
>  Depth range nor Perspective matrix tricks could replace it. MJ. Kilgard
>  Presentation I mentioned earlier has nice expalanation of this topic. (I
> can
>  send it if anyone wants to have a look)
>
>  Cheers,
>  Wojtek Lewandowski
>
>
>
>  - Original Message -
>  From: "Robert Osfield" <[EMAIL PROTECTED]>
>  To: "OpenSceneGraph Users" 
>  Sent: Sunday, March 16, 2008 2:31 PM
>  Subject: Re: [osg-users] osgShadow example and gerneral question
>
>
>  HI Sebastian,
>
>  I see the artificate on Nvidia hardware so this rules out an ATI bug.
>  So far it I looks like an osgShadow bug, exactly what's gone amiss I
>  don't know though...
>
>  Robert.
>
>  On Sun, Mar 16, 2008 at 10:15 AM, Sebastian Messerschmidt
>  <[EMAIL PROTECTED]> wrote:
>  >
>  >
>  >
>  >
>  > Hi Adrian,
>  >
>  >
>  >
>  > As I've pointed out in the osg-users list, there seems to be a bug in
>  > recent
>  > ATI drivers where the t-coordinat

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi Robert,

There are few versions from 2000-2002. I found earlier 2000 version on 
NVidia site. But 2002 version has the PolygonOffset section extended in 
comparison to 2000.  It looks like siggraph 2002 presentation could be found 
under this link:

http://www1.cs.columbia.edu/~ravir/6160/papers/shadowmaps.ppt

Slides 20-27 refer to PolygonOffset topic.

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, March 17, 2008 11:26 AM
Subject: Re: [osg-users] osgShadow example and gerneral question


Hi Wojtek,

Could you post a link, or the actual presentation, or put it up on the
wiiki, of Mark Kilgrads paper discussing PolygonOffset.

It would nice to isolate the actual differences in implementation of
PolygonOffset across hardware so we can pick appropriate settings for
different hardware.  There are already some factors set in
PolygonOffset itself to try and cope with this but the values where
just set from basic experience with osgText, and not done is rigorous
way.  I would to roll this back and do a rigorous testing of different
hardware so we can get more consistent results across and models
sizes.

Robert.

On Mon, Mar 17, 2008 at 9:47 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> Hi Robert and All,
>
>  I am back from vacations. Ready to take the responsibility for my changes 
> in
>  osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with
>  PSSM or standard ShadowMap as well ? Its not obvious from forum emails 
> and I
>  am unable to replicate it with standard ShadowMap.
>
>  I looked once again at the my submitted osgShadow::ShadowMap code and I 
> have
>  NOT changed polygon offset.
>  PolygonOffset remains untoched in several latest revisions.
>
>  However, I do have my objections against default ShadowMap 
> cullface/polygon
>  offset settings. I remember that former (pre 2.0 osgShadow nodekit)
>  DepthShadowMap example was using frontface culling and polygon offset
>  factor=1.1 and units = 4. These were the settings that were also 
> recommended
>  by NVidia ShadowMaping presentations ("ShadowMapping with Today's OpenGL
>  Hardware" Mark J. Kilgard NVidia). I use this as defaults in my work and 
> I
>  am quite happy with them. I also noticed that Terry Welsh PSSM example 
> also
>  used similar defaults.
>
>  But for some reason these recommended settings were changed when
>  osgShadow::ShadowMap was introduced. Whats more, I don't know in which
>  version exactly, but at some moment self shadowing and negative offset 
> was
>  added (front face culling remained). See line 210 in
>  osgShadow::ShadowMap.cpp. In my opinion this is bit unusual method but I
>  understand that different databases and different render approaches may
>  benefit from different cull face/polygon offset settings.
>
>  Currently I work only with NVidia boards but I know that ATI may require
>  different settings. I used to play with Direct3D DepthBias on NVidia and 
> ATI
>  some time ago and results were significantly different for the same depth
>  bias values. I guess its the same situation with PolygonOffset in OpenGL.
>
>  I am afraid that completely getting rid of PolygonOffset is impossible
>  because there is no substitute for slope bias (PolygonOffset factor). No
>  Depth range nor Perspective matrix tricks could replace it. MJ. Kilgard
>  Presentation I mentioned earlier has nice expalanation of this topic. (I 
> can
>  send it if anyone wants to have a look)
>
>  Cheers,
>  Wojtek Lewandowski
>
>
>
>  - Original Message -
>  From: "Robert Osfield" <[EMAIL PROTECTED]>
>  To: "OpenSceneGraph Users" 
>  Sent: Sunday, March 16, 2008 2:31 PM
>  Subject: Re: [osg-users] osgShadow example and gerneral question
>
>
>  HI Sebastian,
>
>  I see the artificate on Nvidia hardware so this rules out an ATI bug.
>  So far it I looks like an osgShadow bug, exactly what's gone amiss I
>  don't know though...
>
>  Robert.
>
>  On Sun, Mar 16, 2008 at 10:15 AM, Sebastian Messerschmidt
>  <[EMAIL PROTECTED]> wrote:
>  >
>  >
>  >
>  >
>  > Hi Adrian,
>  >
>  >
>  >
>  > As I've pointed out in the osg-users list, there seems to be a bug in
>  > recent
>  > ATI drivers where the t-coordinate in the generated shadow texture is
>  > screwed up, i.e. inversed. Your screenshots don't look exactly like the
>  > artefacts I've seen but it might be related I reckon.
>  >
>  > To check this I recommend replacing the fixed function vertex shader by
>  > your
>  > own code which does the EYE_PLANE proj

Re: [osg-users] osgShadow example and gerneral question

[Wojciech Lewandowski]

Hi Robert and All,

I am back from vacations. Ready to take the responsibility for my changes in 
osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with 
PSSM or standard ShadowMap as well ? Its not obvious from forum emails and I 
am unable to replicate it with standard ShadowMap.

I looked once again at the my submitted osgShadow::ShadowMap code and I have 
NOT changed polygon offset.
PolygonOffset remains untoched in several latest revisions.

However, I do have my objections against default ShadowMap cullface/polygon 
offset settings. I remember that former (pre 2.0 osgShadow nodekit) 
DepthShadowMap example was using frontface culling and polygon offset 
factor=1.1 and units = 4. These were the settings that were also recommended 
by NVidia ShadowMaping presentations ("ShadowMapping with Today's OpenGL 
Hardware" Mark J. Kilgard NVidia). I use this as defaults in my work and I 
am quite happy with them. I also noticed that Terry Welsh PSSM example also 
used similar defaults.

But for some reason these recommended settings were changed when 
osgShadow::ShadowMap was introduced. Whats more, I don't know in which 
version exactly, but at some moment self shadowing and negative offset was 
added (front face culling remained). See line 210 in 
osgShadow::ShadowMap.cpp. In my opinion this is bit unusual method but I 
understand that different databases and different render approaches may 
benefit from different cull face/polygon offset settings.

Currently I work only with NVidia boards but I know that ATI may require 
different settings. I used to play with Direct3D DepthBias on NVidia and ATI 
some time ago and results were significantly different for the same depth 
bias values. I guess its the same situation with PolygonOffset in OpenGL.

I am afraid that completely getting rid of PolygonOffset is impossible 
because there is no substitute for slope bias (PolygonOffset factor). No 
Depth range nor Perspective matrix tricks could replace it. MJ. Kilgard 
Presentation I mentioned earlier has nice expalanation of this topic. (I can 
send it if anyone wants to have a look)

Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Sunday, March 16, 2008 2:31 PM
Subject: Re: [osg-users] osgShadow example and gerneral question


HI Sebastian,

I see the artificate on Nvidia hardware so this rules out an ATI bug.
So far it I looks like an osgShadow bug, exactly what's gone amiss I
don't know though...

Robert.

On Sun, Mar 16, 2008 at 10:15 AM, Sebastian Messerschmidt
<[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hi Adrian,
>
>
>
> As I've pointed out in the osg-users list, there seems to be a bug in 
> recent
> ATI drivers where the t-coordinate in the generated shadow texture is
> screwed up, i.e. inversed. Your screenshots don't look exactly like the
> artefacts I've seen but it might be related I reckon.
>
> To check this I recommend replacing the fixed function vertex shader by 
> your
> own code which does the EYE_PLANE projection and play around with the
> coordinates.
>
>
>
> Cheers
>
> Sebastian
>
>
>
>  
>
>
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag von Adrian
> Egli OpenSceneGraph (3D)
>  Gesendet: Donnerstag, 13. März 2008 21:57
>  An: OpenSceneGraph Users
>  Betreff: Re: [osg-users] osgShadow example and gerneral question
>
>
>
>
>
> some screenshots of the bug
>
>  /adi
>
>
> 2008/3/13, Adrian Egli OpenSceneGraph (3D) <[EMAIL PROTECTED]>:
>
> Since the OSG 2.2 or event some version before, osgShadow is broken. I 
> don't
> yet know why. but it doesn't work on ATI based computers as far as i could
> test it.
>
>
> 2008/3/13, Raymond de Vries <[EMAIL PROTECTED]>:
>
>
>
> Hi,
>
>  All I know that the PSSM implementation was not changed, the last I
>  looked at the svn version (some weeks ago), compared to 2.2.0. I will
>  test the svn version example also asap, and let you know.
>
>  Now that you mention PSSM, I've send a (small) patch some months ago and
>  suggested to change the interface a little so that parameters can be
>  changed at runtime (where it is currently only possible at startup).
>
>  Also I've send a bug report to the list in which I showed an artifact,
>  incl source code.
>
>  Within some weeks I would like to dive into PSSM again, so hopefully we
>  can join forces.
>
>  Cheers
>
>  Raymond
>
>
>
>  Jean-Sébastien Guay wrote:
>  > Hi Adrian,
>  >
>  >
>  >> i have retested osgShadow and get some really strange behaviour. event
>  >> PSSM doesn't work on my ATI x1600 based pc. was there changes and did 
> we
>  >> really test all options of osgshadow / implementation, or do
>  >> i only have such a problem
>  >>
>  >
>  > I remarked a while ago that osgshadow --pssm did not work for me on my
>  > nVidia card (even with the --NVidea (sic) switch, I see no shadows). No
>  > idea what's wrong, as I have no time to go into the details...
>  >
>

Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ... whowins?

[Wojciech Lewandowski]

Thanks,

> Yes, and OSG_EXPORT is a truly heavy bit of code, I needed to add some
> lead weights to the right hand side of the class definition to prevent
> its addition from tipping over my monitor!

No need for sarcasm here ;-). I have not said my fix was heavier but the
issue (missing symbols while linking)

>>  I have sent this fix to [EMAIL PROTECTED] but it
got
>>  bounced with message that mail needs to waits for moderator approval.
Its
>>  strange I double checked the address and it seems correct for
submissions.
>>  What did I wrong ? .

> It was your turn to do a typo... you type the address wrong, its a
> wonder it go through to the mailman server at all.

I agree I made and error in email text but not in the address for
submission. I checked this when it went through to osg-submissions list
after you intervention. Looks like Outlook added idiotic suffix to the
address and added camera.dat extension. I need to switch to normal mail
client.

Cheers,
Wojtek


-Original Message-
From: Robert Osfield [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 01, 2008 1:52 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?


On Sat, Mar 1, 2008 at 12:31 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
>  I just have sent a fix for heavier issue. New
>  Camera:DrawCalback::operator()( RenderInfo & ) needs to be exported in
>  Windows. Otherwise windows app using Camera::DrawCallbacks would not
link.

Yes, and OSG_EXPORT is a truly heavy bit of code, I needed to add some
lead weights to the right hand side of the class definition to prevent
its addition from tipping over my monitor!

>  I have sent this fix to [EMAIL PROTECTED] but it
got
>  bounced with message that mail needs to waits for moderator approval. Its
>  strange I double checked the address and it seems correct for
submissions.
>  What did I wrong ? .

It was your turn to do a typo... you type the address wrong, its a
wonder it go through to the mailman server at all.

>  So I attach this fixed Camera in this mail as well.

Thanks, I already added the OSG_EXPORT by hand, just checked against
your version and they are identical.

Changes and now checked in.

Robert.

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

Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ... whowins?

[Wojciech Lewandowski]

Robert,

I just have sent a fix for heavier issue. New
Camera:DrawCalback::operator()( RenderInfo & ) needs to be exported in
Windows. Otherwise windows app using Camera::DrawCallbacks would not link.

I have sent this fix to [EMAIL PROTECTED] but it got
bounced with message that mail needs to waits for moderator approval. Its
strange I double checked the address and it seems correct for submissions.
What did I wrong ? .

So I attach this fixed Camera in this mail as well.

Cheers,
Wojtek


-Original Message-
From: Robert Osfield [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 01, 2008 1:01 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?


On Fri, Feb 29, 2008 at 9:18 PM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
>  I noticed a typo in const getter function for InitialCallback. Method is
>  named getUnitialDrawCallback.

Oops now fixed and checked in.


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

Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ... whowins?

[Wojciech Lewandowski]

Thanks, Robert. I think I will be also happy with this solution ;-). I will
be leaving for two weeks soon so will not have the chance to test now it but
I will do this when I am back.

I noticed a typo in const getter function for InitialCallback. Method is
named getUnitialDrawCallback.

Cheers,
Wojtek


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert
Osfield
Sent: Friday, February 29, 2008 8:24 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?


On Fri, Feb 29, 2008 at 6:24 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> > The RenderInfo version is the main one now, this calls the
>  > Camera version for backwards compatibility.
>
>  This change effectively deprecates the old interface, because if someone
>  overrides the new operator()(RenderInfo&) interface but doesn't call the
old
>  interface in their callback, then the old interface never gets called. Is
>  this correct?

Yes this is correct, but if one doesn't call the old method in your
own callback it really isn't a problem as the old method is just a non
op anyway, it only isn't a non op if you implement it, and only ever a
problem if you implement both.

>  Currently, OcclusionQueryNode uses the old interface to retrieve query
>  results.
>
>  Could you possibly rearchitect this change so that we have some assurance
>  that the old interface will continue to get called? Alternately, you
could
>  modify OcclusionQueryNode to use the new callback interface.

I don't see a strong need to remove the old method right now, its
slightly less minimal and perhaps a potentially little confusing but
code wise its not unsafe.

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] Camera POST_RENDER vs. postDrawCallback ... whowins?

[Wojciech Lewandowski]

Hi Robert,

> I'll be doing some merges this morning and once this done will spend a
> bit of time reflecting on this issue.

Thank You,  I don't opt for any specific solution. Anything what gives a 
method to grab current State object will help. I gues Justin will say the 
same if he would able to figure out current View...

Wojtek 

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

Re: [osg-users] Complete darkness

[Wojciech Lewandowski]

Sounds like default Light Model ambient Look at OpenGL docs for 
glLightModel & GL_LIGHT_MODEL_AMBIENT.

Cheers,
Wojtek

- Original Message - 
From: "Necdet Can Atesman" <[EMAIL PROTECTED]>
To: 
Sent: Friday, February 29, 2008 1:10 AM
Subject: [osg-users] Complete darkness


> Hi folks,
> 
> I am unable to create complete darkness in osg. I'm setting the only
> light source to not emit anything, but the objects in my scene are still
> visible, although very faintly. Is there something wrong with the code,
> or is it just osg/opengl?
> 
> osg::Light* light = new osg::Light();
> light->setAmbient(osg::Vec4d(0.0f, 0.0f, 0.0f, 1.0f));
> light->setDiffuse(osg::Vec4d(0.0f, 0.0f, 0.0f, 1.0f));
> light->setSpecular(osg::Vec4d(0.0f, 0.0f, 0.0f, 1.0f));
> osgView* view = new osg::View();
> osgView->setLightingMode(osg::View::HEADLIGHT);
> view->setLight(light);
> 
> Thanks,
> Necdet Can
> ___
> 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] Camera POST_RENDER vs. postDrawCallback ... whowins?

[Wojciech Lewandowski]

Hi again,

I should problably add one note here: One may say that Camera has getView
method. This method returns NULL for graph nested cameras. I pressume its
valid only for main views and slaves.

Cheers,
Wojtek


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Wojciech
Lewandowski
Sent: Thursday, February 28, 2008 9:07 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?


Hi Justin,

Look at void osgUtil::RenderStage::draw(osg::RenderInfo&
renderInfo,RenderLeaf*& previous)  method.(Line 825 in currnt SVN
src/osgUtil/RenderStage.cpp). Its all there.

1: Prerender cameras add Prerender stages. Prerender stages are drawn first.
Line 833:
   drawPreRenderStages(renderInfo,previous);

2: Camera::preDrawCallback is called later
Line 880:
if (_camera && _camera->getPreDrawCallback())
{
// if we have a camera with a post draw callback invoke it.
(*(_camera->getPreDrawCallback()))(*_camera);
}

3: Then Camera graph (its RenderStage) is drawn
Lines 891-921: (it has two paths for multithreaded and singlethreaded
drawing)

Single Threader case is located in:
Line 913:
drawInner( useRenderInfo, previous, doCopyTexture);

4: Camera::postDrawCallback gets called
Line: 943
if (_camera && _camera->getPostDrawCallback())
{
// if we have a camera with a post draw callback invoke it.
(*(_camera->getPostDrawCallback()))(*_camera);
}

5: Post Render stages from PostRender Cameras are drawn (post render HUD is
usually drawn as a result of this call):
Line: 979 (last line of the method)
drawPostRenderStages(renderInfo,previous);


So reassuming:
Main camera postDrawCallback is always called before your postrender HUD
camera preDraw & postDraw callbacks. So you need to use HUD callback but
there is a problem of recognizing which view has called it. I agree with you
here. I had similar problem recently: there is not enough information passed
to DrawCamera callback. Only one parameter - Camera refernce does not allow
to identify view nor identify gl context (I was unable to call some GL
extension functions in this callback). It sounds like some aditional
parameters should be added to Camera::DrawCallback (RenderInfo ?) or Camera
should have methods to find cooresponding state and view objects. I am
afraid Robert is the only one who can solve this issue.

Cheers,
Wojtek Lewandowski




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Vican,
Justin E.
Sent: Thursday, February 28, 2008 6:40 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?


Hi Robert,
Thanks for getting back to me.  I still seem to be having an issue with
this.  I've attached 3 simple images illustrating the issue.  The text
overly should say "M!".  When I use a post render HUD
camera, it shows up visually correct at runtime
(POST_RENDER_Screenshot.jpg), but I can get the overlay text into the
frame grab (POST_RENDER_FrameGrab.jpg).  However, any combination of
NESTED_RENDER and render bins gives me the problem illustrated in
NESTED_RENDER_FrameGrab.jpg.  The "world space" objects can obscure the
HUD items.

1.)  I have a viewer (osg::Viewer named "viewer1") with a camera
(osg::Camera named "ViewCamera"), and a scene graph that includes a HUD
camera (osg::Camera named "HUDCamera") which has its rendering order set
to POST_RENDER, and I have added a postDrawCallback to the first camera
("ViewCamera").  This is the frame grabbing callback.  Your response to
question 1 would indicate to me that the subgraph inside of "HUDCamera"
is supposed to draw before the "ViewCamera" postDrawCallback is called.
It looks like this is happening in the reverse order.  The
postDrawCallback of "ViewCamera" is being called before the "HUDCamera"
subgraph is rendering which is why I can't see the text in the frame
grab.

   osg::Viewer("viewer1")
 |
 osg::View("view1")
 |
  osg::Camera("ViewCamera") ->setPostDrawCallback(foo).
 |
 osg::Group("SceenRootNode")
 /   \
/ \
osg::Group("OtherStuff") osg::Camera("HUDCamera")
->setRenderOrder(POST_RENDER)


2.)  I've tried adding a postDrawCallback to the HUD camera, but I'm
using the CompositeViewer class so I have potentially N views into the
scene.  These callbacks a

Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ... whowins?

[Wojciech Lewandowski]

Hi Justin,

Look at void osgUtil::RenderStage::draw(osg::RenderInfo&
renderInfo,RenderLeaf*& previous)  method.(Line 825 in currnt SVN
src/osgUtil/RenderStage.cpp). Its all there.

1: Prerender cameras add Prerender stages. Prerender stages are drawn first.
Line 833:
   drawPreRenderStages(renderInfo,previous);

2: Camera::preDrawCallback is called later
Line 880:
if (_camera && _camera->getPreDrawCallback())
{
// if we have a camera with a post draw callback invoke it.
(*(_camera->getPreDrawCallback()))(*_camera);
}

3: Then Camera graph (its RenderStage) is drawn
Lines 891-921: (it has two paths for multithreaded and singlethreaded
drawing)

Single Threader case is located in:
Line 913:
drawInner( useRenderInfo, previous, doCopyTexture);

4: Camera::postDrawCallback gets called
Line: 943
if (_camera && _camera->getPostDrawCallback())
{
// if we have a camera with a post draw callback invoke it.
(*(_camera->getPostDrawCallback()))(*_camera);
}

5: Post Render stages from PostRender Cameras are drawn (post render HUD is
usually drawn as a result of this call):
Line: 979 (last line of the method)
drawPostRenderStages(renderInfo,previous);


So reassuming:
Main camera postDrawCallback is always called before your postrender HUD
camera preDraw & postDraw callbacks. So you need to use HUD callback but
there is a problem of recognizing which view has called it. I agree with you
here. I had similar problem recently: there is not enough information passed
to DrawCamera callback. Only one parameter - Camera refernce does not allow
to identify view nor identify gl context (I was unable to call some GL
extension functions in this callback). It sounds like some aditional
parameters should be added to Camera::DrawCallback (RenderInfo ?) or Camera
should have methods to find cooresponding state and view objects. I am
afraid Robert is the only one who can solve this issue.

Cheers,
Wojtek Lewandowski




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Vican,
Justin E.
Sent: Thursday, February 28, 2008 6:40 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Camera POST_RENDER vs. postDrawCallback ...
whowins?


Hi Robert,
Thanks for getting back to me.  I still seem to be having an issue with
this.  I've attached 3 simple images illustrating the issue.  The text
overly should say "M!".  When I use a post render HUD
camera, it shows up visually correct at runtime
(POST_RENDER_Screenshot.jpg), but I can get the overlay text into the
frame grab (POST_RENDER_FrameGrab.jpg).  However, any combination of
NESTED_RENDER and render bins gives me the problem illustrated in
NESTED_RENDER_FrameGrab.jpg.  The "world space" objects can obscure the
HUD items.

1.)  I have a viewer (osg::Viewer named "viewer1") with a camera
(osg::Camera named "ViewCamera"), and a scene graph that includes a HUD
camera (osg::Camera named "HUDCamera") which has its rendering order set
to POST_RENDER, and I have added a postDrawCallback to the first camera
("ViewCamera").  This is the frame grabbing callback.  Your response to
question 1 would indicate to me that the subgraph inside of "HUDCamera"
is supposed to draw before the "ViewCamera" postDrawCallback is called.
It looks like this is happening in the reverse order.  The
postDrawCallback of "ViewCamera" is being called before the "HUDCamera"
subgraph is rendering which is why I can't see the text in the frame
grab.

   osg::Viewer("viewer1")
 |
 osg::View("view1")
 |
  osg::Camera("ViewCamera") ->setPostDrawCallback(foo).
 |
 osg::Group("SceenRootNode")
 /   \
/ \
osg::Group("OtherStuff") osg::Camera("HUDCamera")
->setRenderOrder(POST_RENDER)


2.)  I've tried adding a postDrawCallback to the HUD camera, but I'm
using the CompositeViewer class so I have potentially N views into the
scene.  These callbacks are doing pixel reads and saving them to images
(frame capturing), so I need the viewport dimensions of the current
viewer's camera (not the HUD camera).  I'm also controlling the frame
grabbing on a per-view basis.  At present, the osg::Camera class only
allows me to add 1 postDrawCallback, so the HUD cannot support any more
than a single callback.  I'm trying to work something out with nested
callbacks, but I'm having trouble figuring out which viewer has finished
rendering by the time the HUD callback is called.  Is there any way to
know which viewer is currently rendering the scene inside of the
osg:Camera::DrawCallback::operator(const osg::camera&) method?.


   osg::Composit

Re: [osg-users] Problem to consider: Shadow maps and LOD computation

[Wojciech Lewandowski]

Hi Everyone interested in this topic.

Solution was very simple. All I had to do was to change my ShadowMap camera 
RefernceFrame to ABSOLUTE_RF_INHERIT_VIEWPOINT.

Thanks to for solving this problem before Robert ;-)

Btw. osgShadow::ShadowMap still sets ABSOLUTE_RF maybe we could change it ? 
I will send proper submission.

Cheers,
Wojtek



- Original Message - 
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, February 26, 2008 9:28 PM
Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD 
computation


>
> Thanks Terry, Brain and Robert,
>
> I will follow all your ViewPoint suggestions tomorrow.
>
>
> Wojtek
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Robert
> Osfield
> Sent: Tuesday, February 26, 2008 9:24 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD
> computation
>
>
> Hi Guys,
>
> You are on the right track with ViewPoint - it exists to solve this
> problem - a RTT effect that needs to have LOD's chosen on the main
> cameras view point (eye point) not the RTT's camera's eye point.   I
> introduced it when Terry Welsh came across this problem when he was
> doing his development of his implementation of parallel split shadow
> maps.
>
> I've just got back so I'm a bit cold on this topic right now, perhaps
> Terry will remember things better than I...
>
> Robert.
>
> On Tue, Feb 26, 2008 at 5:46 PM, Brian R Hill <[EMAIL PROTECTED]> wrote:
>> Wojtek,
>>
>>  I don't know. I just looked at the LOD::traverse method and saw that it
>>  called the node visitor getDistanceToViewPoint method, which for the
>>  CullVisitor calls the CullStack::getViewPointLocal method.
>>
>>  Ooops, looks like you'll need to override
>>  CullVisitor::getDistanceToViewPoint, not CullVisitor::getViewPoint. 
>> Also,
>>  the view point will need to be relative to the LOD object.
>>
>>  I searched the entire OSG tree and only LOD and PagedLOD call
>>  getDistanceToViewPoint, so it should be pretty safe.
>>
>>  Caveat - I've only looked at the code and haven't tried this.
>>
>>
>>  Brian
>>
>>  [EMAIL PROTECTED] wrote: -
>>
>>
>>  To: "OpenSceneGraph Users" 
>>  From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
>>  Sent by: [EMAIL PROTECTED]
>>  Date: 02/26/2008 12:15PM
>>
>> Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD
>>  computation
>>
>>
>>
>> Hi Brian,
>>
>>  > It looks like you'll need to create a custom cull visitor that stores
> the
>>  > desired eye point and overrides the CullVisitor::getViewPoint method 
>> to
>>  > return the stored eye point instead of the CullStack view point.
>>
>>  Thats sounds like it something I might be able to do ;-). Do you know if
>>  changed viewPoint would affect other types of nodes apart from  LOD  ?
>>
>>  Thanks,
>>  Wojtek
>>
>>  ___
>>  osg-users mailing list
>>  osg-users@lists.openscenegraph.org
>>
>>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org---
> 
> 
> -
>>
>>  This is a PRIVATE message. If you are not the intended recipient, please
>>  delete without copying and kindly advise us by e-mail of the mistake in
>>  delivery. NOTE: Regardless of content, this e-mail shall not operate to
>>  bind CSC to any order or other contract unless pursuant to explicit
> written
>>  agreement or government initiative expressly permitting the use of 
>> e-mail
>>  for such purpose.
>>  -
> 
> ---
>>
>>  ___
>>
>>
>> osg-users mailing list
>>  osg-users@lists.openscenegraph.org
>> 
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> ___
> osg-users 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] Problem to consider: Shadow maps and LOD computation

[Wojciech Lewandowski]

Thanks Terry, Brain and Robert,

I will follow all your ViewPoint suggestions tomorrow.


Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert
Osfield
Sent: Tuesday, February 26, 2008 9:24 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD
computation


Hi Guys,

You are on the right track with ViewPoint - it exists to solve this
problem - a RTT effect that needs to have LOD's chosen on the main
cameras view point (eye point) not the RTT's camera's eye point.   I
introduced it when Terry Welsh came across this problem when he was
doing his development of his implementation of parallel split shadow
maps.

I've just got back so I'm a bit cold on this topic right now, perhaps
Terry will remember things better than I...

Robert.

On Tue, Feb 26, 2008 at 5:46 PM, Brian R Hill <[EMAIL PROTECTED]> wrote:
> Wojtek,
>
>  I don't know. I just looked at the LOD::traverse method and saw that it
>  called the node visitor getDistanceToViewPoint method, which for the
>  CullVisitor calls the CullStack::getViewPointLocal method.
>
>  Ooops, looks like you'll need to override
>  CullVisitor::getDistanceToViewPoint, not CullVisitor::getViewPoint. Also,
>  the view point will need to be relative to the LOD object.
>
>  I searched the entire OSG tree and only LOD and PagedLOD call
>  getDistanceToViewPoint, so it should be pretty safe.
>
>  Caveat - I've only looked at the code and haven't tried this.
>
>
>  Brian
>
>  [EMAIL PROTECTED] wrote: -
>
>
>  To: "OpenSceneGraph Users" 
>  From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
>  Sent by: [EMAIL PROTECTED]
>  Date: 02/26/2008 12:15PM
>
> Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD
>  computation
>
>
>
> Hi Brian,
>
>  > It looks like you'll need to create a custom cull visitor that stores
the
>  > desired eye point and overrides the CullVisitor::getViewPoint method to
>  > return the stored eye point instead of the CullStack view point.
>
>  Thats sounds like it something I might be able to do ;-). Do you know if
>  changed viewPoint would affect other types of nodes apart from  LOD  ?
>
>  Thanks,
>  Wojtek
>
>  ___
>  osg-users mailing list
>  osg-users@lists.openscenegraph.org
>
>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org---


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

---
>
>  ___
>
>
> osg-users mailing list
>  osg-users@lists.openscenegraph.org
>  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users 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 to consider: Shadow maps and LOD

[Wojciech Lewandowski]

Thanks,

So you say that OSG is supposed to work the way I want. I suspected that
EyePoint/ViewPoint methods could be somehow used for this purpose but it
looks like one of them was exactly added for this purpose. Thanks for
clarification.
So now it seems that my ShadowMap derived code might have another problem.
I will look into it and see what goes wrong.

Thanks again,
Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Terry Welsh
Sent: Tuesday, February 26, 2008 7:07 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD


Hi Wojciech,
Robert and I discussed this issue in great detail over a year ago.
Here are some related email threads:
http://osgcvs.no-ip.com/osgarchiver/archives/August2006/0307.html
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-
October/003697.html

Eventually, Robert made some changes to OSG (including the addition of
the View class) which eliminated this problem.  It fixed my own
shadows completely.  I wonder if your shadows are just finding some
corner case that is tricking Robert's fix into not working
--
Terry Welsh - mogumbo 'at' gmail.com
www.reallyslick.com  |  www.mogumbo.com


>  Message: 5
>  Date: Tue, 26 Feb 2008 15:18:13 +0100
>  From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
>  Subject: [osg-users] Problem to consider: Shadow maps and LOD
> computation
>  To: 
>  Message-ID: <[EMAIL PROTECTED]>
>  Content-Type: text/plain; charset="windows-1250"
>
>  Hello everyone,
>
>  I have following problem: Shadow Mapping - so called duelling frusta case
ie light direction opposite to view direction. Objects drawn into Shadow Map
also contain LOD nodes. When rendering shadow map LODs are drawn based on
distance computed from shadow camera. But this is plain wrong: LODs should
be always selected based on distance from main camera. Is there a way to
overcome this problem and force LODs drawn into shadow map to be base on
distances from main cam ?
>
>  Thanks in advance, any ideas would be appreciated,
>
>  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] Problem to consider: Shadow maps and LOD computation

[Wojciech Lewandowski]

Hi Brian,

> It looks like you'll need to create a custom cull visitor that stores the
> desired eye point and overrides the CullVisitor::getViewPoint method to
> return the stored eye point instead of the CullStack view point.

Thats sounds like it something I might be able to do ;-). Do you know if 
changed viewPoint would affect other types of nodes apart from  LOD  ?

Thanks,
Wojtek 

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

Re: [osg-users] Problem to consider: Shadow maps and LOD computation

[Wojciech Lewandowski]

Hi Paul,

> If your eye is close to the shadow but far from the caster, then the 
> shadow
> covers a large pixel area and the caster covers a small pixel area. This 
> is
> exactly the case where you would want to use two different levels of 
> detail
> for the caster -- one to create a high resolution shadow, and the lower 
> LOD
> for the final rendered image of the caster. If the LOD distances are
> configured correctly, the user should not notice that the caster and 
> shadow
> were rendered with two different levels of detail; the difference will be
> lost in screen resolution.

Ok, I agree its ideal solution.

But in practice I don't know where the receivers are. Infact receivers in 
this ideal case are not specific objects but random pixels on the screen. 
Shadow from one object can be cast on multituple objects in the scene. So 
implemnting proper metrics for LOD selection sounds like scene analysis 
approach. This would be an overkill considering my real time framerate 
requirements ;-)

Cheers,
Wojtek

- Original Message - 
From: "Paul Martz" <[EMAIL PROTECTED]>
To: "'OpenSceneGraph Users'" 
Sent: Tuesday, February 26, 2008 5:12 PM
Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD 
computation


>> > Ideally, you would want the shadow caster's LOD to be
>> selected based
>> > on the distance between the eyepoint and the shadow
>> receiver, wouldn't
>> > you?
>>
>> Actually I would like it to be based on the distance from
>> eyepoint to Shadow Caster (measured in main camera view
>> space). If its based on / or adjusted to distance from Shadow
>> Receiver we may end up with one LOD used on main camera
>> screen and other LOD used in shadow map texture. Ie shape of
>> shadow would be different than object on the screen casting
>> the shadow.
>
> That might be the solution you want, but I don't think it's a good general
> solution for proper rendering.
>
>   -Paul
>
> ___
> 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 to consider: Shadow maps and LOD computation

[Wojciech Lewandowski]

Hi Paul,

> Ideally, you would want the shadow caster's LOD to be selected based on 
> the
> distance between the eyepoint and the shadow receiver, wouldn't you?

Actually I would like it to be based on the distance from eyepoint to Shadow 
Caster (measured in main camera view space). If its based on / or adjusted 
to distance from Shadow Receiver we may end up with one LOD used on main 
camera screen and other LOD used in shadow map texture. Ie shape of shadow 
would be different than object on the screen casting the shadow.

Cheers,
Wojtek

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

Re: [osg-users] Problem to consider: Shadow maps and LOD computation

[Wojciech Lewandowski]

Hi J-S,

I am not sure what is the difference between EyePoint and ViewPoint but 
really hope that EyePoint/ViewPoint duo was introduced for problems like 
mine. If I only knew how to use them to my advantage ;-)

Cheers,
Wojtek

- Original Message - 
From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, February 26, 2008 3:29 PM
Subject: Re: [osg-users] Problem to consider: Shadow maps and LOD 
computation


> Hi Wojtek,
>
>> When rendering shadow map LODs
>> are drawn based on distance computed from shadow camera. But this is
>> plain wrong: LODs should be always selected based on distance from main
>> camera.
>
> Oh, nice problem there... It's probably just an oversight, and the fact
> that osgShadow tries to be as transparent and as unobtrusive as possible
> will make it harder to overcome...
>
> I don't have any suggestions for this, perhaps Robert will have some
> thoughts as it comes down more to how to design the interaction between
> shadowing and LODs.
>
> Good luck,
>
> J-S
> -- 
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>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

[osg-users] Problem to consider: Shadow maps and LOD computation

[Wojciech Lewandowski]

Hello everyone,

I have following problem: Shadow Mapping - so called duelling frusta case ie 
light direction opposite to view direction. Objects drawn into Shadow Map also 
contain LOD nodes. When rendering shadow map LODs are drawn based on distance 
computed from shadow camera. But this is plain wrong: LODs should be always 
selected based on distance from main camera. Is there a way to overcome this 
problem and force LODs drawn into shadow map to be base on distances from main 
cam ? 

Thanks in advance, any ideas would be appreciated,

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

Re: [osg-users] Vector/Model data inserts in VPB/OSGDEM terrain.Possible ?

[Wojciech Lewandowski]

Hi Robert,

> VPB doesn't yet support this type of operation, so you'll need to do
> this as a post process operation of the database

Thanks for clarification.

I noticed that there is VPBExtrude example in VPB repository. What it does ?

Cheers,
Wojtek

P.S. Have you noticed my submissions for OverlayNode CustomPolytope, 
osg::Plane and CoordinateSystemNode ?  I might have sent them to 
[EMAIL PROTECTED] instead of 
[EMAIL PROTECTED]

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "OpenSceneGraph Users" 

Sent: Friday, February 15, 2008 12:28 PM
Subject: Re: [osg-users] Vector/Model data inserts in VPB/OSGDEM 
terrain.Possible ?


> Hi Wojciech,
>
> VPB doesn't yet support this type of operation, so you'll need to do
> this as a post process operation of the database
>
> Robert.
>
> On Fri, Feb 8, 2008 at 9:56 PM, Wojciech Lewandowski
> <[EMAIL PROTECTED]> wrote:
>>
>>
>> Thanks,
>>
>>
>> I am looking for some tool that will cut portions of OSGDEM/VPB terrain 
>> tile
>> meshes for airport models as a terrain postprocessing step.
>>
>> I thought TDS is aimed at run time terrain modifications - like making
>> explosion craters or digging trenches. But after brief look at TDS
>> doumentation I see it may be relevant... I will further check it. Thank 
>> You.
>>
>> Cheers,
>> Wojtek
>>
>>
>>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] Behalf Of Brian
>> Sent: Friday, February 08, 2008 6:28 PM
>> To: OpenSceneGraph Users
>> Subject: Re: [osg-users] Vector/Model data inserts in VPB/OSGDEM
>> terrain.Possible ?
>>
>>
>> Have you looked at osgTDS
>> http://www.andesengineering.com/Projects/TDS/
>>
>> Brian
>>
>>
>> On Feb 8, 2008 6:16 AM, Wojciech Lewandowski <[EMAIL PROTECTED]> 
>> wrote:
>>
>> >
>> >
>> > Hi everyone,
>> >
>> > Does VPB (or OSGDEM) allow to make holes in the terrain mesh for high
>> fidelity vector models ?
>> > If not, maybe you can offer some suggestions how to do it ?
>> >
>> > Thanks in advance,
>> > 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] Framerate vs stats?

[Wojciech Lewandowski]

Hi J-S,

> I've seen that, but only when compiled in debug mode... Check to see if
> you're in debug. Never do performance timing in debug mode :-)
>
> If you're in release, then I haven't seen this, might be a driver bug...

Its in Release mode. But we also found problem is present only in 
multi-monitor configurations. So its probably a driver issue.
Cheers,

Wojtek



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

Re: [osg-users] Framerate vs stats?

[Wojciech Lewandowski]

Hi again,

Just out curiosity can anyone with two monitors check if this happens with his 
setup ? I made this test on XP/GeForce 7800 GTX and Vista/GeForce 8800. If I 
have two monitors active draw time degrades if only one monitor draw time is 
stable. 

Thanks in advance,
Wojtek 

  - Original Message - 
  From: Wojciech Lewandowski 
  To: OpenSceneGraph Users 
  Sent: Friday, February 15, 2008 2:42 PM
  Subject: Re: [osg-users] Framerate vs stats?


  Thanks Serge,

   I have to withdraw my claim. Your mail gave me something to think and I 
checked whether problem exists in single monitor mode. 

  I turned off my second monitor in Display properties... and  Tada! - problem 
vanished. Framerate is stable. 

  This is not the first time I observe unusual OSG/OpenGL behaviour in 
multimonitor mode. I guess its the drivers again. Sometimes changing NVidia 
multimonitor/mutihreading settings help but most often it does not...;-( 

  Thanks for helping to isolate this issue,

  Wojtek 

  - Original Message - 
From: Serge Lages 
To: OpenSceneGraph Users 
Sent: Friday, February 15, 2008 1:10 PM
Subject: Re: [osg-users] Framerate vs stats?


On Fri, Feb 15, 2008 at 12:57 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> 
wrote:

  Hi Robert,

  We noticed another issue. When statistics bars are on - framerate slowly
  degrades. This happens with osgviewer dumptruck.osg for example. When 
stats
  are on draw time slowly grows and framerate starts to decrease.

  Tested with latest svn (2.3.4), windows xp & vista, OSG built with VS 
2008.

  Regards,
  Wojtek




Hi Wojtek,

I've just tested it (latest SVN, WinXP but VS2005, NVidia 8600GTS), and 
there is no decrease here, my framerate stay at the same value (tested with 
vsync on and off). Have you noticed this problem with VS 2005 too ?

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

Re: [osg-users] Framerate vs stats?

[Wojciech Lewandowski]

Thanks Serge,

 I have to withdraw my claim. Your mail gave me something to think and I 
checked whether problem exists in single monitor mode. 

I turned off my second monitor in Display properties... and  Tada! - problem 
vanished. Framerate is stable. 

This is not the first time I observe unusual OSG/OpenGL behaviour in 
multimonitor mode. I guess its the drivers again. Sometimes changing NVidia 
multimonitor/mutihreading settings help but most often it does not...;-( 

Thanks for helping to isolate this issue,

Wojtek 

- Original Message - 
  From: Serge Lages 
  To: OpenSceneGraph Users 
  Sent: Friday, February 15, 2008 1:10 PM
  Subject: Re: [osg-users] Framerate vs stats?


  On Fri, Feb 15, 2008 at 12:57 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> 
wrote:

Hi Robert,

We noticed another issue. When statistics bars are on - framerate slowly
degrades. This happens with osgviewer dumptruck.osg for example. When stats
are on draw time slowly grows and framerate starts to decrease.

Tested with latest svn (2.3.4), windows xp & vista, OSG built with VS 2008.

Regards,
Wojtek




  Hi Wojtek,

  I've just tested it (latest SVN, WinXP but VS2005, NVidia 8600GTS), and there 
is no decrease here, my framerate stay at the same value (tested with vsync on 
and off). Have you noticed this problem with VS 2005 too ?

  -- 
  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] Framerate vs stats?

[Wojciech Lewandowski]

Hi Robert,

We noticed another issue. When statistics bars are on - framerate slowly 
degrades. This happens with osgviewer dumptruck.osg for example. When stats 
are on draw time slowly grows and framerate starts to decrease.

Tested with latest svn (2.3.4), windows xp & vista, OSG built with VS 2008.

Regards,
Wojtek


- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Friday, February 15, 2008 11:57 AM
Subject: Re: [osg-users] Framerate vs stats?


Hi J-S,

On screen stats adds extra compute and GPU load to the rendering of
the frame, so one would expect it reduce rather than enhance frame
rate.  The fact that you have an instance where the reverse happens
suggest something odd happening with the OpenGL driver - something
like is given the boot when the OpenGL data that the OSG send changes
slightly.  Try other things to jolt the driver by toggle texturing or
lighting to see what happens.

Robert.

On Mon, Feb 4, 2008 at 3:31 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
> Hello all,
>
>  I'm seeing something peculiar in one of our apps using OSG 2.2, and I
>  was wondering if someone else had seen something like this or would have
>  an idea what would cause it.
>
>  The app starts and seems sluggish. Pressing 's' once shows it's running
>  at around 15-20 FPS. But then, if I press 's' a second time, the
>  framerate shoots up to >75 FPS (capped by my refresh rate) and the app
>  is suddenly very smooth. And it stays like that too (I can hide the
>  stats again or whatever, it has no significant effect on the frame rate).
>
>  So, what could cause this? Why would showing the detailed stats screen
>  have that effect? I've seen cases where showing detailed stats _slowed_
>  the frame rate, but this is the first time it makes it faster!
>
>  Thanks in advance,
>
>  J-S
>
>  --
>  __
>  Jean-Sebastien Guay[EMAIL PROTECTED]
>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


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

Re: [osg-users] osgShadow one shot shadow map

[Wojciech Lewandowski]

Hi J-S,

> Thank you Wojtek, I'll check that out! I'm really very grateful to you 
> for contributing this. I've been banging my head on this and we're still 
> on OSG 2.2 here so I didn't think of going to see in the new additions 
> if there was something that would help me out.

You're welcome. I am glad I could help. 

Wojtek  


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

Re: [osg-users] osgShadow one shot shadow map

[Wojciech Lewandowski]

Hi J-S,

>This is the part I'm having trouble with. I actually don't mind using
>the scene bound I get with the ComputeBoundingBoxVisitor, but getting a
>usable camera frustum (both for main and light cameras) and then
>intersecting those is the hard part for me. Any tips there? How do you
>create the convex objects? How do you do the intersection itself?

This piece of code was actually written by Robert ;-). I use his utility
CustomPolytope class from osgSim::OverlayNode.cpp. It computes the
intersection of two polytopes. Its named CustomPolytope but it does work
well as convex hull representation. I attached this class repacked into
separate header. Its identical to CustomPolytope from OverlayNode with one
bug fixed in my version. I submitted this fix to OverlayNode.cpp but its
still pending.  So I suggest to use my header before Robert  returns.

Code for computing frustum polytope is obvious provided we have camera view
& projection matrices:
/
osg::Matrix mvp = camera->getViewMatrix() * camera->getProjectionMatrix();
CustomPolytope cpCameraFrustum;
cpCameraFrustum.setToUnitFrustum( );
// transform frustum from clip space into world coords
cpCameraFrustum.transform( osg::Matrix::inverse(  mvp ), mvp );
/

Of course there is also a method to build CustomPolytope from bounding box:
/
CustomPolytope cpSceneBounds;
cp.setToBoundingBox( sceneBounds );
/

Computing intersection is straight forward
Suppose we have two polytopes for main camera frustum & coarse shadow camera
frustum and scene bounds polytope.
/
CustomPolytope cpMainCamera, cpCoarseShadowCamera,  cpSceneBounds;

CustomPolytope cpIntersection( cpSceneBounds );
cpIntersection.cut( cpMainCamera );
cpIntersection.cut( cpCoarseShadowCamera );
/

CustomPolytope::getVertices returns corners of the convex hull so its easy
to find its bounding box. I compute precise shadow camera projection using
such bounding box around intersection polytope transformed to shadow space.

And thats it. Thank you Robert !

Wojtek Lewandowski
#ifndef CUSTOMPOLYTOPE_H
#define CUSTOMPOLYTOPE_H

#include
#include
#include

// Class directly copied osgSim::OverlayNode (+prefixed few Vec3d occurences 
with osg::)
class CustomPolytope
{
public:

CustomPolytope() {}

typedef std::vector Vertices;

struct Face
{
std::string name;
osg::Plane  plane;
Verticesvertices;
};

Face& createFace() { _faces.push_back(Face()); return _faces.back(); }


/** Create a Polytope which is a cube, centered at 0,0,0, with sides of 2 
units.*/
void setToUnitFrustum(bool withNear=true, bool withFar=true)
{
const osg::Vec3d v000(-1.0,-1.0,-1.0);
const osg::Vec3d v010(-1.0,1.0,-1.0);
const osg::Vec3d v001(-1.0,-1.0,1.0);
const osg::Vec3d v011(-1.0,1.0,1.0);
const osg::Vec3d v100(1.0,-1.0,-1.0);
const osg::Vec3d v110(1.0,1.0,-1.0);
const osg::Vec3d v101(1.0,-1.0,1.0);
const osg::Vec3d v111(1.0,1.0,1.0);

_faces.clear();

{   // left plane.
Face& face = createFace();
face.name = "left";
face.plane.set(1.0,0.0,0.0,1.0);
face.vertices.push_back(v000);
face.vertices.push_back(v001);
face.vertices.push_back(v011);
face.vertices.push_back(v010);
}

{   // right plane.
Face& face = createFace();
face.name = "right";
face.plane.set(-1.0,0.0,0.0,1.0);
face.vertices.push_back(v100);
face.vertices.push_back(v110);
face.vertices.push_back(v111);
face.vertices.push_back(v101);
}

{   // bottom plane.
Face& face = createFace();
face.name = "bottom";
face.plane.set(0.0,1.0,0.0,1.0);
face.vertices.push_back(v000);
face.vertices.push_back(v100);
face.vertices.push_back(v101);
face.vertices.push_back(v001);
}

{   // top plane.
Face& face = createFace();
face.name = "top";
face.plane.set(0.0,-1.0,0.0,1.0);
face.vertices.push_back(v111);
face.vertices.push_back(v011);
face.vertices.push_back(v010);
face.vertices.push_back(v110);
}

if (withNear)
{   // near plane
Face& face = createFace();
face.name = "near";
face.plane.set(0.0,0.0,1.0,1.0);
face.vertices.push_back(v000);
face.vertices.push_back(v010);
face.vertices.push_back(v110);
face.vertices.push_back(v100);
}

if (withFar)
{   // far plane
Face& face = createFace();
face.nam

Re: [osg-users] osgShadow one shot shadow map

[Wojciech Lewandowski]

Hi,

I developed two methods to compute convex hull of visible scene portion:

A: one based on cull stage
I scan render leaves generated by main camera cull traversal and compute 
minimal convex hull around them

B: second based on draw stage
I prerender the scene to small resolution depth texture (64x64) and 
compute convex hull around valid points stored in this texture

then I compute intersection of this convex scene hull with main camera 
frustum and coarse light (shadow) camera frustum. This produces my minimal 
scene bound polytope which I then use to further narrow shadow camera 
projection.

Prerender based approach is somewhat radical but produces really good 
results with my LispSM. Cull based approach is more precise but works well 
only with fairly small drawables (ie when their bounding boxes are much 
smaller than frustum).

I don't know how useful it may be for you. We make flight sim renderer so my 
work was mostly oriented towards elipsoid based large terrain / directional 
light case. But if you do something similar then we may exchange some 
experiences.

I do plan on contributing some of this work with LispSM but will need to 
finish it first ;-).

Cheers,
Wojtek

- Original Message - 
From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "OpenSceneGraph Users" 

Sent: Tuesday, February 12, 2008 2:54 PM
Subject: Re: [osg-users] osgShadow one shot shadow map


> Hello Wojtek,
>
>> Actually most of the time was spent
>> on algorithms finding minimal shadowed scene bounds under OSG. It was a 
>> key
>> to good shadow mapping results.
>
> Well, that's what I'm working on right now too! If you are planning on 
> contributing this sometime, would it be possible for you to help me with 
> this? It would save me lots of time.
>
> I have something that works pretty well, but only if the camera 
> manipulator is a Trackball Manipulator (for the getCenter() method) - I 
> essentially get the smallest of either the scene bound or the camera view 
> volume.
>
> If I could have something that works well in more cases, it would be very 
> useful.
>
> Thanks in advance,
>
> J-S
> -- 
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>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

Re: [osg-users] osgShadow one shot shadow map

[Wojciech Lewandowski]

Hi,

> will this implementation be avaible for the osg community, new shadow 
> implementation ?


Yes. Thats my intent. I derived it from osgShadow::ShadowMap - it could be 
integrated with osgShadow.  But I had to create a bunch of supporting classes, 
so after all, the code may not be clean enough to place it directly as new 
shadow algorithm in osgShadow lib. 
I will probably first create some sort of example and if Robert and community 
gives it green light I may repack it into osgShadow::LispSM. 

But don't expect this too soon ;-(. I won't have time to this in this month. I 
will try to submit it around the end of March.

Wojtek
  - Original Message - 
  From: Adrian Egli OpenSceneGraph (3D) 
  To: [EMAIL PROTECTED] ; OpenSceneGraph Users 
  Sent: Tuesday, February 12, 2008 8:40 AM
  Subject: Re: [osg-users] osgShadow one shot shadow map


  Hi 
  will this implementation be avaible for the osg community, new shadow 
implementation ?


  2008/2/11, Wojciech Lewandowski <[EMAIL PROTECTED]>:
I implemented Trapezoidal and LiSpPSM. Actually most of the time was spent
on algorithms finding minimal shadowed scene bounds under OSG. It was a key
to good shadow mapping results. I will try to contribute LispSM when I am
done with all the issues.

Cheers,
Wojtek


-Original Message-
From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 9:29 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] osgShadow one shot shadow map


Hello Wojtek,

> I have spent couple months banging my head against the wall, implementing
> perspective shadow mapping algortihms and that is the only rason I know
how
> osgShadow::ShadowMap works ;-).

Hehehe, I suspect I am on the same road, so only a few months to go if
your assessment is correct :-)

Any chance you would contribute the PSM implementation? It would make
one more on the list. :-)

Thanks,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
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




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

Re: [osg-users] osgShadow one shot shadow map

[Wojciech Lewandowski]

I implemented Trapezoidal and LiSpPSM. Actually most of the time was spent
on algorithms finding minimal shadowed scene bounds under OSG. It was a key
to good shadow mapping results. I will try to contribute LispSM when I am
done with all the issues.

Cheers,
Wojtek


-Original Message-
From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 9:29 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] osgShadow one shot shadow map


Hello Wojtek,

> I have spent couple months banging my head against the wall, implementing
> perspective shadow mapping algortihms and that is the only rason I know
how
> osgShadow::ShadowMap works ;-).

Hehehe, I suspect I am on the same road, so only a few months to go if
your assessment is correct :-)

Any chance you would contribute the PSM implementation? It would make
one more on the list. :-)

Thanks,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
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

Re: [osg-users] osgShadow one shot shadow map

[Wojciech Lewandowski]

I have spent couple months banging my head against the wall, implementing
perspective shadow mapping algortihms and that is the only rason I know how
osgShadow::ShadowMap works ;-).

Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jean-Sebastien Guay
Sent: Monday, February 11, 2008 7:16 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgShadow one shot shadow map


Hello Wojtek,

> ShadowMap::cull invokes culls traversal for both main camera
> (ShadowReceiving) graph  & shadow camera (ShadowCasting) graphs. So if you
> block whole cull on ShadowMap level - it won't draw the scene as well. The
> trick is to block only the portion that culls ShadowCasting graph.

Cool, thanks for clearing that up! I didn't know, haven't looked at the
code long enough it seems :-)

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
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] osgShadow one shot shadow map

[Wojciech Lewandowski]

Hi,

ShadowMap::cull invokes culls traversal for both main camera 
(ShadowReceiving) graph  & shadow camera (ShadowCasting) graphs. So if you 
block whole cull on ShadowMap level - it won't draw the scene as well. The 
trick is to block only the portion that culls ShadowCasting graph.

See the osgShadow::ShadowMap::cull method (src/ osgShadow / ShadowMap.cpp)

Line 330:  _shadowedScene->osg::Group::traverse(cv);
Thats the line where Scene traversal is invoked

&

Line 469 : _camera->accept(cv);
Thats the line which calls cull traversal on Shadow Map camera.


Cheers,
Wojtek Lewandowski


- Original Message - 
From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, February 11, 2008 4:20 PM
Subject: Re: [osg-users] osgShadow one shot shadow map


> Hello Sebastian,
>
>> I'm quite confused regarding the osgShadow implementation.
>> My scene and my light-positions are static. My idea was to capture the
>> shadow-map only once
>> and apply it consecutively in all frames. I'm a bit lost where to start.
>> Neither update nor cull seems to be the right place.
>> Any hints?
>
> As you have seen, it was not designed to do that. It's designed to
> recalculate the shadow map each frame. I guess you could add a boolean
> to it to say that it has been calculated, and then not redo it again...
> Maybe just something like:
>
> class myShadowMap : public osgShadow::ShadowMap
> {
> public:
> myShadowMap() : _done(false) {}
>
> virtual void update(osg::NodeVisitor& nv)
> {
> if (!_done)
> osgShadow::ShadowMap::update(nv);
> }
>
> virtual void cull(osgUtil::CullVisitor& cv)
> {
> if (!_done)
> {
> osgShadow::ShadowMap::cull(cv);
> _done = true;
> }
> }
>
> private:
> bool _done;
> };
>
> Note that I didn't try this, but it might give you something to start
> with? Let us know how it goes.
>
> Hope this helps,
>
> J-S
> -- 
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>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] Vector/Model data inserts in VPB/OSGDEM terrain.Possible ?

[Wojciech Lewandowski]

Thanks,

I am looking for some tool that will cut portions of OSGDEM/VPB terrain tile
meshes for airport models as a terrain postprocessing step.

I thought TDS is aimed at run time terrain modifications - like making
explosion craters or digging trenches. But after brief look at TDS
doumentation I see it may be relevant... I will further check it. Thank You.

Cheers,
Wojtek


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Brian
Sent: Friday, February 08, 2008 6:28 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Vector/Model data inserts in VPB/OSGDEM
terrain.Possible ?


  Have you looked at osgTDS
  http://www.andesengineering.com/Projects/TDS/

  Brian


  On Feb 8, 2008 6:16 AM, Wojciech Lewandowski <[EMAIL PROTECTED]>
wrote:

Hi everyone,

Does VPB (or OSGDEM) allow to make holes in the terrain mesh for high
fidelity vector models ?
If not, maybe you can offer some suggestions how to do it ?

Thanks in advance,
Wojtek Lewandowski






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



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

Re: [osg-users] Vector/Model data inserts in VPB/OSGDEM terrain. Possible ?

[Wojciech Lewandowski]

Hi,

> Can you please explain more precisely what you intent to do by "making
> holes" in the mesh for "hight fidelity vector models" ?
> Do you want to project a lineset ( aka vector model ) onto your mesh ?

Well... yes, but I don't seek a solution for projecting the model on terrain 
surface and rasterizing it into textures.
What I would like to have is a solution which will cuts underlying terrain 
mesh and removes triangles (whole or portions) below the model.

Thats usual flight simulation task. We have hight detail areas/airport 
models and we want them drawn over terrain without Z-fighting. Typical 
solution  is to remove portions of terrain mesh that lie under our vector 
model.

I asked because I noticed that there was commented out option in OSGDEM for 
loading model data, and noticed that VPB repostiory has some undocumented 
vpbExtrude example so I thought that maybe something like this was already 
done.

Cheers,
Wojtek Lewandowski

> Wojciech Lewandowski a écrit :
>> Hi everyone,
>>
>> Does VPB (or OSGDEM) allow to make holes in the terrain mesh for high
>> fidelity vector models ?
>> If not, maybe you can offer some suggestions how to do it ?
>>
>> Thanks in advance,
>> Wojtek Lewandowski
>>
>>
>>
>>
>>
>> 
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> -- 
> Remy Deslignes
>
> Ingenieur Developement / Software Engineer
>
> Tel: +33 (0)1.53.90.11.19
>
> ===
> Silicon Worlds S.A.
> 224, rue Saint Denis
> 75002 Paris  France
> Tel: +33 (0)1.53.90.11.11
> Fax: +33 (0)1.53.90.11.12
> http://www.silicon-worlds.fr
> ===
>
>
> ___
> 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] Vector/Model data inserts in VPB/OSGDEM terrain. Possible ?

[Wojciech Lewandowski]

Hi everyone, 

Does VPB (or OSGDEM) allow to make holes in the terrain mesh for high fidelity 
vector models ? 
If not, maybe you can offer some suggestions how to do it ?

Thanks in advance,
Wojtek Lewandowski




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

Re: [osg-users] Scene prerender for selecting parameters needed for cull and final screen render

[Wojciech Lewandowski]

Hi Robert,

Well maybe I wrote too lengthy explanation for what I am after. I guess it
was bit confusing.
Maybe question should be: is this possible to nest both CULL/DRAW stages for
some prerender camera into my Shadow Map CULL method ? Thats basically what
I would like to do. I know I can insert some aditional CULL traversal of
some subgraph. The question is if I can also DRAW it ? I just want to
prerender a scene to a depth texture/image and analyze it before further
culling (and rendering) the rest of the shadow casting scene ? I am afraid
that OSG does not allow to perform draw stages untill all cameras cull
stages complete. Or does it ?

Cheers,
Wojtek

PS: I learned some tricks looking at OverlayNode and even use your
CustomPolytope. But I did not notice nested DRAW stage there. I think I did
good job on computing minimal bounds based on scene traversal and visible
drawable bounding boxes. I am actually scanning render bins after cull
traversal and build bounds around generated render leaves. Then I find
intersection with camera frustum and light frustum. CustomPolytope is good
for that. This method produces small shadow scene bounds when render leaves
(drawables) are much smaller than frustum volume. Unfortuantely my drawables
are quite huge, although also quite sparse. I could try to split them into
smaller chunks, but I don't  expect I would be able to "shatter" every
database I get. So I am looking for some worakround for the worst case.
Prerendering and analyzing scene depths is such workaround. I am also trying
to do this because many Shadow Maping papers suggest such aproach for
minimal shadow bounds computation. So out of curiostiy  I just want to do
this to get some comparison with scene traversal methods.

-Original Message-
From: Robert Osfield [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 26, 2008 9:06 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] Scene prerender for selecting parameters needed for
cull and final screen render


Hi Wojciech,

I understand where you are coming from, unfortunately its a pretty
complex topic and one that really needs you to submerge yourself in it
to be able to really understand the issues - it really isn't a topic
that you can dip you toe in and out of.  Right now I have another
large task that it is pretty well consuming almost all my time and
intellectual capacity, I'm afraid there is little left for diving into
other meaty topics.

The best I can do is point you in the direction of work I've done in
the past that comes closest to view dependant render texture work -
and that's in the form of the OverlayNode's
VIEW_DEPENDENT_PERSPECTIVE_OVERLAY.  The code in
src/osgSim/OverlayNode.cpp does do some scene traversal to compute a
right bound between the view frustum and the scene.  The code isn't
yet producing great results all the time though so it looks like their
or corner cases I haven't accounted for yet, or just some bugs lurking
that I have found.

As I'm so short on time I can't really dive any deeper than this, good luck,

Robert.

On Jan 26, 2008 12:37 PM, Wojciech Lewandowski <[EMAIL PROTECTED]>
wrote:
> Hi Robert,
>
> I am struggling with building decent ShadowMapping approach for flight sim
> application. Due to performance requirements I am hesistant to use
multipass
> PSSM and I am trying to implement (one extra pass only) some kind of
> perspective shadow mapping derived algorithm. I went through Trapezoidal,
> Smallest Bounds, LisPSM. Effective computation of minimal shadow scene
> bounds  + LisPSM gave me fairly good results. But this apprach fails when
I
> have badly conditioned database. Few huge drawables that are spread over
> whole terrain kill effectivness of minimal bounds computation. They have
> such big bounds that minimal bound computaion simply does not help at all,
> and I end up using camera frustum as shadow bounds.
>
> So now I am contemplating addition of one prerender pass (ie second extra
> pass ;-( ). This pass would be used for computation of minimal bounds of
> visible scene portion based on an depths rendered to texture. Problem is I
> would like to make this depth analysis pass before actual ShadowMap, Scene
> camera and TexGen setups are done during cull phase. In other words I
would
> like to have the chance to do scene prerender culling and rendering before
> final scene culling and rendering. Is this possible ? Any suggestion for
OSG
> examples to browse ?
>
> Currently my ShadowMap algorithm looks like this (its exactly the same
> control flow as in osgShadow::ShadowMap)
>
> My Shadow Map technique Cull
> Cull Scene Receiving Shadows for final Screen output
render stage
> Find Light source casting shadows
> Compute Bounds of Scene Receiving Shadow v

[osg-users] Scene prerender for selecting parameters needed for cull and final screen render

[Wojciech Lewandowski]

Hi Robert,

I am struggling with building decent ShadowMapping approach for flight sim
application. Due to performance requirements I am hesistant to use multipass
PSSM and I am trying to implement (one extra pass only) some kind of
perspective shadow mapping derived algorithm. I went through Trapezoidal,
Smallest Bounds, LisPSM. Effective computation of minimal shadow scene
bounds  + LisPSM gave me fairly good results. But this apprach fails when I
have badly conditioned database. Few huge drawables that are spread over
whole terrain kill effectivness of minimal bounds computation. They have
such big bounds that minimal bound computaion simply does not help at all,
and I end up using camera frustum as shadow bounds.

So now I am contemplating addition of one prerender pass (ie second extra
pass ;-( ). This pass would be used for computation of minimal bounds of
visible scene portion based on an depths rendered to texture. Problem is I
would like to make this depth analysis pass before actual ShadowMap, Scene
camera and TexGen setups are done during cull phase. In other words I would
like to have the chance to do scene prerender culling and rendering before
final scene culling and rendering. Is this possible ? Any suggestion for OSG
examples to browse ?

Currently my ShadowMap algorithm looks like this (its exactly the same
control flow as in osgShadow::ShadowMap)

My Shadow Map technique Cull
Cull Scene Receiving Shadows for final Screen output render 
stage
Find Light source casting shadows
Compute Bounds of Scene Receiving Shadow visible portion
Setup Shadow Map camera View and Perspective matrices
( based on Scene Bounds and Light source )

Cull Scene Casting Shadows for Shadow Map prerender stage
Add shadow coordinates TexGen to final Screen output render 
stage
End My Shadow Map technique Cull

Rendering of RenderStages is executed in following order
Shadow Map prerender stage
Final Screen render stage


What I would like to achieve looks like this

My next Shadow Map technique Cull
Cull Scene Receiving Shadows for final Screen output
Find Light source casting shadows

Depth Analysis prerender pass
Cull & Render scene producing Depth texture
( view and projection are the same as in Scene 
Receiving Shadow pass,
target texture resolution 8x-4x smaller than screen)

Compute Bounds of Scene Receiving Shadows based on image 
produced in Depth
Analysis pass
Setup Shadow Map camera View and Perspective matrices
Cull Scene Casting Shadows for Shadow Map prerender
Setup shadow coordinates TexGen for final Screen output
End My next Shadow Map technique Cull

Rendering of RenderStages is executed in following order
Shadow Map prerender stage
Final Screen render stage


Cheers,
Wojtek

P.S. When I sort all the issues I could contribute some of this work
(Minimal Bounds Shadow map, LisPSM) to osgShadow portfolio if you are
interested.




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

Re: [osg-users] 64bit question

[Wojciech Lewandowski]

Hi,

We have one 64bit setup in our company. It was not used for few months, but
in the summer we we built couple osg releases using it. In that time, it was
just a matter of selecting target 64 bit VS environment, when Cmake was run
for the very first time in OSG directory. This selection is also available
as a result of Cmake "clear cache" command.  Clearing cache will bring
target selection dialog again. Look carefully - you should be able to find
64 bit VS 2005 target. Maybe new cmake has 64 bit 2008 as well

We ended up using VS 2005 Standard for 64 bit. VS 2005 Express does not
offer 64 bit builds out of the box. Cmake won't also generate 64bit solution
for VS 2005 Express. 64 bit in VS Express is theoretically possible with
some hacking using Platform SDK compiler. But I attempted this path and give
up due to some strange issues with compilation of stl and some predefined
macros. Apparently Sdk compiler has to use Platform SDK headers and libs. It
did not work well with Stl from VS 2005 express. So we ended up buing the
cheapest commercial VS relases that alllowed to do this.

Cheers,
Wojtek Lewandowski

  -Original Message-
  From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gordon
Tomlinson
  Sent: Thursday, January 24, 2008 5:37 AM
  To: osg-users@lists.openscenegraph.org
  Subject: [osg-users] 64bit question


  Hi

  Ok possibly stupid question, we have tasked one of our engineers to start
the process of finally upgrading to OSG 2.3.x from 1.2. One of the things we
do need is both is 32bit and x64 on windows, the Gent we have getting things
upto speed cannot seem to find any thing to do 64 bit builds in the Cmake
configs etc. ( Cmake is all new to him and I'm about the same )

  I'm sort of asking this question blind as I'm not in a position to check
things ( sorry), so as said possibly dumb/stupid question,

  But what do we need to do to get Cmake etc to throw out 64bit solutions
for windozes as well as 32bit



  thanks

  G.

  __
  Gordon Tomlinson

  Email   : [EMAIL PROTECTED]
  YIM/AIM : gordon3dBrit
  MSN IM  : [EMAIL PROTECTED]
  Website : www.vis-sim.com www.gordontomlinson.com

  __


  "Self defence is not a function of learning tricks
  but is a function of how quickly and intensely one
  can arouse one's instinct for survival"
  -Master Tambo Tetsura

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

Re: [osg-users] Shadows with OpenProducer - is it possible?

[Wojciech Lewandowski]

I haven't suggested that it won't work with osgProducer. I said that your
poroblem ie ShadowMap init not being called by Update Traversal may be
caused by some differences beetween osgViewer and osgProducer viewers. I
would not go that far to say that osgProducer is to blame. But osgShadow
example uses osgViewer::Viewer. Can you replace your problem using this
example as foundation ? If yes, send me this modified code and will che
whats going on. On the other hand I won't be able to help with
osgProducer::Viewer as I don't have it installed and dropped my Producer
experiences into oblivion.

Cheers,
Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of DKa
Sent: Thursday, January 17, 2008 2:18 PM
To: OpenSceneGraph Users
Subject: [osg-users] Shadows with OpenProducer - is it possible?


Wojtek Lewandowski just pointed out to me that the osg
implementation of the OpenProducer might not work
properly with the shadow implementation of OSG. Is
this correct? Do I have to migrate my application to
the osg viewer?

Thanks,
D.


  __
__
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

___
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] Adding shadow to an existing scenegraph

[Wojciech Lewandowski]

For tests, you may derive your ShadowMap from osgShadow::ShadowMap, override
init and cull methods. In this way you will be able to check if init was
called. Of course I have not tested it but the code should look more or less
like this:

#include 

class MyShadowMap: public osgShadow::ShadowMap {
public :
/** initialize the ShadowedScene and local cached data structures.*/
virtual void init()
{
assert( getShadowedScene() ); // ShadowMap::init does nothing 
if this not
set

osgShadow::ShadowMap::init();

// now check if all vital resources were created
assert( osgShadow::ShadowMap::_stateset );
assert( osgShadow::ShadowMap::_camera );
assert( osgShadow::ShadowMap::_texture );
}

/** run the cull traversal of the ShadowedScene and set up the
rendering for this ShadowTechnique.*/
virtual void cull( osgUtil::CullVisitor& cv )
{
// check if all vital resources were created by init
assert( osgShadow::ShadowMap::_stateset );
assert( osgShadow::ShadowMap::_camera );
assert( osgShadow::ShadowMap::_texture );

osgShadow::ShadowMap::cull( cv );
}
};


You may additionally call ShadowedScene->dirty() method. But I doubt it
helps, dirty flag is set anyway on creation, its generally used for
refreshing shadow params. What type of viewer uses your App ? J-S Guay
recently observed some issues with initialization of Shaders in ShadowMap
with CompositeViewer. Maybe this is related somehow.

Cheers,
Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of DKa
Sent: Wednesday, January 16, 2008 11:17 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Adding shadow to an existing scenegraph


> If crash happens,  its probably in some function on
> Stack called as result
> of from ShadowMap::cull. I bet getDataVariance is
> called with stateset being
> NULL ? Right ?

Hi, sorry for the late feedback on your new
suggestions. I pretty much do it like in your code
(sm->init after attaching the shadow technique). Still
you're right that the stateset being null is the
problem and this is still not solved.

Something must go wrong in the initialization. I am
building against the library so I cannot put a
breakpoint into the OSG-Code for the init function.

Previously I did not set the texture size for the
shadow map. But it seems this is the only difference
to the stuff you do in order to initialize and set
everything for the shadow.

Cheers,
D.


  __
__
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile.  Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

___
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::ShadowMap and _receivesShadowTraversalMask

[Wojciech Lewandowski]

Hi,

I believe that receivesShadowTraversalMask is used somewhere in
ShadowedScene code to initialize NodeMask for traversals. Its common code
for all techniques. Check ShadowedScene or ShadowedTechnique. Its must be
there.

Cheers,
Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jean-Sebastien Guay
Sent: Monday, January 14, 2008 9:14 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgShadow::ShadowMap and _receivesShadowTraversalMask


Hello,

I can't find any reference to _receivesShadowTraversalMask in
osgShadow/ShadowMap.cpp... Is this supposed to have an effect? We would like
it
to work as well as _castsShadowTraversalMask.

A workaround would be to add the node to a different subgraph than the
shadowedScene, but is there another way?

Thanks,

J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
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] Adding shadow to an existing scenegraph

[Wojciech Lewandowski]

Hi again,

Sorry I was in hurry and I made many errors in my last post it was almost 
unreadable. I repeat it with at least few of them fixed ;-)

You won't find osgShadow::ShadowMap::init it on a Stack Trace. You have to 
place breakpoint into it. You do this to make sure its actually NOT CALLED 
before osgShadow::ShadowMap::cull gets called. If init is not called it 
means that unitialized variables are the reason of your problem.

If crash happens,  its probably in some function on Stack called as result 
of from ShadowMap::cull. I bet getDataVariance is called with stateset being 
NULL ? Right ?

Did you call osgShadow::ShadowMap::init after or before attaching it to
ShadowedScene (_shadowedScene->setShadowTechnique( sm )) ? It should be done 
after. If done before init will not work.

Below is excerpt from my code. In this example I replace pScene group with 
ShadowedScene. pScene is a child of pSceneRoot.

_shadowedScene = new osgShadow::ShadowedScene;

_shadowedScene->addChild( pScene );

osg::StateSet * stateset = pScene->getStateSet();

pSceneRoot->removeChild( pScene );

pSceneRoot->addChild( _shadowedScene.get() );

_shadowedScene->setReceivesShadowTraversalMask( ~0 );

_shadowedScene->setCastsShadowTraversalMask( ~0 );

{

osgShadow::ShadowMap * sm = new osgShadow::ShadowMap;

_shadowedScene->setShadowTechnique( sm );

if( lightSource )

sm->setLight( lightSource );

sm->setTextureSize( osg::Vec2s( RESOLUTION,RESOLUTION ) );

sm->init();

}

If this does not help, I give up ;-(

Cheers,
Wojtek 


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

Re: [osg-users] Adding shadow to an existing scenegraph

[Wojciech Lewandowski]

Hi,

You would need to put breakpoint into osgShadow::ShadowMap::init. When it 
crashes its probably due to not calling init. So you won't find it on Stack 
trace.  If crash happens you its probably some function under 
ShadowMap::cull.  getDataVariance is called with _stateset being NULL ?

Did you call osgShadow::ShadowMap::init after or before attching it to 
ShadowedScene ? It should be done after. If done before init will not work.

Below is excerpt from my code. In this example I pScene group with 
ShadowedScene. pScene is a child of pSceneRoot.


 _shadowedScene = new osgShadow::ShadowedScene;
_shadowedScene->addChild( pScene );

osg::StateSet * stateset = pScene->getStateSet();

pSceneRoot->removeChild( pScene );

pSceneRoot->addChild( _shadowedScene.get() );

_shadowedScene->setReceivesShadowTraversalMask( ~0 );

_shadowedScene->setCastsShadowTraversalMask( ~0 );

 osgShadow::ShadowMap * sm = new osgShadow::ShadowMap;

 _shadowedScene->setShadowTechnique( sm );

 if( lightSource )

sm->setLight( lightSource );

sm->setTextureSize( osg::Vec2s( RESOLUTION,RESOLUTION ) );

sm->init();



Cheers,
Wojtek
- Original Message - 
From: "DKa" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Friday, January 11, 2008 5:57 PM
Subject: Re: [osg-users] Adding shadow to an existing scenegraph


>> Init should be called in UpdateTraversal but if for
>> some reason you created
>> your ShadowedScene after UpdateTraversal but before
>> CullTraversal : crash
>> may happen.
>
> Thanks a lot for these pointers. I still get the same
> error though after adding sm->init() or
> sm->computeDataVariance() or both. If you have already
> succeeded with such an approach maybe my problem lies
> elsewhere in the program.
>
> Lights are added under the scene root and associated
> with the scene root's stateset.
>
> By the way, there is no call to init() in the call
> stack of the debugger. The crash appears while culling
> tries to  get the DataVariance...
>
> Anymore ideas regarding this problem? Maybe a short
> working sample code (apart from the osgshadow
> example).
>
> Thanks,
> D.
>
>
>
> 
> 
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now. 
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
> ___
> 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] StateSet bin mode

[Wojciech Lewandowski]

Hi,

>>o OVERRIDE is effectively an instruction to ignore an
>> attempts of StateSet below it to set RenderBin's.
>
> Understood. Can you give me an example of why someone would want to do 
> this?

Pardon me, to step into this discussion but I think I have a situation where 
renderBin override could become useful. I hope Robert will verify this as 
reasonable scenario.

I think for performance reasons it could be useful to turn OVERRIDE to 
render all geometry into one unsorted bin for faster ShadowMap generation. 
ShadowMap contains only depths so using render bins for transparency sorting 
may not change anything.  Does it make sense ?

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] Adding shadow to an existing scenegraph

[Wojciech Lewandowski]

Hi,

I asked similar question some time ago. In the meantime I figured it out 
myself. You don't need to add light to shadowed scene nor it does not need 
to be present in fixed location in viewer scene hierarchy. I assume of 
course that you have at lest one light somewhere in hierarchy. In case of 
many lights it would be helpful if you point out the Light source that must 
be used to generate shadows. See ShadowMap::setLight function.

 I suspect that crash you observe is due to unitialized ShadowMap technique. 
If you can use debuger, check if osgShadow::ShadowMap::init() gets called 
before the crash. If not you may try to call it by yourself as last line of 
your example.
Try adding "sm->init();" line.

Init should be called in UpdateTraversal but if for some reason you created 
your ShadowedScene after UpdateTraversal but before CullTraversal : crash 
may happen.

Cheers,
Wojtek Lewandowski

- Original Message - 
From: "Basic Soft" <[EMAIL PROTECTED]>
To: 
Sent: Friday, January 11, 2008 3:38 PM
Subject: [osg-users] Adding shadow to an existing scenegraph


>I want to add shadowing to a complex already loaded
> scene in a larger framework context. Possibly
> shadowing should only be activated for subgraphs.
>
> So far I'm trying to add a osgShadow::ShadowedScene to
> the scenegraph which crashes on me while the
> scenegraph is traversed. Error message is as follows:
> osg25-osgd.dll!osg::Object::getDataVariance()
>
> Do I need to register the ShadowedScene with the
> Viewer or the associated Camera? Must there be a light
> present in the ShadowedScene?
>
> Any help greatly appreciated here.
>
> Here is a code snippet:
>
> osg::ref_ptr shadowedScene =
> new osgShadow::ShadowedScene;
>
> shadowedScene->setReceivesShadowTraversalMask(ReceivesShadowTraversalMask);
> shadowedScene->setCastsShadowTraversalMask(CastsShadowTraversalMask);
>
> osg::ref_ptr sm = new
> osgShadow::ShadowMap;
> shadowedScene->setShadowTechnique(sm.get());
>
> selectedNode->setNodeMask(CastsShadowTraversalMask);
> selectedNode->setNodeMask(ReceivesShadowTraversalMask);
> shadowedScene->addChild(selectedNode);
>
> shadowedScene->addChild(selectedNode);
> root->asGroup()->replaceChild(selectedNode, shadowedScene.get());
>
>
> 
> 
> Be a better friend, newshound, and
> know-it-all with Yahoo! Mobile.  Try it now. 
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
> ___
> 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] INT32 redeifinition with Win32 and VS8 binarypackage

[Wojciech Lewandowski]

Hi, Philip,

FYI: All integral types in Win64 are the same size as they were in Win32. 
Only ptr types got "promoted" to 64 bit. See this article:
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Cheers,
Wojtek Lewandowski


- Original Message - 
From: "Philip Taylor" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Wednesday, January 09, 2008 11:34 PM
Subject: Re: [osg-users] INT32 redeifinition with Win32 and VS8 
binarypackage


> Just an idle thought in passing 
>
> with the advent of 64 bit builds, it may not be such a good idea to mark a
> "long" as a 32 bit quantity since I believe the redmond 64 bit model 
> defines
> long as a 64 bit quantity where as an int is 32 bits. On 32 bit systems, 
> the
> two are the same size and can be freely interchanged. So apply the patch 
> but
> ensure the build is 32 bits only.
>
> Happy New Year
> PhilT
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Somerville, Andrew
> Sent: 09 January 2008 21:43
> To: osg-users@lists.openscenegraph.org
> Subject: [osg-users] INT32 redeifinition with Win32 and VS8 binary
> package
>
>
>
> It appears that the VS8 binary package for osg2.2.0 has a problem in
> one of the 3rd party header files included. (jmorecfg.h)
>
> Compiling against it causes an error regarding redefinition of INT32.
>
> Im not sure if there are any repercussions, but there is a simple fix
> seen in an old patch on the secondlife wiki which protects the define
> with a check against WIN32
>
> https://wiki.secondlife.com/wiki/Patch_jpeglib
> in jmorecfg.h:
>
> #ifndef XMD_H
> typedef long INT32;
> #endif
>
> is changed to:
>
> #if !defined( XMD_H ) && !defined( WIN32 )
> typedef long INT32;
> #endif
>
>
> It also does an #undef on FAR just before it blanks it to remove a
> warning about redifinition.
>
> Im not sure how hard it would be to repackage the current 2.2 VS8
> binary package, but at least it can be fixed for for future Visual
> Studio packages.
>
>Regards,
>Andy
> ___
> 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] VBO

[Wojciech Lewandowski]

> vertex indices lead to the slow path == BAD.
>
> vertex arrays + DrawElelemtsn lead to fast path == GOOD :-)

Thats a relief. I was afraid I will have to fix all my code ;-)

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, January 07, 2008 12:20 PM
Subject: Re: [osg-users] VBO


> On Jan 7, 2008 10:58 AM, Wojciech Lewandowski <[EMAIL PROTECTED]> 
> wrote:
>> I am also very surprised to see that use of index arrays/buffer objects
>> impacts performance. Is this a limitation of OSG or OpenGL ? I always
>> thought that Hardware Vertex Buffer  + Hardware Index Buffer should be 
>> the
>> best performing scenario.
>
> Don't confuse vertex indices supported by osg::Geometry with that of
> indices support by osg::DrawElements* (wrapper of glDrawElements(..).
>
> vertex indices lead to the slow path == BAD.
>
> vertex arrays + DrawElelemtsn lead to fast path == GOOD :-)
>
>
>> I just checked GPU_Programming_Guide on NVidia Developer site and found
>> following excerpt in Chapter 3 General GPU Performance Tips:
>>
>> "
>> ...
>> 3.3 Vertex Shader
>>
>> 3.3.1 Use Indexed Primitive Calls
>>
>> Using indexed primitive calls allows the GPU to take advantage of its
>> post-transform-and-lighting vertex cache. If it sees a vertex it's 
>> already
>> transformed, it doesn't transform it a second time-it simply uses a 
>> cached
>> result.
>> ...
>> "
>>
>> It seems to contradict what Robert said...
>
> No contradication... re-read the various post given and look for the
> distinction between vertices indices and primitive indices.
>
> 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] VBO

[Wojciech Lewandowski]

Hi,

I am also very surprised to see that use of index arrays/buffer objects 
impacts performance. Is this a limitation of OSG or OpenGL ? I always 
thought that Hardware Vertex Buffer  + Hardware Index Buffer should be the 
best performing scenario.

I just checked GPU_Programming_Guide on NVidia Developer site and found 
following excerpt in Chapter 3 General GPU Performance Tips:

"
...
3.3 Vertex Shader

3.3.1 Use Indexed Primitive Calls

Using indexed primitive calls allows the GPU to take advantage of its 
post-transform-and-lighting vertex cache. If it sees a vertex it's already 
transformed, it doesn't transform it a second time-it simply uses a cached 
result.
...
"

It seems to contradict what Robert said...

Cheers,
Wojtek

- Original Message - 
From: "Thibault Genessay" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Monday, January 07, 2008 11:28 AM
Subject: Re: [osg-users] VBO


> Hi all,
>
> I know this is slightly off-topic, but if some of you have 5 minutes
> to waste, please read on :)
> I just take the occasion to ask a question regarding Robert's latest 
> comment:
>
>> So if you want fast paths absolutely never ever ever used vertex
>> indices.   Vertex indices are there in the OSG purely for backwards
>> compatibility and are not something I'd recommend usage today.
>
> Acknowledged. Now, what is the preferred way to render triangle
> strip-based geometries where all strips are parallel and share an edge
> ? Should we duplicate all common vertices ? e.g. I have a 1080 * 31
> patch, rendered as 30 tri strips (basically, it's a 3D plot). I use
> indexed rendering so I have 33480 vertices. Now if I want to switch to
> "fast-path", does it mean I'm going to need 2*1080*30 = 64800 vertices
> ?
> Given the amount of info for each vertex (color, texcoords, ...) this
> seems a pretty big memory impact to me (and if the T&L has to be
> performed again, it can also be a slowdown, can't it ?). I am no
> cutting-edge 3D expert so please forgive my ignorance.
>
> Happy new year to everyone,
>
> Thibault
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 


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

Re: [osg-users] osg in Visual C++ Express Edition 2008

[Wojciech Lewandowski]

>Just because the issue was encountered on Vista doesn't mean it's
>related to Vista. In this case, trying to run CMake 2.4.x with Visual
>Studio 2008 even on XP would have given the same issue, because CMake
>2.4 doesn't recognize VS 2008. You need CMake 2.5. Even on XP.

I 100% agree. Its non OS related - basically VS 2008 vs CMake 2.4 (or 
earlier) issue. I did a check on XP and this problem exists as well. Sorry 
for spreading missinformation earlier.

Cheers, Wojtek



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

Re: [osg-users] osg in Visual C++ Express Edition 2008

[Wojciech Lewandowski]

I have not done it myself so I am not 100 % sure but from what I've heard CMAKE 
simply does not find your VS 2008 installation on standard predefined paths. 
Workaround is to run cmake from VS 2008 command prompt. This is what I've 
heard. If this does not help ask again in new year. My collegues who use 2008 
with OSG will be back I am sure they will know the answer...

Linking apllication built with VS 2008  against VS 2005 or VS 2003 libs is bad 
idea. There will be a conflict between OSG runtime and your program runtime 
libs (crashes and exceptions). So the only option is to get CMAKE work and 
rebuild whole OSG. Other option would be to go back to VS 2005 but I would 
rather wait few days ;-)
Happy New Year,
Wojtek

  
  - Original Message - 
  From: Sashidhar Guntury 
  To: OpenSceneGraph Users 
  Sent: Monday, December 31, 2007 4:01 PM
  Subject: [osg-users] osg in Visual C++ Express Edition 2008


  Hi

 I've been using osg in linux this far. Today I tried installing it in 
windows vista with VC++ express edition 2008. I also downloaded the latest 
cmake from their site and religiously followed the instructions given in the 
wiki, but when I tried to configure it, it says visual studio 8.0 was not 
found. Could anybody please tell me where am I going wrong?

Since the building wasn't working, I downloaded the binaries and 
installed them. But now wierd things keep happening. A very simple code of just 
loading a model and displaying it doesn't seem to work. It gives an error like 
this --> 

 Unhandled exception at 0x00a10017 in CameraControl.exe: 
0xC005: Access violation writing location 0x004205b8.

  I tried both the debug as well the release build, but the same error is 
given. Please help me... :( 

   thanks and happy new year to all the guys at osg :)

  bye
  Sashidhar



--


  ___
  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] Is point in view?

[Wojciech Lewandowski]

Hi,

Projection Matrix converts to post projection clip space. OpenGL uses 
[ -1..1 x -1..1 x -1..1 ] clipping box  (also called unit frustum). All 
objects beyond that range will get clipped as extending beyond visible 
space. In OpenGL clipping Z range is exactly the same as for X and Y 
coordinates.

Window matrix trasforms post projection XY coords to viewport range and Z 
coord  to depth range to get final Window/Zbuffer coordinates. I haven't 
checked it but most likely the method You used does also aditional 
multiplication by Window matirx which produces final screen coords. Both 
methods are good you. Use the one which is more convenient ;-)

Regards,
Wojtek

- Original Message - 
From: "Robert Balfour" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, December 30, 2007 10:10 PM
Subject: Re: [osg-users] Is point in view?


> Wojciech Lewandowski wrote:
>>
>> osg::Vec3 projectedPoint = osg::Vec3( x,y,z ) * camera->getViewMatrix() *
>> camera->getProjectionMatrix();
>> bool pointInFrustum = osg::BoundingBox( -1, -1, -1, 1,1,1 ).contains(
>> projectedPoint );
>>
>
> I actually wound up using sceneview->projectObjectIntoWindow(), which
> likely does the same matrix mult, but seems to return a viewport xy with
> 0,0 in lower left corner.  Then I could just do a 2D viewport limit
> check.
>
> The above code looks like it assumes it would get an x,y,z screen
> location each clamped to -1->1 centered at 0,0,0  - which I guess is
> what you would get just applying the view and proj transforms without
> any viewport adjustment?  I'm not sure what happens to z here.
>
> Thanks.
>
> Bob.
>
>
>>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] Behalf Of Robert
>> Balfour
>> Sent: Saturday, December 29, 2007 11:12 PM
>> To: osg-users@lists.openscenegraph.org
>> Subject: [osg-users] Is point in view?
>>
>> Is there a straight forward method to determine if a ground xyz target
>> point (or geode bbox centerpoint) is currently visible (i.e. within the
>> current view frustrum)?
>>
>> I'm drawing a HUD target line, but don't want to draw it if the target
>> point is not in view.
>>
>> Thanks.
>>
>> Bob.
>> --
>> Robert E. Balfour, Ph.D.
>> Exec. V.P. & CTO,  BALFOUR Technologies LLC
>> 960 South Broadway, Suite 108, Hicksville NY 11801
>> Phone: (516)513-0030  Fax: (516)513-0027  email: [EMAIL PROTECTED]
>> ___
> ___
> 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] Is point in view?

[Wojciech Lewandowski]

osg::Vec3 projectedPoint = osg::Vec3( x,y,z ) * camera->getViewMatrix() *
camera->getProjectionMatrix();
bool pointInFrustum = osg::BoundingBox( -1, -1, -1, 1,1,1 ).contains(
projectedPoint );

Cheers,
Wojtek Lewandowski

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert
Balfour
Sent: Saturday, December 29, 2007 11:12 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Is point in view?


Is there a straight forward method to determine if a ground xyz target
point (or geode bbox centerpoint) is currently visible (i.e. within the
current view frustrum)?

I'm drawing a HUD target line, but don't want to draw it if the target
point is not in view.

Thanks.


Bob.
--
Robert E. Balfour, Ph.D.
Exec. V.P. & CTO,  BALFOUR Technologies LLC
960 South Broadway, Suite 108, Hicksville NY 11801
Phone: (516)513-0030  Fax: (516)513-0027  email: [EMAIL PROTECTED]
___
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] [SPAM] Re: Latest SVN: problems withPluginswithoutManifests

[Wojciech Lewandowski]

Thanks for all this info. Its quite useful what you have found. We have another 
completely non OSG related problem where your observations might help. 
Its particularly interesting that manifest checking is done by runtime DLLs 
itselves -  so everyone can look at the runtime source code and see where their 
problem lies.
 
Thanks again. 
Wojtek

- Original Message - 
  From: Roger James 
  To: 'OpenSceneGraph Users' 
  Sent: Thursday, December 13, 2007 5:51 PM
  Subject: Re: [osg-users] [SPAM] Re: Latest SVN: problems 
withPluginswithoutManifests


  I was slightly wrong in what I said originally. The os does not ignore the 
searching sequence if the dll is already loaded it just does not load the 
module and does not call the dlls entry point with DLL_PROCESS_ATTACH.

   

  Here is the full sequence on LoadLibrary.

   

  An "Activation Context" is basically an in memory copy of relevant bits of a 
manifest either loaded from an embedded resource or in the case of an exe maybe 
an external file.

   

1.. Try to locate the dll file using the current "Activation Context". For 
an application the  current activation context will probably be the one created 
from the applications manifest either embedded in the exe or read from a 
related file. 
2.. If the file is not located using the activation context (dependant 
assembly stuff) then look for it using the normal dll search path. 
3.. Is still not found give an error. 
4.. If found but a module with a matching base file name is already loaded 
just return a handle to the already loaded dll. 
5.. If no matching module loaded then map the dll file into the process 
address space. 
6.. Try and create a new  "Activation Context" using resource ID 2 from the 
new module. 
7.. If this succeeds then try to resolve any static imports using this new 
Activation Context otherwise use the existing one. Perform this whole process 
recursively if any new dlls are loaded at this point. 
8.. Once all static imports have been resolved the call the dlls entry 
point (DLL_PROCESS_ATTACH). 
9.. Only when the dll entry point returns, restore the original "Activation 
Context" and return control to the calling app. 
   

  However there is one important fact that is missing here. Which I had 
forgotten about until I looked again at the osgDB::DynamicLibrary and 
remembered this:

   

  DynamicLibrary* DynamicLibrary::loadLibrary(const std::string& libraryName)

  {

  HANDLE handle = NULL;

  std::string fullLibraryName = osgDB::findLibraryFile(libraryName);

  if (!fullLibraryName.empty()) handle = getLibraryHandle( fullLibraryName 
); // try the lib we have found

  else handle = getLibraryHandle( libraryName ); // havn't found a lib 
ourselves, see if the OS can find it simply from the library name.

   

  That bit that is missing is that LoadLibrary will not search the activation 
context or the search paths if the name supplied to it contains any path 
information even a partial one. So in the above code the first call to 
LoadLibrary may or may not use the searching mechanism depending on what 
findLibraryName returns, but the second call always will!.

   

  Roger

   

   


--

  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages
  Sent: 13 December 2007 15:35
  To: OpenSceneGraph Users
  Subject: Re: [osg-users] [SPAM] Re: Latest SVN: problems with 
PluginswithoutManifests

   

  Hi Wojtek,

  On Dec 13, 2007 4:11 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:

  Roger,

  I totally agree with you that manifests should probably stay in plugins. I 
made my research out of curiosity. 

   

  I may add that indeed this mechanism looks like you described. Its 
interesting though that problem does disappear only if the executable loaded 
MSVCRT DLLs. If they were not loaded by exe but instead loaded later in DLL 
loading cascade - problem still remained. That was the case with our original 
app. Exe was built with static linking. It was loading our aditional DLL 
modules dynamically (through LoadLibrary). These module were using the same 
shared MSVCRT DLL libs and OSG libs as OSG Plugins. So when these modules 
loaded, proper MSVCRT DLLs were loaded as well. But even after loading these 
modules attempts to read some media with osgDB plugins produced error messages. 
  

   

  On a side note, I have problems in understanding why removing manifest from 
plugins could save users time if main libs were still built with manifests 
embeded and thus we sitll got the dependecy. Of course its feasible to build 
some application using former version of OSG and former MSVCRT and later update 
OSG plugins only. But who would do this ? It seems highly rare and unprobable 
in practice. But heck, what do I know ? People do so many strange thing

Re: [osg-users] [SPAM] Re: Latest SVN: problems with PluginswithoutManifests

[Wojciech Lewandowski]

Thank You, Now I have the big picture ;-) 
Wojtek
  - Original Message - 
  From: Serge Lages 
  To: OpenSceneGraph Users 
  Sent: Thursday, December 13, 2007 4:35 PM
  Subject: Re: [osg-users] [SPAM] Re: Latest SVN: problems with 
PluginswithoutManifests


  Hi Wojtek,


  On Dec 13, 2007 4:11 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:

Roger,
I totally agree with you that manifests should probably stay in plugins. I 
made my research out of curiosity. 

I may add that indeed this mechanism looks like you described. Its 
interesting though that problem does disappear only if the executable loaded 
MSVCRT DLLs. If they were not loaded by exe but instead loaded later in DLL 
loading cascade - problem still remained. That was the case with our original 
app. Exe was built with static linking. It was loading our aditional DLL 
modules dynamically (through LoadLibrary). These module were using the same 
shared MSVCRT DLL libs and OSG libs as OSG Plugins. So when these modules 
loaded, proper MSVCRT DLLs were loaded as well. But even after loading these 
modules attempts to read some media with osgDB plugins produced error messages. 
  

On a side note, I have problems in understanding why removing manifest from 
plugins could save users time if main libs were still built with manifests 
embeded and thus we sitll got the dependecy. Of course its feasible to build 
some application using former version of OSG and former MSVCRT and later update 
OSG plugins only. But who would do this ? It seems highly rare and unprobable 
in practice. But heck, what do I know ? People do so many strange things with 
computers these days ;-)


  Removing manifest helps when you want to redistribute an OSG application 
without asking to the users to install the MS redistributable package. Removing 
it from the plugins and not the core dlls is done because the plugins are 
distributed into a separated folder, if you don't remove the manifests, you 
have to put in each folders where dlls are located a copy of the CRT dlls, 
without manifests, you only need to put the CRT dlls into the executable 
folder. 

  Of course it's not a common usage, that's why now the manifests are build by 
default. :)
   
But I suspect that such Plugins in some way would still depend on MSVCRT 
lib which was used to build them. If they would work that would be great, but 
if they would crash no one would be able to find that the reason that was 
incompatibilty in runtime libs (back to the DLL hell ;-).


Regards,
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] [SPAM] Re: Latest SVN: problems with Pluginswithout Manifests

[Wojciech Lewandowski]

Roger,
I totally agree with you that manifests should probably stay in plugins. I made 
my research out of curiosity. 

I may add that indeed this mechanism looks like you described. Its interesting 
though that problem does disappear only if the executable loaded MSVCRT DLLs. 
If they were not loaded by exe but instead loaded later in DLL loading cascade 
- problem still remained. That was the case with our original app. Exe was 
built with static linking. It was loading our aditional DLL modules dynamically 
(through LoadLibrary). These module were using the same shared MSVCRT DLL libs 
and OSG libs as OSG Plugins. So when these modules loaded, proper MSVCRT DLLs 
were loaded as well. But even after loading these modules attempts to read some 
media with osgDB plugins produced error messages.   

On a side note, I have problems in understanding why removing manifest from 
plugins could save users time if main libs were still built with manifests 
embeded and thus we sitll got the dependecy. Of course its feasible to build 
some application using former version of OSG and former MSVCRT and later update 
OSG plugins only. But who would do this ? It seems highly rare and unprobable 
in practice. But heck, what do I know ? People do so many strange things with 
computers these days ;-)

But I suspect that such Plugins in some way would still depend on MSVCRT lib 
which was used to build them. If they would work that would be great, but if 
they would crash no one would be able to find that the reason that was 
incompatibilty in runtime libs (back to the DLL hell ;-).


Regards,
Wojtek
 
 - Original Message - 
  From: Roger James 
  To: 'OpenSceneGraph Users' 
  Sent: Thursday, December 13, 2007 2:41 PM
  Subject: Re: [osg-users] [SPAM] Re: Latest SVN: problems with Pluginswithout 
Manifests


  Wojtek,

   

  I think the problem you are hitting here is caused by the windows library 
loading code checking if a module (dll, etc) which has the same base file name 
(i.e. name excluding any path components) as the module to be loaded has 
already been loaded into the process address space. If a matching module is 
found then all the manifest, dll redirection, and dll search path stuff is 
ignored and a handle to the already loaded module is returned.

   

  All the VC8 onwards c runtime dlls have a routine in their initialisation 
code called __check_manifest. This routine attempts to check whether the dll 
has been loaded via the assembly/manifest mechanism and spits out the R6034 
error if it thinks is has not. If you have the c runtime sources (a full 
install of visual studio) you can put a break point on this function and step 
into it to see what is happening. This routine is why trying to load the c 
runtime dlls outside the manifest mechanism is usually a bad idea.

   

  Roger

   


--

  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech 
Lewandowski
  Sent: 12 December 2007 14:42
  To: OpenSceneGraph Users
  Subject: [SPAM] Re: [osg-users] Latest SVN: problems with Plugins without 
Manifests

   

  Serge,

   

  I have created a test solution for my case. It is very simple Exec which 
dynamically loads DLL where osgViewer is initalized nad run. It allowed me to 
further narrow the scenario and see where actual problem appears. See attached 
example. In this example Release version will run but Debug version will crash.

   

  Release version works because executable uses shared Mutlithreded DLL CRT but 
Debug version does not because it was built with Mutlithreaded Debug CRT which 
is different than OSG plugin build model.

   

  It seems that everything is ok when both application, dynamicaly loaded 
modules, OSG libs and plugins are build using the same code generation model 
which implies use of the same runtime libs. In our problematic case Apllication 
was actually built with multithreaded static CRT. But modules were built with 
Multithread DLL model.

   

  In our app I could freely change all projects to Multithread DLL / 
Multithread Debug DLL and then problem disappeared.

   

  On the other hand it is perfectly correct approach to build app using one 
environment and dynamic modules/plugins using other environment. This is how 
many plugin sdks work for various comercial apllications.

   

  I wonder what will happen when OSG is built using static linking.

   

  Regards,

  Wojtek Lewandowski

   

  - Original Message - 

From: Wojciech Lewandowski 

To: OpenSceneGraph Users 

Sent: Tuesday, December 11, 2007 4:39 PM

Subject: Re: [osg-users] Latest SVN: problems with Plugins without Manifests

 

Hi, Serge,

 

Looks like I used the same runtime DLLs and manifest files. Manifests were 
taken from WinSxS and renamed to Microsoft.VC80.CRT.manifest and 
Microsoft.VC80.DebugCRT.manifest. 

 

Its really puzzling th

Re: [osg-users] Latest SVN: problems with Plugins without Manifests

[Wojciech Lewandowski]

Hi, Serge,

Looks like I used the same runtime DLLs and manifest files. Manifests were 
taken from WinSxS and renamed to Microsoft.VC80.CRT.manifest and 
Microsoft.VC80.DebugCRT.manifest. 

Its really puzzling that plugins without manifests work when OSG libs are 
linked with executables but it does not work for our App when they are linked 
with dynamically loaded DLLs.

I saw your recent submission where you reverted Cmake generation for manifest 
linking - before Robert puts them into SVN I actived manifest linking in my OSG 
solution. I gave up. Don't have time for this struggle now. Maybe will get back 
to this later. 
On many Microsoft manifest related documentation pages they state that bulids 
without manifests are not supported so I wouldn't expect that we may be able to 
resolve this issue.

Thanks,
Wojtek

  - Original Message - 
  From: Serge Lages 
  To: [EMAIL PROTECTED] ; OpenSceneGraph Users 
  Sent: Tuesday, December 11, 2007 9:34 AM
  Subject: Re: [osg-users] Latest SVN: problems with Plugins without Manifests


  On Dec 10, 2007 9:49 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote:

Thanks for assistance,

I will further investigate it. I use XP SP2. Something that may be 
important here is the fact that our app loads OSG dynamically. We have our 
program divided into DLL components and some of these components are linked 
with OSG libs. Components are selected and loaded at run time based on 
application config. So in in this way OSG is also loaded dynamically. It used 
to work flawlessly till now. One more thing, I doubt its related, but these XP 
are Polish language version. 

I assume you have msvcp80d / msvcp80 / msvcr80 and msvcr80d dlls + release 
and debug runtime manifests stored in 3rd party binaries or somewhere else on 
the system path. Where tey are located ? Can you send me these files ? I guess 
manifest should suffice in case you use standard SP80 VS1 redist (version 
8.0.50727.762) . I took my dlls from Windoiws/WinSxS redist directory because I 
could not find them in the folder where I got VS8 Express installed. Maybe 
manifest should be modified and differ somehow than the one stored in WinSxS 
directory ? If I made a mistake then it must have been a manifest which was 
wrong. 



  Hi Wojciech,

  The fact that you load OSG dynamically must be the point that make it 
break... About the msvc*.dll, on my dev machine I use the ones located into 
WinSxS (without putting them into another directory), and when I redistribute 
an app, I put the folder joined to this mail into the main binary folder. 

  The simpliest way to solve it is to make it optional in CMake to generate or 
not the manifests, I will make the change and submit it to Robert this morning.

  Cheers,

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

Re: [osg-users] Latest SVN: problems with Plugins without Manifests

[Wojciech Lewandowski]

Thanks for assistance,

I will further investigate it. I use XP SP2. Something that may be important
here is the fact that our app loads OSG dynamically. We have our program
divided into DLL components and some of these components are linked with OSG
libs. Components are selected and loaded at run time based on application
config. So in in this way OSG is also loaded dynamically. It used to work
flawlessly till now. One more thing, I doubt its related, but these XP are
Polish language version.

I assume you have msvcp80d / msvcp80 / msvcr80 and msvcr80d dlls + release
and debug runtime manifests stored in 3rd party binaries or somewhere else
on the system path. Where tey are located ? Can you send me these files ? I
guess manifest should suffice in case you use standard SP80 VS1 redist
(version 8.0.50727.762) . I took my dlls from Windoiws/WinSxS redist
directory because I could not find them in the folder where I got VS8
Express installed. Maybe manifest should be modified and differ somehow than
the one stored in WinSxS directory ? If I made a mistake then it must have
been a manifest which was wrong.

Thanks,
Wojtek
  -Original Message-
  From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Serge Lages
  Sent: Monday, December 10, 2007 6:20 PM
  To: OpenSceneGraph Users
  Subject: Re: [osg-users] Latest SVN: problems with Plugins without
Manifests


  Hi Wojciech,

  You said that OSG examples work but not your application ? Is there
something really different in your project configuration ?
  And what is you system ? WinXP or Vista ?

  I have tested this plugin configuration with my app and the OSG examples
without any problem on my WinXP dev machine, a fresh WinXP install without
redistributables or VS installed, and a Vista without redistributables nor
VS8. And I havn't change nothing to my app or the examples to make it work.
  I have never seen before your errors, it is really weird. :/

  If your problem persist I think I will add an option to CMake to choose to
build the manifests or not.


  On Dec 10, 2007 5:19 PM, Wojciech Lewandowski < [EMAIL PROTECTED]>
wrote:

Hi,

I just have updated from SVN and rebuilt OSG. It looks like OSG examples
work but when I try to run my application, all plugin DLLs are not loaded
due to missing manifests. I think I understand the idea to avoid manifests
and MS runtime DLL problems in Plugins but it looks like it caused exactly
opposite results for me.

For some time I have learned to live with manifests and stay quite
happy. So I am not very experienced in writing my own manifests or
overcoming problems with not found Redistributable DLLs. All I always had to
do: was loading Redistirutable setup and installing it.

So I expect that proponents of this change will know how to configure
system to use "new" plugins. I did brief research in microsoft websites got
some puzzling answers, tried few methods but without success. I tried to
copy msvcp80.dll, msvcr80.dll into my apllication lib but I get the error
about DLLs loaded without manifests. If I add manifest add manifest file
from WinSxS redist to my app directory I get different error message.

What should I do to make it work ?

I use VS 80 SP1. OSG examples seem to load the plugins. When I use my
aplication in different directory plugins are not loaded. Error hapens when
osgDB tries to load osgdb_jpg.dll to load our splash screen. OSG dlls are
not copied into app dir but loaded from system PATH.

Attached are screenshots with the error messages.

Regards, Thanks for any help,
Wojtek Lewandowski

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





  --
  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] Latest SVN: problems with Plugins without Manifests

[Wojciech Lewandowski]

Hi,

I just have updated from SVN and rebuilt OSG. It looks like OSG examples work 
but when I try to run my application, all plugin DLLs are not loaded due to 
missing manifests. I think I understand the idea to avoid manifests and MS 
runtime DLL problems in Plugins but it looks like it caused exactly opposite 
results for me. 

For some time I have learned to live with manifests and stay quite happy. So I 
am not very experienced in writing my own manifests or overcoming problems with 
not found Redistributable DLLs. All I always had to do: was loading 
Redistirutable setup and installing it.

So I expect that proponents of this change will know how to configure system to 
use "new" plugins. I did brief research in microsoft websites got some puzzling 
answers, tried few methods but without success. I tried to copy msvcp80.dll, 
msvcr80.dll into my apllication lib but I get the error  about DLLs loaded 
without manifests. If I add manifest add manifest file from WinSxS redist to my 
app directory I get different error message.

What should I do to make it work ? 

I use VS 80 SP1. OSG examples seem to load the plugins. When I use my 
aplication in different directory plugins are not loaded. Error hapens when 
osgDB tries to load osgdb_jpg.dll to load our splash screen. OSG dlls are not 
copied into app dir but loaded from system PATH. 

Attached are screenshots with the error messages. 

Regards, Thanks for any help,
Wojtek Lewandowski<><>___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Question about ShadowedScene

[Wojciech Lewandowski]

Hi, 

I am trying to work with osgShadow in my application. Node graph is bit more 
complicated than osgShadow example and I see a problem with shadow map not 
rendered to shadow texture (its empty - filled only with clear depth value). 

One thing that I may do wrong is use of ShadowScene. We do not use it as scene 
root but instead place down in the hierarchy under a chain of parent nodes. Is 
it allowed ? Or ShadowedScene won't work if not passed as root node to 
Viewer->setSceneData ?

We are heavily using node masks for terrain intersections and this somewhat 
restricts recommended CastsShadow  ReceivesShadow mask approach. Thats why we 
placed shadowed nodes down in the graph hierarchy.

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

Re: [osg-users] Computing BoundingBox from RenderBin ?

[Wojciech Lewandowski]

Amount of job you do - causes me to suspect that you are twins at least. 
After cloninig there would be a three or four of you ?

I also noticed CustomPolytope class and its methods. Does it work for some 
special cases only or can be used to compute intersections of any arbitrary 
convex volumes ? It looks like it can directly used in Trapezoidal Shadow 
Map computations.

Cheers,
Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, December 04, 2007 2:28 PM
Subject: Re: [osg-users] Computing BoundingBox from RenderBin ?


> On Dec 4, 2007 12:39 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> 
> wrote:
>> Thank You,
>>
>> Seems that studying
>> OverlayNode::traverse_VIEW_DEPENDENT_WITH_ORTHOGRAPHIC_OVERLAY may be
>> appropriate for my task. Thats a huge piece of code. Thanks again.
>
> My plan is to refactor OverlayNode so that the code for computing the
> intersection code between the view frustum, the overlay geometry and
> the scene would become part of CullVisitor, and osgUtil to also have
> helper functions for setting up the various parameters required for
> the shaders.  This would be to facilitate other techniques like shadow
> mapping.
>
> Alas if I only could clone myself then I'd have to time to do this...
>
> 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] Computing BoundingBox from RenderBin ?

[Wojciech Lewandowski]

Thank You,

Seems that studying 
OverlayNode::traverse_VIEW_DEPENDENT_WITH_ORTHOGRAPHIC_OVERLAY may be 
appropriate for my task. Thats a huge piece of code. Thanks again.

Wojtek

- Original Message - 
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Tuesday, December 04, 2007 12:40 PM
Subject: Re: [osg-users] Computing BoundingBox from RenderBin ?


> Hi Wjciech,
>
> I have done something very similiar to Trapezoidal/Perspective shadow
> maps in the osgSim::OverlayNode, have a look at its implementation.
>
> Robert.
>
> On Dec 4, 2007 11:22 AM, Wojciech Lewandowski <[EMAIL PROTECTED]> 
> wrote:
>>
>>
>> Hi Everyone,
>>
>> I am trying to implement Shadow Mapping algorithm somewhat similar to
>> Trapezoidal/Perspective shadow maps. During this work I learned that one 
>> of
>> most effective optimizations is proper calculation of minimal shadowed 
>> world
>> area and appropriate construction of minimal shadow map.
>>
>> I came up with idea that computing bounding box from drawables stored in
>> main camera render bin (after main cam traversal) could be useful for 
>> this
>> purpose. Finding union of this bounding box with camera frustum would
>> produce even better conditioned volume.
>>
>> Can someone provide me some hints/advice on:
>>
>> How to optimally scan drawable bounding boxes stored in render bin ? 
>> Would
>> this require writing special CullVisitor or can be done by a callback ? 
>> Any
>> examples ?
>>
>>
>> Thanks in advance,
>> 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

[osg-users] Computing BoundingBox from RenderBin ?

[Wojciech Lewandowski]

Hi Everyone,

I am trying to implement Shadow Mapping algorithm somewhat similar to 
Trapezoidal/Perspective shadow maps. During this work I learned that one of 
most effective optimizations is proper calculation of minimal shadowed world 
area and appropriate construction of minimal shadow map.

I came up with idea that computing bounding box from drawables stored in main 
camera render bin (after main cam traversal) could be useful for this purpose. 
Finding union of this bounding box with camera frustum would produce even 
better conditioned volume.  

Can someone provide me some hints/advice on: 

How to optimally scan drawable bounding boxes stored in render bin ? Would this 
require writing special CullVisitor or can be done by a callback ? Any examples 
? 


Thanks in advance,
Wojtek Lewandowski ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OT: Visual Studio stupid memory dumps work around

[Wojciech Lewandowski]

Thats a Fantastic news ;-) I tried exit() and abort() without success.

Thanks,
Wojtek Lewandowski
  -Original Message-
  From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Gordon
Tomlinson
  Sent: Sunday, November 18, 2007 8:13 PM
  To: osg-users@lists.openscenegraph.org
  Subject: [osg-users] OT: Visual Studio stupid memory dumps work around


  For those who get caught the the silly memory dump when in debug mode in
visual studio under windoze

  Add the following to we you would normally exit your program


  TerminateProcess( GetCurrentProcess(), 0);


  Your app will now exit nice and quickly and nor silly memory dumps


  Best Regards


  Gordon

  __
  Gordon Tomlinson
  Email  : gordon.tomlinson @ overwatch.com
  YIM/AIM: Gordon3dBrit
  MSN IM : Gordon3dBrit @ 3dSceneGraph.com

  __
  Telephone (Cell): (+1) 571-265-2612 <-- Note New Number
  Telephone (Work): (+1) 703-437-7651

  "Self defence is not a function of learning tricks
  but is a function of how quickly and intensely one
  can arouse one's instinct for survival"
  - Master Tambo Tetsura

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

Re: [osg-users] marker projection on sphere

[Wojciech Lewandowski]

What type of marker ? Some kind of geometry or just texture projected on the 
surface ?

I am afraid that first one would be impossible without some intersection 
testing (or depth picking - maybe GL picking could work - but its a guess as 
I am not an expert on GL picking).

Texture marker may be much simpler using texgen and second texture stage for 
marker.

If you are allowed to use shaders you may try to do some procedural fragment 
coloring based on direct screen coords available in fragment shader.

Does this marker needs to adjust to the depth somehow ? If not why you just 
not draw it at your screen location after whole scene was drawn ?

Regards,
Wojtek Lewandowski

PS. Mozesz zaatakowac mnie bezposrednio pod moim adresem po Polsku. Musimy 
sobie pomagac ;-)

- Original Message - 
From: "Janusz Goldasz" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, November 07, 2007 7:38 PM
Subject: [osg-users] marker projection on sphere


> Hello:
>
> I would appreciate any help/advice to direct me in the right direction->
>
> I need to project a marker on a sphere in such a way that its
> coordinates when projected back on the viewport (screen coordinates)
> remain constant regardless camera movements/panning/dragging/pitch
> changes, etc. For a number of reasons this cannot be done using 
> intersector.
>
> The marker has to follow the camera motion "gliding" on the sphere's
> surface in any direction (or a little above it) but the projected
> coordinates should not change and ideally be located in the center of
> the viewport.
>
> If that were done using the intersector the OSG code would be, e.g.:
>
> ---
> if
> (viewer->computeIntersections(ea.getWindowX()+0.5*ea.getWindowWidth(),ea.getWindowY()+0.5*ea.getWindowHeight(),intersections))
>{
>  const osgUtil::LineSegmentIntersector::Intersection&
> intersection = *(intersections.begin());
>
>  osg::Vec3 markerXYZ = intersection.getWorldIntersectPoint();
> // marker on the sphere
> .
> }
>
> Appreciate any guidance/advice,
> Janusz Goldasz
> ___
> 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] Collada Plugin DAE build errors

[Wojciech Lewandowski]

Hi, I don't know how to make static link. But I succeeded in using dynamic
Colllada DLLs.

To make it work:
1 define DYNAMIC_DOM macro for the plugin (this forces using dllimports on
collada symbols in the plugin)
2 from all collada related libs use only libcollada141dom13.lib (import
library) remove other libs from the link line
(delete inputs of libcollada_dom.lib libcollada_dae.lib
libcollada_STLDatabase.lib libcollada_LIBXMLPlugin.lib
libcollada_stdErrPlugin.lib libxml2.lib)
3 compile and build and install (it works for me)
4 unfortunately latest cmake build keeps restoring project settings when
install is build. You may need to redo steps 1-2 before each build. I help
myself here by building and installing Collada plugin once then unload
project from solution. Otherwise each consecutive build and install stops on
errors due to restored faulty settings.

I may be wrong here, but I saw few weeks ago that Collada maintainer
submitted some fix to make it build as dynamic by default. But I guess this
submit did not get into distribution yet.

Regards,
Wojtek Lewandowski




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Hamm,
Brandon
Sent: Tuesday, October 23, 2007 11:20 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Collada Plugin DAE build errors


I have this same issue - such that I've yet to have it build
successfully on Windows.  I HAVE got it successfully built and used it
in a Linux environment, though.  If you do get it built on Windows,
please post your solution as I would certainly appreciate it.

Thanks,

Brandon Hamm
SimAuthor, Inc.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, October 21, 2007 7:49 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Collada Plugin DAE build errors

I have this same problem.  I tried removing LIBXML_STATIC from the
preprocessor defines in LIBXMLPlugin.vcproj and rebuilt and still get
the same error.

Adrian Egli wrote:
> hi
>
> (1) i downloaded the collada prebuild library from
> http://sourceforge.net/projects/collada-dom
> (2) installed the prebuild library
> http://sourceforge.net/project/showfiles.php?group_id=157838&package_i
> d=211510
>  id=211510>
> (17.04.2007)
> (3) c-make configurated
> (4) build osg with VC 7 and got the following errors:
>
> Plug 3d dae error LNK2019: unresolved external symbol _xmlFree
> referenced in function "private: void __thiscall
> daeLIBXMLPlugin::readAttributes(class daeElement *,struct
> _xmlTextReader *)"
> (?readAttributes 
> daeLIBXMLPlugin@@AAEXPAVdaeElement@@PAU_xmlTextReader@@@Z)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

Re: [osg-users] Problem with combining texture maps.

[Wojciech Lewandowski]

Pictures you sent look like GTOPO30 elevation tile thumbnails. They don't
seem to be georefernced. Which means you need to define the mapping between
database coordinates and image pixels.

 If you want to create flat non georeferenced database you may do it as
described in the osgDem wiki page: using options -xx -yy. But you will also
need some more options to indicate image origins (--xy, --yx etc).
Unfortunately these are not documented (you would need to look at the
source) .
http://www.openscenegraph.org/index.php?page=UserGuides.Osgdem
In practice there are more options than wiki page shows. Running --help will
display all of them.

It seems that similar functionality may give the --range option. Just
precede each -t image call with  --range Xmin Xmax Ymin Ymax. This will
define world extents of the next image you load with -t option.

I don't have the osgDem at home. I cannot test this but I would try to
define extents with following options:
...
--range -180 -140 40 90  -t W180N90.tif
--range -140 -100 40 90  -t W140N90.tif
...

There is one catch, I am not sure if --range was already present in all
osgDEM versions. If you don't find it,  try VPB or ultimate method: load
these two into some image editor, merge them and use single -t option with
merged image.

Regards,
Wojtek

PS1: On a side note: option -t treats these as colour channels not elevation
are your sure you don't want to use -d option instead of -t.

PS2: osgDem was superceded by Virtual Planet Builder VPB project. You may
check it out. For sure it will have --range option.
http://www.openscenegraph.org/projects/VirtualPlanetBuilder



-Original Message-
From: om [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 04, 2007 9:50 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] Problem with combining texture maps.


Wojciech Lewandowski wrote:

>If you have copied the same command as you invoked,  thats because you use
>osgdem -t option twice with the same W180N90.tif file. ;-).
>If you did a mistake in the email and not in real command, and actually use
>two different tiffs then it may mean that your tiffs are not georeferenced
>(GeoTiff) and osgDem does assume they cover the same range. You may need to
>use other osgDem options to define word ranges this tiffs correspond to ...
>Run osgDem --help  for the list of options.
>
>Regards,
>Wojtek
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] Behalf Of om
>Sent: Thursday, October 04, 2007 8:53 PM
>To: OpenSceneGraph Users
>Subject: [osg-users] Problem with combining texture maps.
>
>
>I tried to combine two texture maps with the following command line
>script using osgdem.
>
>osgdem -t W180N90.tif  -t W180N90.tif -l 1 -a output.osga
>output.osga shows the second texture map only. It'll be great if
>somebody can enlighten me on where it is going wrong.
>I can send the texture maps if required
>
>Thanks
>om
>___
>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
>
>
>
>
sorry the similarity in names was a mistake in the mail...
Could you please suggest the option to be used from osgdem as I am
unable to find it out. :-(
I am sending the texture maps also for ur reference.

thanks
Om





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

Re: [osg-users] Problem with combining texture maps.

[Wojciech Lewandowski]

If you have copied the same command as you invoked,  thats because you use
osgdem -t option twice with the same W180N90.tif file. ;-).
If you did a mistake in the email and not in real command, and actually use
two different tiffs then it may mean that your tiffs are not georeferenced
(GeoTiff) and osgDem does assume they cover the same range. You may need to
use other osgDem options to define word ranges this tiffs correspond to ...
Run osgDem --help  for the list of options.

Regards,
Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of om
Sent: Thursday, October 04, 2007 8:53 PM
To: OpenSceneGraph Users
Subject: [osg-users] Problem with combining texture maps.


I tried to combine two texture maps with the following command line
script using osgdem.

osgdem -t W180N90.tif  -t W180N90.tif -l 1 -a output.osga
output.osga shows the second texture map only. It'll be great if
somebody can enlighten me on where it is going wrong.
I can send the texture maps if required

Thanks
om
___
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] more on Windows debugging

[Wojciech Lewandowski]

I am glad to hear that. Out of curiosity which option was missing ?

Wojtek

- Original Message - 
From: "Andy Skinner" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Thursday, September 27, 2007 5:10 PM
Subject: Re: [osg-users] more on Windows debugging


> It works, and I'm debugging.
> 
> Thanks so much.  We've got several OSG developers here, and this will be
> very helpful.
> 
> I've asked how come this flag isn't included for our 3rd party builds,
> and I'm curious why we got pdb files and symbols without it.  That's why
> I was confused for a long time.  But I'm going now, anyway.
> 
> andy
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andy
> Skinner
> Sent: Thursday, September 27, 2007 10:28 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] more on Windows debugging
> 
> Thanks to Wojtek, I think I'm getting somewhere.
> 
> When he looked at strings in his pdb files, he saw paths to source code,
> and I didn't.  But I was pretty sure I was generating things with flags,
> because I was creating pdb files and the debugger was finding symbols.
> 
> Well, apparently something was creating pdb files, but not with enough
> info.  I added some of the flags that I thought had to be there anyway
> to generate the files in the first place, and I'm seeing the source file
> paths in the pdb files.
> 
> I'm still building, but I should be able to test soon.
> 
> I'm not sure what options built debug and made pdb files and symbols but
> didn't put the source paths in the pdb files, but I think I'll be able
> to resolve this now.
> 
> andy
> 
> 
> -Original Message-
> From: Wojciech Lewandowski [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 27, 2007 4:35 AM
> To: Andy Skinner; OpenSceneGraph Users
> Subject: Re: [osg-users] more on Windows debugging
> 
>>Do you actually have the OSG (or in this case OpenThreads) source path
>>names, up to the .cpp extension in your pdb file?
> 
> Yes. PDB is a huge container of various information. It contains both 
> relative paths (prefixed with ./) and absolute paths of my source files.
> 
> Also contains  whole commands used to compile and link.
> 
> I googled PDB a little. Found few interesting links but nothing realy 
> spectacular. Some information on microsoft site says that copying .pdb
> files 
> to working directory may help: 
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366 :
> 
> " The new Visual C++ debugger uses the .PDB file created by the
> 
> linker directly, and embeds the absolute path to the .PDB in the .EXE or
> 
> .DLL file. If the debugger can't find the .PDB file at that location or
> if 
> the path is invalid (if, for example, the project was moved to another 
> computer), the debugger looks for it in the current directory. "
> 
> If you are desperate you may try to grab DIA sdk and build dia2dump
> example 
> and see what exactly your PDB contains.
> http://msdn2.microsoft.com/en-us/library/x93ctkx8(VS.80).aspx
> 
> Hope it helps,
> Wojtek
> 
> - Original Message - 
> From: "Andy Skinner" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "OpenSceneGraph Users" 
> 
> Sent: Wednesday, September 26, 2007 10:34 PM
> Subject: RE: [osg-users] more on Windows debugging
> 
> 
> Thanks.  I have been looking at strings in these files, too.  I did not
> see the path to the cpp files listed in the pdb file.  I see paths to
> .obj files, a .dll.embed.manifest.res file, some source files
> (f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a
> volume f) but no OSG source files.  There are some .exp files.
> 
> Do you actually have the OSG (or in this case OpenThreads) source path
> names, up to the .cpp extension in your pdb file?
> 
> In the meantime, I have been trying to debug just looking at stack
> traces.  I should see how far I can get using linux, too, although I'm
> not fond of gdb.
> 
> thanks,
> andy
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Wojciech Lewandowski
> Sent: Wednesday, September 26, 2007 4:24 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] more on Windows debugging
> 
> My INSTALL step does copy these DLLs to the different location. They
> were
> compiled in OpenSceneGraph\src\subproject and linked in
> OpenSceneGraph\lib\release or debug directories and INSTALL places them
> in
> OpenSceneGraph\bin directory. Technically its almost the same s

Re: [osg-users] more on Windows debugging

[Wojciech Lewandowski]

>Do you actually have the OSG (or in this case OpenThreads) source path
>names, up to the .cpp extension in your pdb file?

Yes. PDB is a huge container of various information. It contains both 
relative paths (prefixed with ./) and absolute paths of my source files. 
Also contains  whole commands used to compile and link.

I googled PDB a little. Found few interesting links but nothing realy 
spectacular. Some information on microsoft site says that copying .pdb files 
to working directory may help: 
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q121366 :

" The new Visual C++ debugger uses the .PDB file created by the 
linker directly, and embeds the absolute path to the .PDB in the .EXE or 
.DLL file. If the debugger can't find the .PDB file at that location or if 
the path is invalid (if, for example, the project was moved to another 
computer), the debugger looks for it in the current directory. "

If you are desperate you may try to grab DIA sdk and build dia2dump example 
and see what exactly your PDB contains.
http://msdn2.microsoft.com/en-us/library/x93ctkx8(VS.80).aspx

Hope it helps,
Wojtek

- Original Message - 
From: "Andy Skinner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "OpenSceneGraph Users" 

Sent: Wednesday, September 26, 2007 10:34 PM
Subject: RE: [osg-users] more on Windows debugging


Thanks.  I have been looking at strings in these files, too.  I did not
see the path to the cpp files listed in the pdb file.  I see paths to
.obj files, a .dll.embed.manifest.res file, some source files
(f:\sp\public\sdk\inc\pshpack4.h, for example, and I don't even have a
volume f) but no OSG source files.  There are some .exp files.

Do you actually have the OSG (or in this case OpenThreads) source path
names, up to the .cpp extension in your pdb file?

In the meantime, I have been trying to debug just looking at stack
traces.  I should see how far I can get using linux, too, although I'm
not fond of gdb.

thanks,
andy


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Wojciech Lewandowski
Sent: Wednesday, September 26, 2007 4:24 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] more on Windows debugging

My INSTALL step does copy these DLLs to the different location. They
were
compiled in OpenSceneGraph\src\subproject and linked in
OpenSceneGraph\lib\release or debug directories and INSTALL places them
in
OpenSceneGraph\bin directory. Technically its almost the same situation
as
yours. I did an extra test and moved DLLs to my sample project
directory.
Even if they were loaded from my app dir I was still able to step into
OSG
sources.

Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for
OpenThreadsd.pdb string. There is only one line containing this string
and
this line contains full absolute path to the place where
OpenThreadsd.pdb
was built. In my case this is
C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened
PDB
in hexeditor. PDB seems to keep all the absolute paths to the source cpp
files. My PDB still resides in this directory where DLL points (ie where
DLL
was linked) and my source OSG cpp files are still at the same directory
where PDB points (ie where they were compiled). DLL may be moved
wherever I
want and VS is still able to find the sources. I guess VS first loads
DLL,
reads the PDB absolute path, then loads PDB and finds absolute paths to
sources. I suppose VS may have trouble if PDB or cpp files absolute
paths
change. But it looks that DLL can be moved freely.

PS. I use VS 2005 SP1 maybe it matters.

Wojtek


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andy
Skinner
Sent: Wednesday, September 26, 2007 7:26 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] more on Windows debugging


Thanks.  I have some of the same setup, but I don't get OSG from the
place where I built it.  I'm afraid that moving the dlls has lost their
connection with the source.

I've got paths set to specify the source, but it doesn't seem to be
helping, in the same way it didn't help you to remove them.  :)

thanks,
andy


-----Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Wojciech Lewandowski
Sent: Wednesday, September 26, 2007 11:43 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] more on Windows debugging

Below is my OSG configuration. Apparently it works well with Visual
Studio
2005 Express intellibase as I am able to step down into OSG sources from
my
OSG based projects. This may be no solution for you but I hope it may be

helpful somehow if you will be able to find differences and maybe
finally
isolate the cause of the problems.

1. I keep all my projects in C:\DEV directory. All OSG svn related
projects
are kept in C:\DEV\OSG_SVN\ directory. And OpenSceneGraph distribution
is
located in C:\DEV\OSG_SVN\OpenSceneGraph.

2. After Op

Re: [osg-users] more on Windows debugging

[Wojciech Lewandowski]

My INSTALL step does copy these DLLs to the different location. They were
compiled in OpenSceneGraph\src\subproject and linked in
OpenSceneGraph\lib\release or debug directories and INSTALL places them in
OpenSceneGraph\bin directory. Technically its almost the same situation as
yours. I did an extra test and moved DLLs to my sample project directory.
Even if they were loaded from my app dir I was still able to step into OSG
sources.

Out of curiosity I opened OpenThreadsd.dll in hexeditor. Searched for
OpenThreadsd.pdb string. There is only one line containing this string and
this line contains full absolute path to the place where OpenThreadsd.pdb
was built. In my case this is
C:\dev\OSG_SVN\OpenSceneGraph\lib\Debug\OpenThreadsd.pdb. I also opened PDB
in hexeditor. PDB seems to keep all the absolute paths to the source cpp
files. My PDB still resides in this directory where DLL points (ie where DLL
was linked) and my source OSG cpp files are still at the same directory
where PDB points (ie where they were compiled). DLL may be moved wherever I
want and VS is still able to find the sources. I guess VS first loads DLL,
reads the PDB absolute path, then loads PDB and finds absolute paths to
sources. I suppose VS may have trouble if PDB or cpp files absolute paths
change. But it looks that DLL can be moved freely.

PS. I use VS 2005 SP1 maybe it matters.

Wojtek


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andy Skinner
Sent: Wednesday, September 26, 2007 7:26 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] more on Windows debugging


Thanks.  I have some of the same setup, but I don't get OSG from the
place where I built it.  I'm afraid that moving the dlls has lost their
connection with the source.

I've got paths set to specify the source, but it doesn't seem to be
helping, in the same way it didn't help you to remove them.  :)

thanks,
andy


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Wojciech Lewandowski
Sent: Wednesday, September 26, 2007 11:43 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] more on Windows debugging

Below is my OSG configuration. Apparently it works well with Visual
Studio
2005 Express intellibase as I am able to step down into OSG sources from
my
OSG based projects. This may be no solution for you but I hope it may be

helpful somehow if you will be able to find differences and maybe
finally
isolate the cause of the problems.

1. I keep all my projects in C:\DEV directory. All OSG svn related
projects
are kept in C:\DEV\OSG_SVN\ directory. And OpenSceneGraph distribution
is
located in C:\DEV\OSG_SVN\OpenSceneGraph.

2. After OpenScenGraph SVN update I run CMake and change OSG INSTALL
directory variable to '.' (dot - current directory). It has the effect
that
install will make bin and lib subdirectories in OpenSceneGraph root
directory. Ie:  C:\DEV\OSG_SVN\OpenSceneGraph\bin and
C:\DEV\OSG_SVN\OpenSceneGraph\lib.

DLLs and EXEs land in:
 C:\DEV\OSG_SVN\OpenSceneGraph\bin

Libraries land in:
C:\DEV\OSG_SVN\OpenSceneGraph\lib

Headers remain in (Cmake is clever and does not copy them over
themselves):
C:\DEV\OSG_SVN\OpenSceneGraph\include

3. My system PATH variable inludes C:\DEV\OSG_SVN\OpenSceneGraph\bin
directory

4. With VisualStudio I load Cmake generated sln and run BUILD ALL and
then
BUILD INSTALL to copy binaries to above directories. I do it twice -
once
for Release and once for Debug build.

5. At this point I am able to build, run, debug my projects and step
into
OSG sources (.cpp).

6. I don't know if this is relevant, but obviously to compile and link
my
projects I had set include and library paths in VisualStudio 2005.
Menu
Tools/Options/Projects and Solutions/VC++ Directories:

Path for Include files is set to:
C:\DEV\OSG_SVN\\OpenSceneGraph\include

Path for Library files is set to:
C:\DEV\OSG_SVN\\OpenSceneGraph\lib

Path for Sources files has all subdirs of OpenSceneGraph\src listed in
separate lines:
C:\DEV\OSG_SVN\OpenSceneGraph\src\OpenThreads
C:\DEV\OSG_SVN\OpenSceneGraph\src\osg
C:\DEV\OSG_SVN\OpenSceneGraph\src\osgUtil
and so on.
I don't think that source paths are really that important. For some
testing
I removed one of  source path lines and Visual Studio was still able to
find
sources and step into them. But it may be neccessary during OSG build
(when
intellibase is generated) so I propose to set them as well. It won't
make
things worse.

Hope this helps,
Wojtek



- Original Message -
From: "Andy Skinner" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Wednesday, September 26, 2007 2:47 PM
Subject: Re: [osg-users] more on Windows debugging


> Yep, I've got 2.1.12.
>
> I copy the bin and lib files elsewhere for installation, but I've
> pointed visual studio at the pdb files and source files back in the
> build area, though.
>
> I'

Re: [osg-users] more on Windows debugging

[Wojciech Lewandowski]

Below is my OSG configuration. Apparently it works well with Visual Studio 
2005 Express intellibase as I am able to step down into OSG sources from my 
OSG based projects. This may be no solution for you but I hope it may be 
helpful somehow if you will be able to find differences and maybe finally 
isolate the cause of the problems.

1. I keep all my projects in C:\DEV directory. All OSG svn related projects 
are kept in C:\DEV\OSG_SVN\ directory. And OpenSceneGraph distribution is 
located in C:\DEV\OSG_SVN\OpenSceneGraph.

2. After OpenScenGraph SVN update I run CMake and change OSG INSTALL 
directory variable to '.' (dot - current directory). It has the effect that 
install will make bin and lib subdirectories in OpenSceneGraph root 
directory. Ie:  C:\DEV\OSG_SVN\OpenSceneGraph\bin and 
C:\DEV\OSG_SVN\OpenSceneGraph\lib.

DLLs and EXEs land in:
 C:\DEV\OSG_SVN\OpenSceneGraph\bin

Libraries land in:
C:\DEV\OSG_SVN\OpenSceneGraph\lib

Headers remain in (Cmake is clever and does not copy them over themselves):
C:\DEV\OSG_SVN\OpenSceneGraph\include

3. My system PATH variable inludes C:\DEV\OSG_SVN\OpenSceneGraph\bin 
directory

4. With VisualStudio I load Cmake generated sln and run BUILD ALL and then 
BUILD INSTALL to copy binaries to above directories. I do it twice - once 
for Release and once for Debug build.

5. At this point I am able to build, run, debug my projects and step into 
OSG sources (.cpp).

6. I don't know if this is relevant, but obviously to compile and link my 
projects I had set include and library paths in VisualStudio 2005.   Menu 
Tools/Options/Projects and Solutions/VC++ Directories:

Path for Include files is set to:
C:\DEV\OSG_SVN\\OpenSceneGraph\include

Path for Library files is set to:
C:\DEV\OSG_SVN\\OpenSceneGraph\lib

Path for Sources files has all subdirs of OpenSceneGraph\src listed in 
separate lines:
C:\DEV\OSG_SVN\OpenSceneGraph\src\OpenThreads
C:\DEV\OSG_SVN\OpenSceneGraph\src\osg
C:\DEV\OSG_SVN\OpenSceneGraph\src\osgUtil
and so on.
I don't think that source paths are really that important. For some testing 
I removed one of  source path lines and Visual Studio was still able to find 
sources and step into them. But it may be neccessary during OSG build (when 
intellibase is generated) so I propose to set them as well. It won't make 
things worse.

Hope this helps,
Wojtek



- Original Message - 
From: "Andy Skinner" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Wednesday, September 26, 2007 2:47 PM
Subject: Re: [osg-users] more on Windows debugging


> Yep, I've got 2.1.12.
>
> I copy the bin and lib files elsewhere for installation, but I've
> pointed visual studio at the pdb files and source files back in the
> build area, though.
>
> I'm wondering whether Visual Studio knows these are related, however.  I
> tried starting up visual studio with the OpenSceneGraph.sln, and
> attaching it to our program running with OSG libraries.  I open a source
> file and try to make a breakpoint, and it says no symbols have been
> loaded for that document.
>
> In the modules window, I can see that dll (osg23-osgUtild.dll), saying
> that it loaded symbols from the pdb file I expect.
>
> So it really does make me wonder if it just doesn't that that this
> source file is associated with this dll or pdb file.
>
> andy
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Robert
> Osfield
> Sent: Wednesday, September 26, 2007 8:39 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] more on Windows debugging
>
> Hi Andy,
>
> Out of curiosity which version of the OSG are you working with now?
> Do they include Luigi's modifications for building libs and debug
> files in the bin directory?
>
> Robert.
>
> On 9/26/07, Andy Skinner <[EMAIL PROTECTED]> wrote:
>> I am definitely using the dlls associated with the pdb files, which
> were
>> generated in debug mode.  I can find where the libraries come from,
>> where the pdb files come from, etc, and all is in place.  The symbols
>> are in the stack trace as well.  Before I was using debug directories,
>> it couldn't tell me where it was in OSG.
>>
>> One possible issue is that these dlls have been copied to other places
>> since they were built, and they're not in the same place relative to
> the
>> pdb files or source code.  But they are the files built with the pdb
>> files and source code.
>>
>> It has been suggested that I try to load the OSG solution and attach
> to
>> my program.  This may now make it harder to debug our code, but it
> would
>> be something.
>>
>> andy
>>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Eric
>> Sokolowsky
>> Sent: Tuesday, September 25, 2007 5:16 PM
>> To: OpenSceneGraph Users
>> Subject: Re: [osg-users] more on Windows debugging
>>
>> Andy Skinner wrote:
>> > I can step into header files, but not the source.  I wonder why that
>> is.
>> >
>> > It seems I'm pretty close, since it is fin

Re: [osg-users] more on Windows debugging

[Wojciech Lewandowski]

 I had similar problems which were usually related to the fact I did not 
install binaries after building OSG and were actually using new PDBs with 
earlier set of DLLs. Even if there is no binary change in DLLs visual studio 
seems to not find sources if DLLs do not come from the same built as the 
PDBs.
I don't know if this helps you but I would stress what erlier said Brian: 
please make sure you are actually using those DLLs that were built with PDB 
files.

Regards,
Wojtek

- Original Message - 
From: "Andy Skinner" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "OpenSceneGraph Users" 

Sent: Tuesday, September 25, 2007 9:03 PM
Subject: Re: [osg-users] more on Windows debugging


>I can step into header files, but not the source.  I wonder why that is.
>
> It seems I'm pretty close, since it is finding the header file.  If
> anyone could suggest why Visual Studio can find one and not the other,
> I'd be grateful.  I've added both to the list of debug source.
>
> andy
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Brian
> Sent: Monday, September 24, 2007 11:10 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] more on Windows debugging
>
>
> Usually, VS will prompt you for a file location if it cannot find a
> file.  It sounds like your DLLs are being loaded from the correct place,
> but just in case, make certain that the DLLs you just recently built
> match the ones that are being loaded.  It's been my experience that PDB
> files can be very picky (frustatingly so, sometimes).  Check your output
> window for the DLL names.  Also, set a breakpoint on some code that
> calls an OSG function.  Step into that code and see what happens.  The
> IDE should prompt you for a source filename if it cannot determine where
> it is.
>
> That's all that I can think of at the moment.
>
> Hope it helps,
> Brian
>
> On Mon Sep 24 10:39 , 'Andy Skinner' <[EMAIL PROTECTED]> sent:
>
>>Has anyone had to do anything tricky to see OSG source code while
>>debugging their application?
>>
>>I've been able to compile OSG debug, and to put the .pdb files where
>>Visual Studio can see them.  If I stop in my code, I can see OSG
> symbols
>>on the stack trace.  But I can't see the source code.
>>
>>I've added the directories I need to a list of debug source locations.
>>
>>Does anyone else know how I should be able to see into the OSG source
> in
>>Visual Studio?
>>
>>thanks,
>>andy
>>
>>___
>>osg-users mailing list
>>osg-users@lists.openscenegraph.org
>>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o
> rg
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
> g
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 


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

Re: [osg-users] Problems using OSG 2.0 on two monitors under WinXP

[Wojciech Lewandowski]

Your problem looks similar to what we experienced. We noticed that changing 
NVidia driver settings helps sometimes.
Try changing NVidia driver: Performance and Quality Settings/ Hardware 
Acceleration to Multi-display mode.

On a side: from time to time we see a strange issues when we use two monitor 
config. Usually switch to single display solves the problem. This suggests 
that most of these issues are driver related.

Regards,
Wojtek

- Original Message - 
From: <[EMAIL PROTECTED]>
To: 
Sent: Friday, August 24, 2007 11:24 AM
Subject: Re: [osg-users] Problems using OSG 2.0 on two monitors under WinXP


Hi Robert,

Thank you very much for your detailed answer!

But I am not sure if I discribed the problem in the right way...
In one single system is only one NVIDIA card with two displays attached.

So I guess the memory thing isn't that weird...

To your solutions:
I do not want to disable the dragging because it is crucial for me.

>   Might it be possible to implementing dragging via two coordinated
>   GraphicsWindow one on each screen/card?

What do you mean by this?
Thank you very much!
Julian

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:osg-users-
> [EMAIL PROTECTED] Im Auftrag von Robert Osfield
> Gesendet: Freitag, 24. August 2007 10:50
> An: osg-users@lists.openscenegraph.org
> Betreff: Re: [osg-users] Problems using OSG 2.0 on two monitors under
> WinXP
>
> Hi Julian,
>
> I don't have any direct answers, the best I can do is speculate, so here
> goes...
>
> First up, two different graphics cards have two physcially different
> blocks on memory and associated state that the drivers have to keep in
> sync.
>
> Seocnd, when graphics applications like the open up they open up
> windows on each of the cards/displays, with a graphics window for each
> card/display.  The fact that the cards each have their own state and
> local memory, and own block in driver memory allocated to them is not
> a problem as the separate graphics context all manage this at the same
> level of granularity.
>
> Third, this is where things come unstuck quite easily, if your desktop
> allows you to drag a window from one display/card to another you end
> up with part of the window needing to be rendered by the first card,
> and part by the new one.  Now the graphics window was opened up on the
> first, the second doesn't know anything about it.  A driver which is
> going to manage this trick without blinking will have to duplicate the
> graphics context backend to server two graphics cards at once.
>
> I can image supporting the ability to drag from one screen to another
> across separate graphics cards is really hard to do robustly is really
> really hard, and complicates things within the driver substantially,
> and that the overhead code wise and performance wise is going to be
> big hit.
>
> What amazes me is that is works at all, great kudos to the Nvidia
> drivers for managing this trick.
>
> As what to do to help facilitate things at the OSG end? I'm not sure,
> I don't have any direct experience of this type of function.  If a
> graphics window spans multiple screens then it obviously presents a
> problem with a graphics window Traits only having a single screeenNum
> to represent its address.  But even if you had a list of screen
> numbers, you'd still need the windowing system calls to tell you that
> its been dragged across multiple screens.
>
> Perhaps there are other routes:
>
>   Is it possible to disable the dragging of windows across screens?
>
>   Might it be possible to implementing dragging via two coordinated
>   GraphicsWindow one on each screen/card?
>
> Any others?
>
> Robert.
>
>
> On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I am using many different WinXP-Systems with OSG2.0, all having two
> monitors
> > and different NVIDIA cards.
> >
> >
> >
> > Everything is fine but when I drag the OSG window to the other screen,
> many
> > systems produce the following error:
> >
> > Error: [Screen #0]
> > GraphicsWindowWin32::swapBuffersImplementation() Unable to
> > swap display buffers
> >
> >
> >
> > Then the OSG-Window is not updated anymore. When dragging it back to
> screen
> > 1 the error disappears and ... well sometimes the systems keeps running.
> >
> >
> >
> > Maybe the problem is that the traits->screenNum does not change when the
> > window is dragged e.g. from screen 0 to screen 1, but the X-Coordinate
> of
> > the window goes beyond the resolution of sceen 0.
> >
> >
> >
> > E.g. When Screen 0 has a resolution of 1280x1024 and I drag a window
> from
> > screen 0 to the upper left corner of screen1, screenNum stays 0 and the
> > x-coordinate of the OSG-window becomes 1280.
> >
> >
> >
> > Is there any solution for this on OSG-side?
> >
> >
> >
> > In many cases an update of the NVIDIA driver solves the problem, but not
> on
> > Quadro FX 3500 cards...
> >
> >
> >
> > Thank you very much!
> >
> >
> >
> > Julian
> > _