Re: [osg-users] traversal question w/latest developer release - blacknodes

[sherman wilcox]

I've found a few clues this evening. Not sure why things are behaving
the way they are - I'm probably abusing the OSG in my overridden
traverse(...) function. My node has a shader attached. If I do NOT
attach that shader to the stateset, no problems. Read on

On Feb 12, 2008 3:40 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> > I have a class that inherits from osg::Group. In this class
> > I'm overriding the traverse function. It is written in such a
> > way that the CULL_VISITOR doesn't have an opportunity to call
> > osg::Group::traverse(nv). When I add this object to the
> > scenegraph all the nodes in my scene go black. Even if this
> > class is a child - all the nodes (including parent nodes)
> > appear black.
>
> The presence of this custom Node is changing the color of your geometry so
> that they render black? E.g., against a non-black background, you see them
> render? Or, by "appear black", do you mean they just don't show up?
>
> What color is your Geometry supposed to render?

The only other node is a bluemarble ellipsoid produced by osgdem. It's
entirely black when I intrdouce my node into the scenegraph. If the
node (my custom node) is a sibling, the bluemarble node goes black.

>
> Does your custom Node support the .osg file format? If so, have you dumped
> your scene to a .osg file to see if anything is amiss?
>

No - doesn't support OSG.

> Have you tried to reproduce the problem with a very simple scene, like just
> a single triangle plus your custom Node? Then you could step through in the
> debugger and determine what's going on.
>
> Have you tried capturing the OpenGL output with GLIntercept?
>
> In the past, whenever I've seen state bleed from one Node to a sibling Node,
> it is usually because the sibling Node's Geometry lacks a color array.
>

I suspect either one of (at least) two things:

1) I'm abusing OSG some manner and the code is responding in kind. In
other words, I'm doing something I shouldn't be and I'm getting
undefined behavior.

OR

2) There is some sort of state leakage (of my shader) issue between
sibling nodes. If this is leakage - is it a bug or not?

> > What I did to patch things is to hack my class such that the
> > CULL_VISITOR is allowed to call osg::Group::traverse(nv); at
> > least once at the start. This seems to address the problem,
> > albeit in a kludgy sort of way. I'd like to know if:
> >
> > - this is a new OSG bug?
>
> Are you saying you tried this same thing in v2.2 and the problem didn't
> occur?

I thought this was new - but went back and tried older versions of OSG
and the problem persists. I have a fix (allow one cull traversal on my
custom node)...but it seeems kludgy. I'm either doing something
terribly wrong OR I've found some bug. It's probably the former.

It does strike me as add that performing a single cull traversal
addresses the issue. Seems as though some state isn't be set properly
unless this cull traversal is allowed to pass through.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] MRT

[Guy]

Hello all,

 I've read in the mailing list that some people made some patches to use
MRT.

I also did the same, instead of changing the RenderStage, I changed the
FrameBufferObject apply function (does MRT possible without FBO??)

Anyway, the textures I attach to get the right values, but the images I
attach do not.

In RenderStage, only the last image of the camera attachments is being
copied with readPixels.

So I patched the RenderStage too, going over all camera attachments and
trying to read the images. But readPixels read from the frame buffer, so
for those attachments I attached also a texture and applied the texture
with the state of the renderstage, and then tried readFromCurrentTexture
(with fixing the image class to read correctly when using float) but the
images data was the same (the data on the frame buffer) even that the
textures where different.

 

Can anyone explain how to read the data to the images (or any other way
to get the data from the MRT to the RAM)?

 

Thanks,

 Guy. 

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

Re: [osg-users] traversal question w/latest developer release - blacknodes

[sherman wilcox]

Paul - thanks for the suggestions. I've found an older code tree of
mine from November 07 and everything seemed to work there. I'm
investigating.

On Feb 12, 2008 3:40 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> > I have a class that inherits from osg::Group. In this class
> > I'm overriding the traverse function. It is written in such a
> > way that the CULL_VISITOR doesn't have an opportunity to call
> > osg::Group::traverse(nv). When I add this object to the
> > scenegraph all the nodes in my scene go black. Even if this
> > class is a child - all the nodes (including parent nodes)
> > appear black.
>
> The presence of this custom Node is changing the color of your geometry so
> that they render black? E.g., against a non-black background, you see them
> render? Or, by "appear black", do you mean they just don't show up?
>
> What color is your Geometry supposed to render?
>
> Does your custom Node support the .osg file format? If so, have you dumped
> your scene to a .osg file to see if anything is amiss?
>
> Have you tried to reproduce the problem with a very simple scene, like just
> a single triangle plus your custom Node? Then you could step through in the
> debugger and determine what's going on.
>
> Have you tried capturing the OpenGL output with GLIntercept?
>
> In the past, whenever I've seen state bleed from one Node to a sibling Node,
> it is usually because the sibling Node's Geometry lacks a color array.
>
> > What I did to patch things is to hack my class such that the
> > CULL_VISITOR is allowed to call osg::Group::traverse(nv); at
> > least once at the start. This seems to address the problem,
> > albeit in a kludgy sort of way. I'd like to know if:
> >
> > - this is a new OSG bug?
>
> Are you saying you tried this same thing in v2.2 and the problem didn't
> occur?
>   -Paul
>
> > - anyone else is experiencing this?
> > - or perhaps I'm abusing things in such way that is ill-advised?
> >
> > Comments?
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
> negraph.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] how to read GeoTIFF files using osgdem?

[Linh Phan]

Hi,

  this is my first time trying to use osgdem on a GeoTIFF file and I 
wasn't successful in viewing the
generated osga file.  The data (from 
http://webgis.wr.usgs.gov/ftphirise/index.jsp) look like this:

% ls DEM_1m_VictoriaCrater*
DEM_1m_VictoriaCrater.asc.gz  DEM_1m_VictoriaCrater.rrd
DEM_1m_VictoriaCrater.aux DEM_1m_VictoriaCrater.tif
DEM_1m_VictoriaCrater.prj

% cat DEM_1m_VictoriaCrater.prj

PROJCS["Plate_Carree",GEOGCS["EQUIRECTANGULAR_CYLINDRICAL_MARS",DATUM["D_MARS",SPHEROID["MARS",3396190,0]],PRIMEM["Reference_Meridian",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Plate_Carree"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",180],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]

I then use osgdem command:

% osgdem -l 2 -d DEM_1m_VictoriaCrater.tif -o test.ive -a test.osga

% osgviewer test.osga

But I didn't see anything when osgviewer first came up, but I know 
something is there because when
I spin it, I see something spin by really fast.  My question are:

1. Is the "-d DEM_1m_VictoriaCrater.tif" argument to osgdem all I need 
for a GeoTIFF file?

2. Is there a way for osgviewer to put the object in the center so I can 
see it or do
   I have to ask the USGS to generate the GeoTIFF DEM that has the DEM 
in the center so I can see?

Thank you very much,

Linh


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

Re: [osg-users] osgViewer config files ???

[Bob Huebert]

On Tue, 12 Feb 2008, Brian R Hill wrote:

> Folks,
>
> I'm upgrading from 1.2 to 2.2 and Producer to osgViewer. I see notes in the
> subversion log for osgViewer Viewer.cpp that mention reading configuration
> files, but I can't figure out what the format is.
>
> Is there an equivalent to the Producer config files?
> Is the format described anywhere?

The new files you're looking for are in the current osg data distribution 
within the Configuration directory. There are several .view examples.

I haven't been able to find documentation or a howto on using them. Nor 
are the files commented.

Perhaps someone else has pointers on this?

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

Re: [osg-users] Test www.osgChina.org . Normal?

[yann le paih]

I'm in France, It works for me

On Feb 12, 2008 7:47 PM, Emmanuel Roche <[EMAIL PROTECTED]> wrote:

> I'm in France, it doesn't work at all for me.
>
> 2008/2/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> > FreeSouth wrote:
> > >
> > > Hello all :
> > >Somebody found that He(at Singapore) cann't visit 
> > > www.osgChina.org(located HangZhou China.
> > >I don't know this site can be visited normally or not at other
> > country. Thanks All.
> > > Yang ShiXing
> >
> > very slow but it works from europe
> >
> > ___
> > 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
>
>


-- 
Yann Le Paih
Keraudrono
56150 BAUD
Portable: +33(0)610524356
[EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgViewer config files ???

[Brian R Hill]

Folks,

I'm upgrading from 1.2 to 2.2 and Producer to osgViewer. I see notes in the
subversion log for osgViewer Viewer.cpp that mention reading configuration
files, but I can't figure out what the format is.

Is there an equivalent to the Producer config files?
Is the format described anywhere?

Thanks,

Brian

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


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

Re: [osg-users] traversal question w/latest developer release - blacknodes

[Paul Martz]

> I have a class that inherits from osg::Group. In this class 
> I'm overriding the traverse function. It is written in such a 
> way that the CULL_VISITOR doesn't have an opportunity to call 
> osg::Group::traverse(nv). When I add this object to the 
> scenegraph all the nodes in my scene go black. Even if this 
> class is a child - all the nodes (including parent nodes) 
> appear black.

The presence of this custom Node is changing the color of your geometry so
that they render black? E.g., against a non-black background, you see them
render? Or, by "appear black", do you mean they just don't show up?

What color is your Geometry supposed to render?

Does your custom Node support the .osg file format? If so, have you dumped
your scene to a .osg file to see if anything is amiss?

Have you tried to reproduce the problem with a very simple scene, like just
a single triangle plus your custom Node? Then you could step through in the
debugger and determine what's going on.

Have you tried capturing the OpenGL output with GLIntercept?

In the past, whenever I've seen state bleed from one Node to a sibling Node,
it is usually because the sibling Node's Geometry lacks a color array.

> What I did to patch things is to hack my class such that the 
> CULL_VISITOR is allowed to call osg::Group::traverse(nv); at 
> least once at the start. This seems to address the problem, 
> albeit in a kludgy sort of way. I'd like to know if:
> 
> - this is a new OSG bug?

Are you saying you tried this same thing in v2.2 and the problem didn't
occur?
   -Paul

> - anyone else is experiencing this?
> - or perhaps I'm abusing things in such way that is ill-advised?
> 
> Comments?
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org

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

Re: [osg-users] osgChunkLOD

[Sergey Kurdakov]

Hello Joseph,

there is osgchunklod derived code for osg in csp project
http://csp.sourceforge.net/
look for chunklod folder in source

Regards
Sergey

On Feb 13, 2008 12:19 AM, Joseph Mahsman  wrote:
> Does anyone know where I can find a copy of the archive from Vladimir's 
> website? His site is down, and I haven't had luck in finding it via Google.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgChunkLOD

[Norman Vine]

Joseph Mahsman writes
> 
> Does anyone know where I can find a copy of the archive from 
> Vladimir's website? His site is down, and I haven't had luck 
> in finding it via Google.


http://web.archive.org/web/20070428001632/http://www.vlad1.com/~vladimir/pro
jects/osg/osgChunkLod-0.1.tar.gz



> 
> 

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

Re: [osg-users] osgChunkLOD

[Jean-Sébastien Guay]

Hello Joseph,

> Does anyone know where I can find a copy of the archive from Vladimir's 
> website? His site is down, and I haven't had luck in finding it via Google.

Did you try www.archive.org? It's usually pretty reliable, if a bit slow 
sometimes. And it doesn't store zips/tarballs...

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

[Joseph Mahsman]

Does anyone know where I can find a copy of the archive from Vladimir's
website? His site is down, and I haven't had luck in finding it via Google.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] traversal question w/latest developer release - black nodes

[sherman wilcox]

I have a class that inherits from osg::Group. In this class I'm
overriding the traverse function. It is written in such a way that the
CULL_VISITOR doesn't have an opportunity to call
osg::Group::traverse(nv). When I add this object to the scenegraph all
the nodes in my scene go black. Even if this class is a child - all
the nodes (including parent nodes) appear black.

What I did to patch things is to hack my class such that the
CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least
once at the start. This seems to address the problem, albeit in a
kludgy sort of way. I'd like to know if:

- this is a new OSG bug?
- anyone else is experiencing this?
- or perhaps I'm abusing things in such way that is ill-advised?

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

Re: [osg-users] debug build of plugins and wrappers on linux

[David Callu]

Hi Manu,

This is normal. I don't know the reason but this is the correct behaviors.
Perhaps another could explain this choice.

HTH
David Callu

2008/2/12, Emmanuel Roche <[EMAIL PROTECTED]>:
>
> Hi everyone,
>
> I tryed a debug built of OSG 2.2.0 on linux (gcc4 + cmake)
>
> everything is already, no compilation issues, but still I end up with main
> libraries correctly named (ie with the final "d" standing for "debug")
> whereas the plugins and wrappers don't have that final "d"... Is it normal ?
> if yes, well, why ? and if not, what did I miss in the configuration ?
>
> regards,
> Manu.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ANN: osgPython (SWIG) 2.2.0

[Hartmut Seichter]

Hi René,

I added you to the project. Feel free to add the CMake files etc. pp. As 
somebody down in the thread suggested I might change the layout to the 
traditional trunk/branches/tags layout

Cheers,
Hartmut


René Molenaar wrote:
> I just separated an osgswig cmake project from our larger Library.
> 
> Tomorrow I can try to build some of your version of the wrappers in this 
> structure.
> (our version has changed a version of yours here and there).
> 
> You can add me to the Project members of the google code page?
> I saw another member on there, I worked with him to create our current 
> version.
> He makes great use of osgPython in combination with IPython gtk and the 
> rest
> of our Library.
> 
> Cheers,
> 
> René
> 
> 
> 2008/2/12, Hartmut Seichter <[EMAIL PROTECTED] 
> >:
> 
> 
> Hi there,
> 
> I updated the SWIG based python bindings.
> 
> http://code.google.com/p/osgswig/
> 
> Please test and break it.
> 
> Some, hopefully, clarifying words about licensing:
> 
> The generating scripts are under the MIT license. The modules directly
> derived from OpenSceneGraph are following the OSGPL v0.0 or the
> appropriate licenses.
> 
> The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of
> osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are
> using this module you also agree to follow the licensing terms of the
> GPLv2.
> 
> Shameless plug :)
> 
> If you need a commercial license for osgART or features beyond marker
> based tracking please contact ARToolworks Inc.
> (http://www.artoolworks.com/)
> 
> Cheers,
> Hartmut
> ___
> 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

[Jean-Sébastien Guay]

Hello Wojtek,

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

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?

Any guidance in this would be useful. 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] ANN: osgPython (SWIG) 2.2.0

[René Molenaar]

I checked and it worked with the word trunk removed,
so try to checkout http://osgswig.googlecode.com/svn/

svn checkout http://osgswig.googlecode.com/svn/ osg-swig-read-only

René


2008/2/12, Jeremy Moles <[EMAIL PROTECTED]>:
>
> Just as a head up, it doesn't look like the project was created using
> the standard "trunk/tags/branches" layout, so the link that the Google
> Source tab provides is wrong...
>
> On Tue, 2008-02-12 at 19:07 +0100, René Molenaar wrote:
> > Swig wrappers for OpenSceneGraph Python and Perl
> >
> > These files are part of: The VRmeer Library - Delft University of
> > Technology
> >
> > The files are based on osgswig (http://code.google.com/p/osgswig/)
> > with some additions and CMake files.
> >
> > (I currenlty use swigwin 1.3.29 and the current svn trunk of osg but
> > other platform and versions are also being used. There is only one
> > example, all our other examples make heavy use of
> > The VRmeer Library and the vrmswig library.)
> >
> > You can also just copy the needed cmake files and place them in the
> > right
> > directories of the online version. To use cmake to build your project.
> >
> > Good Luck.
> >
> > Rene Molenaar
> >
> >
> > 2008/2/12, Luigi Calori <[EMAIL PROTECTED]>:
> > I would also be interested in Cmake osgswig building
> > I, as a novice in both python and Lua, would greatly
> > appreciate any
> > script example usage.
> >
> > I' m trying to use the binary version of osgSwig, it seems
> > working well
> > but some further python example would really help
> >
> > Is this the right place to ask question regarding osgswig?
> >
> > thanks in advance and compliments for the work
> >
> >
> > Luigi
> >
> > René Molenaar wrote:
> >
> > > I just separated an osgswig cmake project from our larger
> > Library.
> > >
> > > Tomorrow I can try to build some of your version of the
> > wrappers in
> > > this structure.
> > > (our version has changed a version of yours here and there).
> > >
> > > You can add me to the Project members of the google code
> > page?
> > > I saw another member on there, I worked with him to create
> > our current
> > > version.
> > > He makes great use of osgPython in combination with IPython
> > gtk and
> > > the rest
> > > of our Library.
> > >
> > > Cheers,
> > >
> > > René
> > >
> > >
> > > 2008/2/12, Hartmut Seichter <[EMAIL PROTECTED]
> > > >:
> > >
> > >
> > > Hi there,
> > >
> > > I updated the SWIG based python bindings.
> > >
> > > http://code.google.com/p/osgswig/
> > >
> > > Please test and break it.
> > >
> > > Some, hopefully, clarifying words about licensing:
> > >
> > > The generating scripts are under the MIT license. The
> > modules directly
> > > derived from OpenSceneGraph are following the OSGPL v0.0
> > or the
> > > appropriate licenses.
> > >
> > > The HITLabNZ (http://www.hitlabnz.org) is promoting the
> > GPL version of
> > > osgART 1.1, ARToolKit for OpenSceneGraph, with this
> > release. If
> > > you are
> > > using this module you also agree to follow the licensing
> > terms of the
> > > GPLv2.
> > >
> > > Shameless plug :)
> > >
> > > If you need a commercial license for osgART or features
> > beyond marker
> > > based tracking please contact ARToolworks Inc.
> > > (http://www.artoolworks.com/)
> > >
> > > Cheers,
> > > Hartmut
> > > ___
> > > 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.openscen

Re: [osg-users] Test www.osgChina.org . Normal?

[Emmanuel Roche]

I'm in France, it doesn't work at all for me.

2008/2/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> FreeSouth wrote:
> >
> > Hello all :
> >Somebody found that He(at Singapore) cann't visit 
> > www.osgChina.org(located HangZhou China.
> >I don't know this site can be visited normally or not at other
> country. Thanks All.
> > Yang ShiXing
>
> very slow but it works from europe
>
> ___
> 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] Test www.osgChina.org . Normal?

[Bob Huebert]

Reachable from Alaska as well.

Nice job with the site!

-bob

On Tue, 12 Feb 2008, Jean-S?bastien Guay wrote:


Hello,


Hello all :
   Somebody found that He(at Singapore) cann't visit www.osgChina.org
(located HangZhou China.
   I don't know this site can be visited normally or not at other
country. Thanks All.
Yang ShiXing


very slow but it works from europe


Seems to work from Canada as well.

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] ANN: osgPython (SWIG) 2.2.0

[Jeremy Moles]

Just as a head up, it doesn't look like the project was created using
the standard "trunk/tags/branches" layout, so the link that the Google
Source tab provides is wrong...

On Tue, 2008-02-12 at 19:07 +0100, René Molenaar wrote:
> Swig wrappers for OpenSceneGraph Python and Perl
> 
> These files are part of: The VRmeer Library - Delft University of
> Technology
> 
> The files are based on osgswig (http://code.google.com/p/osgswig/)
> with some additions and CMake files. 
> 
> (I currenlty use swigwin 1.3.29 and the current svn trunk of osg but
> other platform and versions are also being used. There is only one 
> example, all our other examples make heavy use of 
> The VRmeer Library and the vrmswig library.)
> 
> You can also just copy the needed cmake files and place them in the
> right
> directories of the online version. To use cmake to build your project.
> 
> Good Luck.
> 
> Rene Molenaar
> 
> 
> 2008/2/12, Luigi Calori <[EMAIL PROTECTED]>:
> I would also be interested in Cmake osgswig building
> I, as a novice in both python and Lua, would greatly
> appreciate any
> script example usage.
> 
> I' m trying to use the binary version of osgSwig, it seems
> working well
> but some further python example would really help
> 
> Is this the right place to ask question regarding osgswig?
> 
> thanks in advance and compliments for the work
> 
> 
> Luigi
> 
> René Molenaar wrote:
> 
> > I just separated an osgswig cmake project from our larger
> Library.
> >
> > Tomorrow I can try to build some of your version of the
> wrappers in
> > this structure.
> > (our version has changed a version of yours here and there).
> >
> > You can add me to the Project members of the google code
> page?
> > I saw another member on there, I worked with him to create
> our current
> > version.
> > He makes great use of osgPython in combination with IPython
> gtk and
> > the rest
> > of our Library.
> >
> > Cheers,
> >
> > René
> >
> >
> > 2008/2/12, Hartmut Seichter <[EMAIL PROTECTED]
> > >:
> >
> >
> > Hi there,
> >
> > I updated the SWIG based python bindings.
> >
> > http://code.google.com/p/osgswig/
> >
> > Please test and break it.
> >
> > Some, hopefully, clarifying words about licensing:
> >
> > The generating scripts are under the MIT license. The
> modules directly
> > derived from OpenSceneGraph are following the OSGPL v0.0
> or the
> > appropriate licenses.
> >
> > The HITLabNZ (http://www.hitlabnz.org) is promoting the
> GPL version of
> > osgART 1.1, ARToolKit for OpenSceneGraph, with this
> release. If
> > you are
> > using this module you also agree to follow the licensing
> terms of the
> > GPLv2.
> >
> > Shameless plug :)
> >
> > If you need a commercial license for osgART or features
> beyond marker
> > based tracking please contact ARToolworks Inc.
> > (http://www.artoolworks.com/)
> >
> > Cheers,
> > Hartmut
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > 
> >
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> 
> >
> >
> >___
> >osg-users mailing list
> >osg-users@lists.openscenegraph.org
> 
> >http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[osg-users] Stereoscopy in OSG

[Renan Mendes]

Hi, everyone.

  What is OSG's support on stereoscopy? I have a dual-head video
card and I needed that the images shown in the two monitors were slightly
different in terms of view angle (my final objective, of course, is to
project these two images on a screen making use of the stereoscopic
polarized projection technique). Does anyone have any reference on the
subject? Or even some already developed code? I'd really appreciate it.

  Thanks,

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

[osg-users] ANN: osgWidget 0.1.5

[Jeremy Moles]

Finally got around to a point where I feel somewhat comfortable with
another alpha release (after renaming the project to osgWidget from
osgHUD).

No major changes from a visual standpoint, but lots has changed
internally. For example, picking has been significantly changed and I
added the ability to assign either function callbacks or class-method
callbacks to a Widget or Window, along with maintaining the ability to
simply override mouseOver, mouseDrag, etc. in a derived class.

I also added Lua and Python engine "skeletons" in this, though they
don't do anything interesting yet. However, ideally, if all goes
according to plan, you will be able to use either (or both!) scripting
engines for interfacing with osgWidget. The reason I chose to use both
instead of just Python (since I really don't have any love for Lua) is
because Python doesn't provide any way to "lock" itself down, and if a
user requires this Lua would be more appropriate (think games, like
World of Warcraft, where you want to create a modding API but want to
restrict the environment to prevent cheating, etc.) As much as I love
Python, it has no solution to this problem at the moment... 

CHANGELOG here:

http://code.google.com/p/osgwidget/source/browse/tags/0.1.5/CHANGELOG

PROJECT here:

http://osgwidget.googlecode.com

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

[osg-users] debug build of plugins and wrappers on linux

[Emmanuel Roche]

Hi everyone,

I tryed a debug built of OSG 2.2.0 on linux (gcc4 + cmake)

everything is already, no compilation issues, but still I end up with main
libraries correctly named (ie with the final "d" standing for "debug")
whereas the plugins and wrappers don't have that final "d"... Is it normal ?
if yes, well, why ? and if not, what did I miss in the configuration ?

regards,
Manu.
___
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,

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] intersect() methods in LineSegment (probably others)

[Andy Skinner]

Thanks!

Hopefully Robert can give it a look when he gets back.

thanks,
andy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien 
Guay
Sent: Tuesday, February 12, 2008 9:21 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] intersect() methods in LineSegment (probably others)

Hi Andy,

> J-S, did you get to do any timing with my proposed use of doubles in the
> intersection code?

I did some tests last night. Full results below. The "executive summary" 
is this:

For 2,244,800 samples (individual ray tests),
Floats:  113.121566 seconds (original)
Doubles: 113.954178 seconds (your patch)

Difference: ~0.730655 %

Floats:  19844.138 samples / second
Doubles: 19699.146 samples / second


So with doubles, it is less than one percent slower, which I don't think 
is significant over that many samples... I did not have the time to do 
multiple tests though (because that 0.7% might even be due to some other 
activity on my machine) but I think we can safely say it's not a 
significant difference. You can quote me on that :-)

BTW, for reference, using the kdtree took 13.366302 seconds to do the 
same thing :-) See below.

Hope this helps,

J-S


Detailed results:
===
LineSegmentIntersector, float (original)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.534819 seconds. (747.917 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.1999 seconds. (26763.4 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 13.9724 seconds. (26624 
samples/sec)


[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.7206 seconds. (29391.5 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.901 seconds. (10170.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3278 seconds. (19298.8 
samples/sec)

  Total time for loading transfer functions: 113.121566 seconds.
  Total loading/computing time: 113.657229 seconds.

Precalculation done, exiting.

===
LineSegmentIntersector, double (Andy Skinner's modification)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.524556 seconds. (762.55 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.6853 seconds. (25935.1 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 14.2079 seconds. (26182.6 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.8676 seconds. (29193.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.8934 seconds. (10172.8 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3 seconds. (19324 
samples/sec)

  Total time for loading transfer functions: 113.954178 seconds.
  Total loading/computing time: 114.479672 seconds.

Precalculation done, exiting.

===
Adrian Egli's kdtree

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Jean-Sébastien Guay]

Hi Andy,

> J-S, did you get to do any timing with my proposed use of doubles in the
> intersection code?

I did some tests last night. Full results below. The "executive summary" 
is this:

For 2,244,800 samples (individual ray tests),
Floats:  113.121566 seconds (original)
Doubles: 113.954178 seconds (your patch)

Difference: ~0.730655 %

Floats:  19844.138 samples / second
Doubles: 19699.146 samples / second


So with doubles, it is less than one percent slower, which I don't think 
is significant over that many samples... I did not have the time to do 
multiple tests though (because that 0.7% might even be due to some other 
activity on my machine) but I think we can safely say it's not a 
significant difference. You can quote me on that :-)

BTW, for reference, using the kdtree took 13.366302 seconds to do the 
same thing :-) See below.

Hope this helps,

J-S


Detailed results:
===
LineSegmentIntersector, float (original)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.534819 seconds. (747.917 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.1999 seconds. (26763.4 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 13.9724 seconds. (26624 
samples/sec)


[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.7206 seconds. (29391.5 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.901 seconds. (10170.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3278 seconds. (19298.8 
samples/sec)

  Total time for loading transfer functions: 113.121566 seconds.
  Total loading/computing time: 113.657229 seconds.

Precalculation done, exiting.

===
LineSegmentIntersector, double (Andy Skinner's modification)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.524556 seconds. (762.55 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.6853 seconds. (25935.1 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 14.2079 seconds. (26182.6 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.8676 seconds. (29193.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.8934 seconds. (10172.8 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3 seconds. (19324 
samples/sec)

  Total time for loading transfer functions: 113.954178 seconds.
  Total loading/computing time: 114.479672 seconds.

Precalculation done, exiting.

===
Adrian Egli's kdtree
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] 

Re: [osg-users] Test www.osgChina.org . Normal?

[Jean-Sébastien Guay]

Hello,

>> Hello all :
>>Somebody found that He(at Singapore) cann't visit www.osgChina.org 
>> (located HangZhou China.
>>I don't know this site can be visited normally or not at other 
>> country. Thanks All.
>> Yang ShiXing
> 
> very slow but it works from europe

Seems to work from Canada as well.

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

[Jean-Sébastien Guay]

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] ANN: osgPython (SWIG) 2.2.0

[Luigi Calori]

I would also be interested in Cmake osgswig building
I, as a novice in both python and Lua, would greatly appreciate any 
script example usage.

I' m trying to use the binary version of osgSwig, it seems working well 
but some further python example would really help

Is this the right place to ask question regarding osgswig?

thanks in advance and compliments for the work


Luigi

René Molenaar wrote:

> I just separated an osgswig cmake project from our larger Library.
>
> Tomorrow I can try to build some of your version of the wrappers in 
> this structure.
> (our version has changed a version of yours here and there).
>
> You can add me to the Project members of the google code page?
> I saw another member on there, I worked with him to create our current 
> version.
> He makes great use of osgPython in combination with IPython gtk and 
> the rest
> of our Library.
>
> Cheers,
>
> René
>
>
> 2008/2/12, Hartmut Seichter <[EMAIL PROTECTED] 
> >:
>
>
> Hi there,
>
> I updated the SWIG based python bindings.
>
> http://code.google.com/p/osgswig/
>
> Please test and break it.
>
> Some, hopefully, clarifying words about licensing:
>
> The generating scripts are under the MIT license. The modules directly
> derived from OpenSceneGraph are following the OSGPL v0.0 or the
> appropriate licenses.
>
> The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of
> osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If
> you are
> using this module you also agree to follow the licensing terms of the
> GPLv2.
>
> Shameless plug :)
>
> If you need a commercial license for osgART or features beyond marker
> based tracking please contact ARToolworks Inc.
> (http://www.artoolworks.com/)
>
> Cheers,
> Hartmut
> ___
> 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] X11 keyboard bug (+ ugly fix)

[Melchior FRANZ]

Attached is my suggested fix for the keyboard bug. The
behavior should be the same as before, except when losing
the focus (FocusOut, LeaveNotify) all keys are released
(normal keys first, modifiers at last), and on re-entering
(KeymapNotify) pressed (modifiers first, other keys afterwards).
I'll explain some more when I submit it. Please test on
different Unices, especially with multiple windows/displays.

m.
Index: include/osgViewer/api/X11/GraphicsWindowX11
===
--- include/osgViewer/api/X11/GraphicsWindowX11	(revision 7855)
+++ include/osgViewer/api/X11/GraphicsWindowX11	(working copy)
@@ -44,9 +44,11 @@
 _currentCursor(0),
 _initialized(false),
 _realized(false),
-_timeOfLastCheckEvents(-1.0)
+_timeOfLastCheckEvents(-1.0),
+_lastEventType(0)
 {
 _traits = traits;
+memset(_keyMap, 0, 32);
 
 init();
 
@@ -159,6 +161,7 @@
 
 void transformMouseXY(float& x, float& y);
 void adaptKey(XKeyEvent& keyevent, int& keySymbol, unsigned int& modifierMask);
+int getModifierMask();
 
 bool_valid;
 Display*_display;
@@ -177,7 +180,9 @@
 bool_ownsWindow;
 
 double  _timeOfLastCheckEvents;
+int _lastEventType;
 
+char_keyMap[32];
 std::map _mouseCursorMap;
 };
 
Index: src/osgViewer/GraphicsWindowX11.cpp
===
--- src/osgViewer/GraphicsWindowX11.cpp	(revision 7855)
+++ src/osgViewer/GraphicsWindowX11.cpp	(working copy)
@@ -173,6 +173,23 @@
 return s_x11KeyboardMap.remapKey(key);
 }
 
+// Functions to handle key maps of type char[32] as contained in
+// a KeymapNotify event structure or returned by XQueryKeymap().
+static inline bool keyMapGetKey(char* map, unsigned int key)
+{
+return (map[(key & 0xff) / 8] & (1 << (key & 7))) != 0;
+}
+
+static inline void keyMapSetKey(char* map, unsigned int key)
+{
+map[(key & 0xff) / 8] |= (1 << (key & 7));
+}
+
+static inline void keyMapClearKey(char* map, unsigned int key)
+{
+map[(key & 0xff) / 8] &= ~(1 << (key & 7));
+}
+
 GraphicsWindowX11::~GraphicsWindowX11()
 {
 close(true);
@@ -693,7 +710,8 @@
 
 XSelectInput( _eventDisplay, _window, ExposureMask | StructureNotifyMask | 
  KeyPressMask | KeyReleaseMask |
- PointerMotionMask  | ButtonPressMask | ButtonReleaseMask);
+ PointerMotionMask | ButtonPressMask | ButtonReleaseMask |
+ KeymapStateMask | FocusChangeMask | LeaveWindowMask );
 
 XFlush( _eventDisplay );
 XSync( _eventDisplay, 0 );
@@ -917,6 +935,119 @@
 osg::notify(osg::INFO)<<"GravityNotify event recieved"< modifier;
+KeyCode *m = mkm->modifiermap;
+for (int i = 0; i < mkm->max_keypermod * 8; i++, m++)
+{
+if (*m) modifier[*m] = true;
+}
+
+// Send fake-releases in two passes for all keys reported as pressed.
+// (pass 0: normal keys, pass 1: modifier keys)
+for (int pass = 0; pass < 2; pass++)
+{
+for (unsigned int key = 8; key < 256; key++)
+{
+if (!keyMapGetKey(_keyMap, key)) continue;
+bool isModifier = modifier.find(key) != modifier.end();
+if (pass == 0 && !isModifier || pass == 1 && isModifier)
+{
+XKeyEvent event;
+event.type = KeyRelease;
+event.serial = 0;
+event.send_event = True;
+event.display = display;
+event.window = _window;
+event.subwindow = 0;
+event.time = eventTime;
+event.x = 0;
+event.y = 0;
+event.x_root = 0;
+event.y_root = 0;
+event.state = getModifierMask();
+event.keycode = key;
+event.same_screen = True;
+
+int keySymbol = 0;
+unsigned int modifierMask = 0;
+adaptKey(event, keySymbol, modifierMask);
+getEventQueue()->keyRelease(keySymbol, eventTime);
+keyMapClearKey(_keyMap, key);
+}
+}
+}
+break;
+}
+
+case KeymapNotify :
+  

Re: [osg-users] Test www.osgChina.org . Normal?

[Miao]

it works from Japan.
Hope you make osg popular in China.

  - Original Message - 
  From: Adrian Egli OpenSceneGraph (3D)
  To: OpenSceneGraph Users
  Sent: Tuesday, February 12, 2008 7:44 PM
  Subject: Re: [osg-users] Test www.osgChina.org . Normal?


  i can not visit the site www.osgchina.org form university network 
(switzerland)




  2008/2/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
FreeSouth wrote:
>
> Hello all :
>Somebody found that He(at Singapore) cann't visit www.osgChina.org 
(located HangZhou China.
>I don't know this site can be visited normally or not at other 
country. Thanks All.
> Yang ShiXing

very slow but it works from europe

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





  -- 
  
  Adrian Egli


--


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

Re: [osg-users] Test www.osgChina.org . Normal?

[Adrian Egli OpenSceneGraph (3D)]

i can not visit the site www.osgchina.org form university network
(switzerland)



2008/2/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> FreeSouth wrote:
> >
> > Hello all :
> >Somebody found that He(at Singapore) cann't visit 
> > www.osgChina.org(located HangZhou China.
> >I don't know this site can be visited normally or not at other
> country. Thanks All.
> > Yang ShiXing
>
> very slow but it works from europe
>
> ___
> 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] Test www.osgChina.org . Normal?

[[EMAIL PROTECTED]]

FreeSouth wrote:
 
Hello all :

   Somebody found that He(at Singapore) cann't visit www.osgChina.org (located 
HangZhou China.
   I don't know this site can be visited normally or not at other country. 
Thanks All.
Yang ShiXing


very slow but it works from europe
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Test www.osgChina.org . Normal?

[FreeSouth]

 
Hello all :
   Somebody found that He(at Singapore) cann't visit www.osgChina.org (located 
HangZhou China.
   I don't know this site can be visited normally or not at other country. 
Thanks All.
Yang ShiXing___
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

[osg-users] Setting Home position in OSG Viewer

[Image Modelling Limited (IML)]

Hi all,

New to this list so please be kind

I currently use the good old SGI Perfly viewer to look at individual models 
and utilise the option in perfly to set the initial start position and 
attitude using the -p and -e options.

It is currently possible, or could it be possible, to do this in the 
OSGViewer. I have had a look and play with it but it wasn't immediatly 
obvious.

Just for the record, I am not a programmer but a modeller, so going in and 
hacking the code is not really an option.

I would really like to get to use the osg viwer as I would guess the 
OpenFlight loader support is at a newer version that the 15.7 I am fixed at 
in perfly...

TIA,

John Wintle
Image Modelling Limited.
www.image-modelling.co.uk 

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

Re: [osg-users] Congratulations ag! OpenSceneGraph Chinese Mirror have been finished , try it.

[FreeSouth]

Hi Jean-S:

  Thank you for your attation. I am waitting his back.

  "Gung hey fat choi!" He, he.

ShiXing

>Hello ShiXing,

>> I want to know how to applicate a link at openscenegraph.org to 
>> osgChina, what should I do .

>>Unfortunately the front page on openscenegraph.org is protected and 
>>cannot be edited. We will have to wait till Robert comes back from his 
>>vacation to get the link to your site there.

>>J-S

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

Re: [osg-users] Congratulations ag! OpenSceneGraph Chinese Mirror have been finished , try it.

[FreeSouth]

Hi John Donovan:

  He He, The same to you "Gung hey fat choi!".

  If you go to China some day , I'd like to teach you about Chinese. He he.

YangShiXing___
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

[Sebastian Messerschmidt]

Hi,

I've implemented this and it works reasonably well. But there is a catch 
though ...
When creating my shadowed scene (usually by loading elements) I set the 
ShadowMap to "updateMode" in order to render the new Elements.
However, due to multithreading I need a way to be certain, that all 
elements are drawn. Is there a callback I can use?

cheers
Sebastian
> Hi Wojciech,
>
> Thanks for clarifying. I was looking into it yesterday but didn't find 
> the right spots.
> Maybe this could be integrated into the current implementation. I'm 
> pretty sure it might be usefull for other users too.
>
>   
>> 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
>>
>>   
>> 
>
> ___
> 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

[Sebastian Messerschmidt]

Hi Wojciech,

Thanks for clarifying. I was looking into it yesterday but didn't find 
the right spots.
Maybe this could be integrated into the current implementation. I'm 
pretty sure it might be usefull for other users too.

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

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