date:20081125


Hello Art,


I would propose to use post processing outline technique.


Interesting technique, but unfortunately, integrating osgPPU into our 
framework and doing all rendering through it would be too much work for 
a simple outline technique.


That being said, I am planning a complete redesign of our effect/shader 
architecture in the not too distant future. At that point, the whole 
architecture might be RTT- or MRT-based, in which case it will probably 
use osgPPU, and then using osgPPU for the outline effect would be 
feasible :-)


I'm still wondering why the technique I have is so slow (over 3x cull 
and draw time, and over 10x GPU time versus rendering the object without 
outline). I'm thinking I'd like to run the code through gDebugger to get 
a clearer picture. I just thought someone might have implemented a 
similar technique and might have an idea.


Still, thanks for chiming in, and I do like osgPPU - I just can't use it 
for the framework we use at work for now.


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] Outline technique that doesn't triple (or worse) my frame time?


Hi all,

Forgot to mention the timings below are with a release mode build of our 
application. I'll see if I can transpose the results in a basic 
osgviewer-based app using the same technique... Perhaps there's 
something screwy with our scene graph.


In any case, if anyone has any comments about the results and questions 
below, I'd be very interested in reading them. Thanks,


J-S


The following random bytes came from Jean-Sébastien Guay's keyboard :

Hi all,

As I said before, I'm working on a modeling-type application. To give 
feedback of which object is selected, I'd like to outline it in white 
(or any color).


I've currently got two implementations of an outline effect (using 
osgFX::Effect), one of which uses the stencil buffer, the other which 
doesn't but does basically the same things (render back faces as lines, 
with a line width of 3, with a depth function of LEQUAL, etc.). Pretty 
classic.


In both cases, my cull, draw and GPU times jump inordinately high when 
the effect is active. For a pretty simple object, I get the following:


Without effect:
Cull 0.4
Draw 0.5
GPU  0.12

With effect:
Cull 1.43
Draw 2.3
GPU  2.7

That seems apalling to me... I would think the time would *at most* 
double, and I would be hesitant to use the effect if it did. So more 
than triple is just too much.


Is there some explanation for this? More importantly, is there some 
other technique I could use to get an outline around my object, which 
would have less of an impact? What do others do to get similar effects?


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] Dual screen support on Linux using TwinView

2008-11-25 Thread Michael

Hi Robert

Thanks for the clarrification. After reading through the OpenSceneGraph API
docs we definitely require two views. So to summarise

2 monitors (projectors)
1 View on each monitor
1 XScreen, and therefore 1 context (if possible).

Sorry for not giving all this information up front but I have only written
about 1/3 of the codebase, so I have to go fishing through the code. I
appreciate the help!

Thanks
Michael



On Fri, Nov 21, 2008 at 8:10 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:

> HI Michael,
>
> Does you two "views" move together, i.e. they look different
> directions but as the viewpoint moves around both projector outputs
> should update relative to this?  If this is the case they you have one
> View but with two slave Cameras each with a project and view offset
> from the View's master Camera.
>
> If two projector outputs are wholly independent w.r.t viewpoint, and
> require same camera controls such as seprate CameraManipulator then
> you do have a case which is logically two different views.
>
> Robert.
>
> On Thu, Nov 20, 2008 at 11:52 PM, Michael <[EMAIL PROTECTED]>
> wrote:
> > Hey Robert
> >
> > We have 2 separate logical views (I guess). Essentially we have 2
> projectors
> > that can each be placed at any location and orientation in the room and
> they
> > project onto objects in the room. This is not a tiled display, and we are
> > not worried about overlap. We are also doing some render to texture
> > operations which is why we have different views. Each monitor output is
> > driving a single projector. So, we have 2 projectors and a couple of RTT
> > cameras.
> >
> > The projectors have their own projection and view matrices, but share the
> > same scene graph data for drawing. One of the projectors does shadow
> removal
> > for the other one, so we need to control the render order. So, we need
> each
> > monitor output to drive one of our views for the projector, using the 1
> > graphics context.
> >
> > I appreciate the help (and patience!)
> >
> > Cheers
> > Michael
> >
> >
> > On Thu, Nov 20, 2008 at 7:38 PM, Robert Osfield <
> [EMAIL PROTECTED]>
> > wrote:
> >>
> >> Hi Michael,
> >>
> >> On Thu, Nov 20, 2008 at 12:09 AM, Michael <
> [EMAIL PROTECTED]>
> >> wrote:
> >> > This fails on the second display because OSG can't connect to screen
> >> > 0:1,
> >> > because there is only 1 xscreen. Clearly I am doing this wrong, but
> I'm
> >> > not
> >> > sure of the correct way.
> >>
> >> If you have only only X screen then you'll only be able to open up a
> >> window on that one... so you'll need to use the screenNum set to 0 fro
> >> both contexts, or
> >>
> >> > Something like this?
> >> > 1. Create a single GraphicsContext on screen 0, with width=2048 (both
> >> > displays)
> >> > 2. Create my views, and somehow tell each one to only render on half
> of
> >> > the
> >> > context?
> >>
> >> If you a grabbing the whole of both displays I would create a single
> >> graphics context that goes across both physical displays.  Otherwise
> >> you'll need to create two graphics contexts on the same X11 screenNum
> >> but with the second window starting at a xpos of 1024.
> >>
> >> Now what to do about the views depends upon you actual needs.  Do you
> >> have two separate logical views of doing you have  single view that is
> >> just made up of two cameras (like looking out of two adjacent
> >> real-world windows that share the same view).  If you have only single
> >> view, then do the two halves of it but up against each other or do
> >> they overlap?
> >>
> >> Could you have a bash at explain what you are specifically trying to
> >> achieve as the advice to give is different for all the different
> >> cases.
> >>
> >> 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] OSG_GECKO (xulrunner headers)

2008-11-25 Thread Bob Huebert


Thank you! Using the Ubuntu repo for the libxul kit was the hint I needed.

I grabbed this: 
http://archive.ubuntu.com/ubuntu/pool/universe/x/xulrunner/xulrunner_1.8.1.16+nobinonly.orig.tar.gz


Albeit I built on FC7, I now have a osgdb_gecko.so!

Note that it was necessary to create links from headers in widget, necko, 
nkcache, docshell, dom, xpcom, string, xulapp, pref, js, gfx, webbrwsr, 
layout, content, locale, and view to the parent directory. I also needed 
to link js/jsproto.tbl to the parent as well. I presume this is the result 
of building the package instead of using Ubuntu's install method.


best regards,
bob

Date: Tue, 25 Nov 2008 19:59:51 +
From: "Robert Osfield" <[EMAIL PROTECTED]>
Subject: Re: [osg-users] OSG_GECKO (xulrunner headers)
To: "OpenSceneGraph Users" 
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

Hi Bob,

I just pulled down libxul and associated dev package from the Ubuntu
repositories.  It worked just fine under Kubuntu 7.10 and 8.10.

Robert.


Bob Huebert email: [EMAIL PROTECTED]
Visualization Systems Analyst   voice: (907) 450-8638
Arctic Region Supercomputing Center   FAX: (907) 450-8601
University of Alaska FairbanksWWW: http://www.arsc.edu/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Outline technique that doesn't triple (or worse) my frame time?

2008-11-25 Thread Art Tevs

Hi Jean-Sebastian,

I would propose to use post processing outline technique. I have no references 
how to do this, but here an idea how I think it could be implemented:

1) render selected object into a stencil texture (hence you got 1 where object 
is seen and 0 otherwise)

2) use a shader to compute absolute gradient of this texture 
grad.x = abs(texel(x+1,y) - texel(x,y)); 
grad.y = abs(texel(x,y+1) - texel(x,y));

3) now blur this gradient texture

4) multiply the blurred gradient texture with inverse stencil mask you have 
created before
 - so you get blurred values outside of the object and inside of the objet 
nothing is blurred


5) render the so computed gradient texture over you scene view texture


I think, this is a simpliest and efficientest way to create an outline around 
an object. Instead of blurring one can use something like a growing filter, so 
in a specified window of i.e. 5 pixel set to 1 if one of the mask pixels is 
already 1. Afterwards blur it, to get nice edges of your outline. Of course one 
has to deal with alpha values correctly to get the outline blurred perfectly

This all things can be easyly implemented with osgPPU. But I think you know 
that already ;)

Best regards,
art




--- Jean-Sébastien Guay <[EMAIL PROTECTED]> schrieb am Di, 25.11.2008:

> Von: Jean-Sébastien Guay <[EMAIL PROTECTED]>
> Betreff: [osg-users] Outline technique that doesn't triple (or worse) my 
> frame time?
> An: "OpenSceneGraph Users" 
> Datum: Dienstag, 25. November 2008, 22:47
> Hi all,
> 
> As I said before, I'm working on a modeling-type
> application. To give feedback of which object is selected,
> I'd like to outline it in white (or any color).
> 
> I've currently got two implementations of an outline
> effect (using osgFX::Effect), one of which uses the stencil
> buffer, the other which doesn't but does basically the
> same things (render back faces as lines, with a line width
> of 3, with a depth function of LEQUAL, etc.). Pretty
> classic.
> 
> In both cases, my cull, draw and GPU times jump
> inordinately high when the effect is active. For a pretty
> simple object, I get the following:
> 
> Without effect:
> Cull 0.4
> Draw 0.5
> GPU  0.12
> 
> With effect:
> Cull 1.43
> Draw 2.3
> GPU  2.7
> 
> That seems apalling to me... I would think the time would
> *at most* double, and I would be hesitant to use the effect
> if it did. So more than triple is just too much.
> 
> Is there some explanation for this? More importantly, is
> there some other technique I could use to get an outline
> around my object, which would have less of an impact? What
> do others do to get similar effects?
> 
> 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

Re: [osg-users] Interest in DirectShow plugin for OpenSceneGraph?

2008-11-25 Thread Brad Colbert

Definitely!  Open source right?

I believe you can take advantage of direct to texture loads similar to
what the QuickTime library offers on OSX (sadly not for Windows).

-B
 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:osg-users-
> [EMAIL PROTECTED] On Behalf Of Jason Beverage
> Sent: Saturday, November 22, 2008 3:07 PM
> To: osg users
> Subject: [osg-users] Interest in DirectShow plugin for OpenSceneGraph?
> 
> Hi all,
> 
> We're currently developing a DirectShow plugin for OpenSceneGraph and
I
> wanted to see if there was anyone else in the community that would be
> interested in this capability.
> 
> Thanks!
> 
> Jason
> 
> -
> Jason Beverage
> Pelican Mapping
> http://www.pelicanmapping.com/

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

[osg-users] DatabasePager and memory

2008-11-25 Thread Brad Colbert

Hi Folks,

We have an .ive PagedLOD database that is high resolution in both
textures and poly's.  Understandably in certain situations we are able
to clobber both the memory on the machine and GPU memory when the pager
tries to page in more data then is possible to hold.  The result is that
the database pager thread dies and does not deallocate the memory it was
holding onto.

We have played with a couple settings such as:

* Hoping this forces immediate deletion.
databasePager->setExpiryDelay( 0.0 );

* Not sure if this helps.
databasePager->setDoPreCompile( true );

And we have played with the LOD scale but we still have some issues.

Is it possible to detect the death of the paging thread, and if so, can
we flush the nodes it was holding onto and restart it?

Any other ideas would be greatly appreciated.

-Brad

---
Brad Colbert
Renaissance Sciences Corporation
W: 480 374-5073 x:5073
F: 425 675-8044

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

[osg-users] Advice: Adding ffmpeg to OSG via osgViewer

2008-11-25 Thread Fred

Background:
I need to create a service/daemon running delta3D to which an
application running a FlashPlayer 10 video connects for its video
feed.
Presently, I am running ffmpeg -f x11grab ...  to capture the osg
display and converting to flv and streaming that via ffserver.
Yuck.

Plan:
Incorporate ffmpeg into osgViewer in a way that the FlashPlayer
NetConnectors can subscribe directly to it (in a multicast way).
This is my current plan but if there is a better way that would be
more generally beneficial I'm open to suggestions.


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

[osg-users] Outline technique that doesn't triple (or worse) my frame time?


Hi all,

As I said before, I'm working on a modeling-type application. To give 
feedback of which object is selected, I'd like to outline it in white 
(or any color).


I've currently got two implementations of an outline effect (using 
osgFX::Effect), one of which uses the stencil buffer, the other which 
doesn't but does basically the same things (render back faces as lines, 
with a line width of 3, with a depth function of LEQUAL, etc.). Pretty 
classic.


In both cases, my cull, draw and GPU times jump inordinately high when 
the effect is active. For a pretty simple object, I get the following:


Without effect:
Cull 0.4
Draw 0.5
GPU  0.12

With effect:
Cull 1.43
Draw 2.3
GPU  2.7

That seems apalling to me... I would think the time would *at most* 
double, and I would be hesitant to use the effect if it did. So more 
than triple is just too much.


Is there some explanation for this? More importantly, is there some 
other technique I could use to get an outline around my object, which 
would have less of an impact? What do others do to get similar effects?


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] osgswig manifest blues

2008-11-25 Thread Randolph Fritz

OK, now that I've got the files to build, how do I avoid the R6034 
(manifest file) error when I move them into site-packages? There doesn't 
seem to be a cmake generated install script, that would presumably take 
care of the problem.


Randolph

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

Re: [osg-users] OSG_GECKO (xulrunner headers)

Hi Bob,

I just pulled down libxul and associated dev package from the Ubuntu
repositories.  It worked just fine under Kubuntu 7.10 and 8.10.

Robert.

On Tue, Nov 25, 2008 at 7:31 PM, Bob Huebert <[EMAIL PROTECTED]> wrote:
> Hi Robert & Adrian,
>
>  I too am following the development of osgbrowser, but am not having success
> in setting up my environment for the build.
>
>  Going on the presumption that the required lkibraries & headers would be
> within the xulrunner-1.8.1.3.en-US.linux-i686.sdk-20080128.tar as downloaded
> from
> ftp://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/
>
>  This package contains no header files, although the libraries are present.
>
>  I had a go with the gecko-sdk, but same story there - no headers.
>
>  I hate to be dense, but could you provide the location of the package you
> used to satisfy the requirements? I'm building in non-system space, so
> tarballs are preferred.
>
> thanks in advance!
>
> -bob
>
> Date: Mon, 24 Nov 2008 19:18:24 +
> From: "Robert Osfield" <[EMAIL PROTECTED]>
> Subject: Re: [osg-users] OSG_GECKO
> To: "OpenSceneGraph Users" 
> Message-ID:
><[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Adrian,
>
> You'll need libxul 1.8.x, it's not compatible with 1.9.x
>
> A copy and paste form ccmake .
>
> XUL_DIR  /usr/lib/xulrunner
>  XUL_INCLUDE_DIR  /usr/include/xulrunner
>  XUL_LIBRARY  /usr/lib/libxul.so
>  XUL_MOZJS_LIBRARY/usr/lib/libmozjs.so
>  XUL_NSS_LIBRARY  /usr/lib/libnss3.so
>  XUL_PLUGIN_LIBRARY   /usr/lib/libplds4.so
>  XUL_XPCOM_LIBRARY/usr/lib/libxpcom.so
>
> Robert.
>
> On Mon, Nov 24, 2008 at 6:12 PM, Adrian Egli OpenSceneGraph (3D)
> <[EMAIL PROTECTED]> wrote:
>>
>> Hi Robert,
>>
>> can you poste a screen shot of your CMake config : cmake -i .
>> i downloaded windows gecko sdk (xul-runner sdk) and also gecko, so i
>
> like to
>>
>> get running the gecko plugin under windows, may i can work out what the
>> variables correspond to.
>>
>> /adrian
>>
>> --
>> 
>> Adrian Egli
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> 
> Bob Huebert email: [EMAIL PROTECTED]
> Visualization Systems Analyst   voice: (907) 450-8638
> Arctic Region Supercomputing Center   FAX: (907) 450-8601
> University of Alaska FairbanksWWW: http://www.arsc.edu/
> ___
> osg-users 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] OSG_GECKO (xulrunner headers)

2008-11-25 Thread Bob Huebert


Hi Robert & Adrian,

  I too am following the development of osgbrowser, but am not having 
success in setting up my environment for the build.


  Going on the presumption that the required lkibraries & headers would be 
within the xulrunner-1.8.1.3.en-US.linux-i686.sdk-20080128.tar as 
downloaded from 
ftp://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/sdk/


  This package contains no header files, although the libraries are 
present.


  I had a go with the gecko-sdk, but same story there - no headers.

  I hate to be dense, but could you provide the location of the package 
you used to satisfy the requirements? I'm building in non-system space, so 
tarballs are preferred.


thanks in advance!

-bob

Date: Mon, 24 Nov 2008 19:18:24 +
From: "Robert Osfield" <[EMAIL PROTECTED]>
Subject: Re: [osg-users] OSG_GECKO
To: "OpenSceneGraph Users" 
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

Hi Adrian,

You'll need libxul 1.8.x, it's not compatible with 1.9.x

A copy and paste form ccmake .

XUL_DIR  /usr/lib/xulrunner
 XUL_INCLUDE_DIR  /usr/include/xulrunner
 XUL_LIBRARY  /usr/lib/libxul.so
 XUL_MOZJS_LIBRARY/usr/lib/libmozjs.so
 XUL_NSS_LIBRARY  /usr/lib/libnss3.so
 XUL_PLUGIN_LIBRARY   /usr/lib/libplds4.so
 XUL_XPCOM_LIBRARY/usr/lib/libxpcom.so

Robert.

On Mon, Nov 24, 2008 at 6:12 PM, Adrian Egli OpenSceneGraph (3D)
<[EMAIL PROTECTED]> wrote:

Hi Robert,

can you poste a screen shot of your CMake config : cmake -i .
i downloaded windows gecko sdk (xul-runner sdk) and also gecko, so i 

like to

get running the gecko plugin under windows, may i can work out what the
variables correspond to.

/adrian

--

Adrian Egli

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


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



Bob Huebert email: [EMAIL PROTECTED]
Visualization Systems Analyst   voice: (907) 450-8638
Arctic Region Supercomputing Center   FAX: (907) 450-8601
University of Alaska FairbanksWWW: http://www.arsc.edu/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Packaging granularity + platform specific scripts

2008-11-25 Thread R Fritz

Different platforms use different levels of granularity.  Mac OS  
bundles libraries into "frameworks", which can themselves be placed in  
application bundles, or installed for systemwide use.  This is a very  
coarse level of granularity.   I think OSG would probably best fits  
what Apple calls an "umbrella framework"--a framework which contains  
frameworks.  I'm not too clear--yet, anyhow--on how Macs deal with  
framework dependencies on other frameworks and libraries; I have the  
impression it's not automatic but instead handled ad-hoc by the  
installer script or by the app.


Randolph

On Nov 25, 2008, at 7:09 AM, Robert Osfield wrote:


Right now we have the OSG itself has an
OpenSceneGraph/packaging/pkconfig directory, and this contains an
openthreads.pc and openscenegraph.pc files.  Looking at these files
they don't lists all the OSG dependencies, and they obviously don't
break it down like I'm advocating above.  I'm also aware that on
debain there are plenty of other configuration files associated with
the debian packaging.   What I feel would be appropriate would for us
to centralise this, and make full use of the existing packing
directory, full it out as required.  I also feel the granularity needs
to be addressed - but what sets of packaging and naming would be
appropriate?


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

Re: [osg-users] Packaging granularity + platform specific scripts

Ooops! Sorry, it seems my mail client smoked something illegal and then mailed 
3 times the same mail at the same time.

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


Le Tue, 25 Nov 2008 17:27:34 +0100, Sukender <[EMAIL PROTECTED]> a écrit:

> Hi Robert,
>
> As a Windows user (and Linux too, but I definitively don't have enough time), 
> I'd like to tell that dependencies are somtimes a pain. I easily come to 
> trouble with versions confilcts (When using a lib in an app that already 
> exists in a OSG plugin, such as libcurl).
>
> And about deployement of binaries, I think some people should be *explicitly* 
> assigned to compilation/deployment of a specific binary set. My idea is that 
> a kind of chart should be maintained (maybe by you?) that indicates sets to 
> be compiled. These sets should indicate:
> - platform
> - compiler
> - OSG version (Stable or developper release)
> - dependencies versions
> - and various options.
> Each set would be assigned to one or more people (the first one that compiled 
> the set uploads it to the server). Does it sound right for you?
> Of course, these sets are to be discussed...
>
> For me, the set I compile looks like:
> - Win32
> - VC8 SP1
> - All stable OSG releases + some developper releases
> - Dependencies found in 
> https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1
> - Libs: Freetype, giflib, jpeg, png, tiff, zlib. All OSG wrappers. All 
> plugins available with given dependencies. All exemples and applications. 
> Release and Debug configurations only.
> (The resulting dir is >1GB, >100MB when 7Zip'ed)
>
> I'd like to help as much as I can for OSG 2.8, just tell me if you want some 
> things to be tested under Windows.
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
>
> Le Tue, 25 Nov 2008 16:09:20 +0100, Robert Osfield <[EMAIL PROTECTED]> a 
> écrit:
>
>> Hi All,
>>
>> Development wise I'm working towards getting OpenSceneGraph-2.8 in the
>> not too distant future.  One aspect I'd like to improve on before this
>> release is putting together better packing support for the various
>> platforms that we have.  For instance the OSG has/is/should continue
>> distributed in binary form either a win32 binaries/OSX binaries, as
>> well as the major linux distributions.  I can't hope to have all the
>> experitise, time and hardware/sofwtware resources to do this package
>> building, but I would like to help facilate making it easier for
>> others to do so, and for there to be greater continuity between the
>> packaging composition/naming.  So I'd start a discussion with those
>> knowledge on each platform - what your needs are, and for OSG users
>> themselves to help refine how it would make most sense for you.
>>
>> One area that I'd like to resolve is the packaging granularity.  The
>> OSG is now packing more functionality than ever before, much of this
>> like osgWidget and osgAnimation don't have an external dependencies,
>> so can easily be placed in the base package, but not facilities like
>> browser support, pdf support, vnc clients, as well as existing support
>> for plugins like Collada are all items that while really useful to
>> some, would be a rather weighty payload for others.  I therefore
>> believe it would be sensible for use to have a series of
>> OpenSceneGraph packages, a base package, and a base package set of
>> dependneices, then a series of add on packages that add extra features
>> and with it their dependencies.
>>
>> Right now we have the OSG itself has an
>> OpenSceneGraph/packaging/pkconfig directory, and this contains an
>> openthreads.pc and openscenegraph.pc files.  Looking at these files
>> they don't lists all the OSG dependencies, and they obviously don't
>> break it down like I'm advocating above.  I'm also aware that on
>> debain there are plenty of other configuration files associated with
>> the debian packaging.   What I feel would be appropriate would for us
>> to centralise this, and make full use of the existing packing
>> directory, full it out as required.  I also feel the granularity needs
>> to be addressed - but what sets of packaging and naming would be
>> appropriate?
>>
>> Thanks in advance for you help/thoughts/wisdom,
>> 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] Jni and compositeviewer

2008-11-25 Thread Vincent Bourdier

Hi,

Using the JNI to control 3D application from Java, I am implementing
multi-view.

Following the osg example ThirdPersonView, I try using only one
compositeviewer, and add some osgViewer::View to it.

But, depending on adding a view from the JNI or from C++ frame loop, I have
not the same behavior :
C++ : 2 view are well created, but one have the draw time increasing... so
the frame rate slowly decrease...
JNI : 2 view are well created, but only the second view can be used : the
first one is a clone of the second (same render, manipulator, ...). To have
2 different view, I need to make one compositeviewer per view...

Any idea of why the composite Viewer can be so different or seems unstable ?

Thanks.

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

Re: [osg-users] LightSource::setLocalStateSetModes

I understand. Thank you.

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


Le Tue, 25 Nov 2008 17:05:39 +0100, Robert Osfield <[EMAIL PROTECTED]> a écrit:

> Hi Sukender, I'm really overload right now, so I'll defer to others
> for this support.
>
> On Tue, Nov 25, 2008 at 3:37 PM, Sukender <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I have another question about light sources (This may be more directed to 
>> Robert, but maybe someone has the answer):
>> Why does the LightSource::setLocalStateSetModes() call "_stateset->clear();"?
>>
>> Just for info, I:
>> - set a root node that is a LightSource,
>> - call setLocalStateSetModes() (called on each frame) to illuminate its 
>> subgraph,
>> - and add another LightSource that illuminates the same subgraph.
>> When doing this, the call to setLocalStateSetModes() (on each frame) seem to 
>> remove the illumination from the second light source. I guess this is normal 
>> considering the "_stateset->clear();" statement.
>> I then have to call 
>> "lightSource->setStateSetModes(*lightSource->getOrCreateStateSet(), 
>> osg::StateAttribute::ON);" for this to work properly.
>>
>> Sukender
>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] Packaging granularity + platform specific scripts

Hi Robert,

As a Windows user (and Linux too, but I definitively don't have enough time), 
I'd like to tell that dependencies are somtimes a pain. I easily come to 
trouble with versions confilcts (When using a lib in an app that already exists 
in a OSG plugin, such as libcurl).

And about deployement of binaries, I think some people should be *explicitly* 
assigned to compilation/deployment of a specific binary set. My idea is that a 
kind of chart should be maintained (maybe by you?) that indicates sets to be 
compiled. These sets should indicate:
- platform
- compiler
- OSG version (Stable or developper release)
- dependencies versions
- and various options.
Each set would be assigned to one or more people (the first one that compiled 
the set uploads it to the server). Does it sound right for you?
Of course, these sets are to be discussed...

For me, the set I compile looks like:
- Win32
- VC8 SP1
- All stable OSG releases + some developper releases
- Dependencies found in 
https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1
- Libs: Freetype, giflib, jpeg, png, tiff, zlib. All OSG wrappers. All plugins 
available with given dependencies. All exemples and applications. Release and 
Debug configurations only.
(The resulting dir is >1GB, >100MB when 7Zip'ed)

I'd like to help as much as I can for OSG 2.8, just tell me if you want some 
things to be tested under Windows.

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


Le Tue, 25 Nov 2008 16:09:20 +0100, Robert Osfield <[EMAIL PROTECTED]> a écrit:

> Hi All,
>
> Development wise I'm working towards getting OpenSceneGraph-2.8 in the
> not too distant future.  One aspect I'd like to improve on before this
> release is putting together better packing support for the various
> platforms that we have.  For instance the OSG has/is/should continue
> distributed in binary form either a win32 binaries/OSX binaries, as
> well as the major linux distributions.  I can't hope to have all the
> experitise, time and hardware/sofwtware resources to do this package
> building, but I would like to help facilate making it easier for
> others to do so, and for there to be greater continuity between the
> packaging composition/naming.  So I'd start a discussion with those
> knowledge on each platform - what your needs are, and for OSG users
> themselves to help refine how it would make most sense for you.
>
> One area that I'd like to resolve is the packaging granularity.  The
> OSG is now packing more functionality than ever before, much of this
> like osgWidget and osgAnimation don't have an external dependencies,
> so can easily be placed in the base package, but not facilities like
> browser support, pdf support, vnc clients, as well as existing support
> for plugins like Collada are all items that while really useful to
> some, would be a rather weighty payload for others.  I therefore
> believe it would be sensible for use to have a series of
> OpenSceneGraph packages, a base package, and a base package set of
> dependneices, then a series of add on packages that add extra features
> and with it their dependencies.
>
> Right now we have the OSG itself has an
> OpenSceneGraph/packaging/pkconfig directory, and this contains an
> openthreads.pc and openscenegraph.pc files.  Looking at these files
> they don't lists all the OSG dependencies, and they obviously don't
> break it down like I'm advocating above.  I'm also aware that on
> debain there are plenty of other configuration files associated with
> the debian packaging.   What I feel would be appropriate would for us
> to centralise this, and make full use of the existing packing
> directory, full it out as required.  I also feel the granularity needs
> to be addressed - but what sets of packaging and naming would be
> appropriate?
>
> Thanks in advance for you help/thoughts/wisdom,
> 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] Cullind Data

2008-11-25 Thread Paul Martz

Seems like you could use a Camera pre-draw callback to put OpenGL into
feedback mode, and a post-draw callback to return to render mode and
retrieve the results. This would be awfully slow, not recommended for real
time rendering.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of oren david
Sent: Monday, November 24, 2008 9:20 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Cullind Data


Hello, 
I need to know the vertex of all the polygon I'm about to draw on screen
(after the culling has choosen the right ones), what is the right approach??

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

Re: [osg-users] osgWidget Design Advice

2008-11-25 Thread Jeremy Moles

On Tue, 2008-11-25 at 10:05 -0500, Max Bandazian wrote:
> 
> Jeremy,
> 
> 
>Having used osgWidget extensively, I second what everyone has said

I would definitely be interested most in the opinions of people who have
used osgWidget most. :)

>  above, that the input processing/picking ought to be factored out of
> the WindowManager into a separate class. osgWidget is a nice
> contribution to osg, but it does have a lot of instances like this
> where modularity could be improved. Input processing/picking is a
> tricky thing, and it would be great to have an easy setup for swapping
> in my own input handler; for instance, by default the topmost picked
> widget is selected, but I might want to pick through pixels that are
> textured transparent.

This is not a bad idea, but I'm not sure I fully understand how you want
them divorced. You're absolutely right that there is currently no "easy"
way to pick through a transparent pixel. Perhaps the answer here is not
to break it apart, but make creating derived WindowManagers easier?

>Since you're in a refactoring mood, I also want to mention that the
> biggest thing you could do to improve osgWidget is get rid of all uses
> of the friend keyword. It's not good in a toolkit, especially an alpha
> version toolkit, as it is mostly impossible to extend/override/bugfix
> the existing stuff by inheritance. For my own project, I needed to
> inherit from some of the widget classes and had to build my own
> friendless version as a result.

This would be easy to get rid of, and something I could do quickly.

> I can make a more extensive list of ''suggested improvements'' if you
> want :)

Please do. :) The results of this discussion thread will determine if I
am way over my head or not with osgWidget. It may turn out that I've
tackled a project much larger than my understanding, and need to scrap
it entirely. :(

> - Max Bandazian
> ___
> osg-users 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] Packaging granularity + platform specific scripts

Hi All,

Development wise I'm working towards getting OpenSceneGraph-2.8 in the
not too distant future.  One aspect I'd like to improve on before this
release is putting together better packing support for the various
platforms that we have.  For instance the OSG has/is/should continue
distributed in binary form either a win32 binaries/OSX binaries, as
well as the major linux distributions.  I can't hope to have all the
experitise, time and hardware/sofwtware resources to do this package
building, but I would like to help facilate making it easier for
others to do so, and for there to be greater continuity between the
packaging composition/naming.  So I'd start a discussion with those
knowledge on each platform - what your needs are, and for OSG users
themselves to help refine how it would make most sense for you.

One area that I'd like to resolve is the packaging granularity.  The
OSG is now packing more functionality than ever before, much of this
like osgWidget and osgAnimation don't have an external dependencies,
so can easily be placed in the base package, but not facilities like
browser support, pdf support, vnc clients, as well as existing support
for plugins like Collada are all items that while really useful to
some, would be a rather weighty payload for others.  I therefore
believe it would be sensible for use to have a series of
OpenSceneGraph packages, a base package, and a base package set of
dependneices, then a series of add on packages that add extra features
and with it their dependencies.

Right now we have the OSG itself has an
OpenSceneGraph/packaging/pkconfig directory, and this contains an
openthreads.pc and openscenegraph.pc files.  Looking at these files
they don't lists all the OSG dependencies, and they obviously don't
break it down like I'm advocating above.  I'm also aware that on
debain there are plenty of other configuration files associated with
the debian packaging.   What I feel would be appropriate would for us
to centralise this, and make full use of the existing packing
directory, full it out as required.  I also feel the granularity needs
to be addressed - but what sets of packaging and naming would be
appropriate?

Thanks in advance for you help/thoughts/wisdom,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LightSource::setLocalStateSetModes

Hi Sukender, I'm really overload right now, so I'll defer to others
for this support.

On Tue, Nov 25, 2008 at 3:37 PM, Sukender <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have another question about light sources (This may be more directed to 
> Robert, but maybe someone has the answer):
> Why does the LightSource::setLocalStateSetModes() call "_stateset->clear();"?
>
> Just for info, I:
> - set a root node that is a LightSource,
> - call setLocalStateSetModes() (called on each frame) to illuminate its 
> subgraph,
> - and add another LightSource that illuminates the same subgraph.
> When doing this, the call to setLocalStateSetModes() (on each frame) seem to 
> remove the illumination from the second light source. I guess this is normal 
> considering the "_stateset->clear();" statement.
> I then have to call 
> "lightSource->setStateSetModes(*lightSource->getOrCreateStateSet(), 
> osg::StateAttribute::ON);" for this to work properly.
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgWidget Design Advice

2008-11-25 Thread Cedric Pinson


Hi Jeremy,

The view pointer is a bit weird for me because i manage eventhandler not 
in the viewer. I put them in node event callback and then with
a switch i enable some and disable other depending of game state. So the 
view pointer make osgWidget crash with my system. So an approach

like Robert explain works better with what i do.

Anyway i am happy to use osgWidget now.

Cheers,
Cedric

Jeremy Moles wrote:

On Tue, 2008-11-25 at 10:05 -0500, Max Bandazian wrote:
  

Jeremy,


   Having used osgWidget extensively, I second what everyone has said



I would definitely be interested most in the opinions of people who have
used osgWidget most. :)

  

 above, that the input processing/picking ought to be factored out of
the WindowManager into a separate class. osgWidget is a nice
contribution to osg, but it does have a lot of instances like this
where modularity could be improved. Input processing/picking is a
tricky thing, and it would be great to have an easy setup for swapping
in my own input handler; for instance, by default the topmost picked
widget is selected, but I might want to pick through pixels that are
textured transparent.



This is not a bad idea, but I'm not sure I fully understand how you want
them divorced. You're absolutely right that there is currently no "easy"
way to pick through a transparent pixel. Perhaps the answer here is not
to break it apart, but make creating derived WindowManagers easier?

  

   Since you're in a refactoring mood, I also want to mention that the
biggest thing you could do to improve osgWidget is get rid of all uses
of the friend keyword. It's not good in a toolkit, especially an alpha
version toolkit, as it is mostly impossible to extend/override/bugfix
the existing stuff by inheritance. For my own project, I needed to
inherit from some of the widget classes and had to build my own
friendless version as a result.



This would be easy to get rid of, and something I could do quickly.

  

I can make a more extensive list of ''suggested improvements'' if you
want :)



Please do. :) The results of this discussion thread will determine if I
am way over my head or not with osgWidget. It may turn out that I've
tackled a project much larger than my understanding, and need to scrap
it entirely. :(

  

- Max Bandazian
___
osg-users 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
  


--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED] 
http://www.plopbyte.net


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

Re: [osg-users] repository

2008-11-25 Thread Cedric Pinson


Hi Alberto,
No i will still use osg-branch as development. The osg-trunk repository 
is just a copy of the svn, it will be always sync from the trunk svn. I 
will not push external stuff inside. Just it can help some time to try 
stuff and to have it as backup or when osg is down.
It does not change the way we work with Jeremy so the osg-branch is 
still the good place.


Cheers,
Cedric

Alberto Luaces wrote:

Hi Cedric,

now that osgAnimation is on OSG trunk, are you going to leave the previous 
branch (http://hg.plopbyte.net/osg-branch/) and use this new one instead?


Regards,

Alberto

El Martes 25 Noviembre 2008ES 15:07:37 Cedric Pinson escribió:
  

Hi All,

Maybe it will not interest so much people but i added a mercurial
repository of OpenSceneGraph trunk. it's updated from the svn each
hours, and keep
all history. I use it to manipulate patch diff merge and branch code. So
if other are interested to use it's open.
It can be considerer as backup and or a second source when the svn is
down too

hg clone hg.plopbyte.net/osg-trunk
else
you can browse it http://hg.plopbyte.net/osg-trunk/

Cheers,
Cedric




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


--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED] 
http://www.plopbyte.net


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

[osg-users] LightSource::setLocalStateSetModes

Hi all,

I have another question about light sources (This may be more directed to 
Robert, but maybe someone has the answer):
Why does the LightSource::setLocalStateSetModes() call "_stateset->clear();"?

Just for info, I:
- set a root node that is a LightSource,
- call setLocalStateSetModes() (called on each frame) to illuminate its 
subgraph,
- and add another LightSource that illuminates the same subgraph.
When doing this, the call to setLocalStateSetModes() (on each frame) seem to 
remove the illumination from the second light source. I guess this is normal 
considering the "_stateset->clear();" statement.
I then have to call 
"lightSource->setStateSetModes(*lightSource->getOrCreateStateSet(), 
osg::StateAttribute::ON);" for this to work properly.

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

Re: [osg-users] osgWidget Design Advice

2008-11-25 Thread Jeremy Moles

On Mon, 2008-11-24 at 23:22 -0500, Jean-Sébastien Guay wrote:
> Hi Jeremy,
> 
> > Why does the WindowManager have to know anything about cameras?
> 
> I have the same question, but with different results: unless I've missed 
> something in your description, why does anyone need to know about the 
> camera? If you get your click events (which you act upon to get 
> intersections) through an event handler, then you can just get an 
> osg::View* with aa.asView(), which then has a camera. No one really 
> needs to hold on to a camera pointer.
> 
> I would definitely go with calculating intersections directly through 
> osgUtil::IntersectionVisitor. You can use the constructor that takes one 
> of the WINDOW, PROJECTION, VIEW and MODEL enum values to easily 
> construct the right intersector. It should even work for 3D "widgets in 
> space... space ... space ..." :-)
> 
> As for creating an ortho viewport, perhaps you can return an osg::Camera 
> with the right setup, and the user can then assign that to their 
> viewer/view/slave camera/scenegraph/whatever. It would be more general.
> 
> That way you can remove the dependency between osgWidget and osgViewer 
> (not sure if that's the goal here, but if intersections was the only 
> thing that forced that dependency, I'd definitely remove it).

Yeah, removing this dependency is definitely something I'd like to do,
and computeIntersections is the only things I use.

> Anyways, like the others who replied I don't really know the internals 
> of osgWidget, so perhaps there's something I've overlooked, but that's 
> how I see it at first glance.
> 
> Hope this helps,
> 
> J-S

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

Re: [osg-users] repository

2008-11-25 Thread Alberto Luaces

Hi Cedric,

now that osgAnimation is on OSG trunk, are you going to leave the previous 
branch (http://hg.plopbyte.net/osg-branch/) and use this new one instead?

Regards,

Alberto

El Martes 25 Noviembre 2008ES 15:07:37 Cedric Pinson escribió:
> Hi All,
>
> Maybe it will not interest so much people but i added a mercurial
> repository of OpenSceneGraph trunk. it's updated from the svn each
> hours, and keep
> all history. I use it to manipulate patch diff merge and branch code. So
> if other are interested to use it's open.
> It can be considerer as backup and or a second source when the svn is
> down too
>
> hg clone hg.plopbyte.net/osg-trunk
> else
> you can browse it http://hg.plopbyte.net/osg-trunk/
>
> Cheers,
> Cedric


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

Re: [osg-users] osgWidget Design Advice

2008-11-25 Thread Max Bandazian

Jeremy,
   Having used osgWidget extensively, I second what everyone has said above,
that the input processing/picking ought to be factored out of the
WindowManager into a separate class. osgWidget is a nice contribution to
osg, but it does have a lot of instances like this where modularity could be
improved. Input processing/picking is a tricky thing, and it would be great
to have an easy setup for swapping in my own input handler; for instance, by
default the topmost picked widget is selected, but I might want to pick
through pixels that are textured transparent.

   Since you're in a refactoring mood, I also want to mention that the
biggest thing you could do to improve osgWidget is get rid of all uses of
the friend keyword. It's not good in a toolkit, especially an alpha version
toolkit, as it is mostly impossible to extend/override/bugfix the existing
stuff by inheritance. For my own project, I needed to inherit from some of
the widget classes and had to build my own friendless version as a result.

I can make a more extensive list of ''suggested improvements'' if you want
:)

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

Re: [osg-users] Interest in DirectShow plugin for OpenSceneGraph?

2008-11-25 Thread alessandro terenzi

I use OSG on Windows and I'm here to say that it could be useful to have
such a plugin.
Alessandro

On Sun, Nov 23, 2008 at 10:04 PM, Jason Beverage <[EMAIL PROTECTED]>wrote:

> Hi Janusz,
>
> Yes, the plan is to open source the plugin.  I was interested in gauging
> the level of community interest before deciding about how to eventually
> proceed.
>
> Thanks!
>
> Jason
>
>
> On Sun, Nov 23, 2008 at 5:44 AM, Janusz <[EMAIL PROTECTED]> wrote:
>
>> Jason: Will that be open-sourced? Janusz
>>
>> Robert Osfield pisze:
>>
>> Hi Jason,
>>
>> On Sat, Nov 22, 2008 at 11:06 PM, Jason Beverage<[EMAIL PROTECTED]> <[EMAIL 
>> PROTECTED]> wrote:
>>
>>
>> We're currently developing a DirectShow plugin for OpenSceneGraph and I
>> wanted to see if there was anyone else in the community that would be
>> interested in this capability.
>>
>>
>> I'm no windows user, but I can't certainly see value in having an open
>> source direct show plugin.  I know of other groups that have developed
>> their own DirectShow integration with the OSG, but without the code
>> being open sourced everyone else is doomed to replicate this
>> functionality...
>>
>> Robert.
>> ___
>> osg-users mailing [EMAIL 
>> PROTECTED]://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] CompositeViewer addView threading issue on Windows?


Hi Robert,

I forgot to mention that this is running with OSG as compiled yesterday 
afternoon after an svn update.



It's interesting that opening up the windows at the start allows
things to run, this suggest that it's allocation of new OpenGL that is
problem - which is something that the resize of the GL buffers would
have done the trick.


I really think there's something fishy with makeCurrent. Perhaps 
somewhere it's done on the wrong thread the first time, or something 
like that... It seems one of the graphics threads is stuck trying to 
make its context current but can't for some reason - it seems to be 
spinning on a critical section in the graphics driver. Not sure if that 
makes sense, and in any case it won't help much until you can see the 
problem firsthand, but that's what it looks like to me.



W.r.t opening 40 windows and the app crashing - this is almost
certainly down to exhustion of OpenGL resouces.


Yeah, I think so too. I could get to 32. I don't think we could get much 
higher, and I'm not inclined to debug it either, as I doubt our users 
will open as many - normally in a modeling app you have the classic 4 
views (3 ortho + 1 perspective) and maybe a few more when needed, but I 
would think we'd rarely need more than 10 at a time.



Whether the new system will work properly right away and if to does
will it reproduce the hang I don't know untill I get to testing, but
test it I will.


OK, I'm anxiously awaiting any new info.

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] Multi-threading bug related to Registry

Hi Rick,

Just to confirm the issue, if you enable Registry caching of imagery
and use paged databases that have external image files, then you get
the below crash.   If you don't use the Registry cache what happens?

How reliably does this crash occur?

My hypothisis is that the object cache is being cleared by another
thread just at the wrong time for this particular section of .ive
plugin.  If it is correct then use of  Registry::readImage(...) that
returns a Registry::ReadResult rather than a Image* would be safe as
ReadResult uses ref_ptr<> internally.

Robert.

On Tue, Nov 25, 2008 at 1:49 PM, Rick Appleton
<[EMAIL PROTECTED]> wrote:
> Sorry for the delay on this.
>
> Here's some more information. Below is a complete callstack which should be 
> similar to when the issue happened. Basically we are loading a Paged terrain 
> database which uses IVE files for data, and DDS textures for images. A quick 
> search in OSG reveals that osgDB::readImageFile is called from many plugin 
> loaders, so I suspect they would have the same issue.
>
>osg48-osgDBd.dll!osgDB::Registry::readImageImplementation(const 
> std::basic_string,std::allocator > & 
> fileName="textures/TxMosaic.dds", const osgDB::ReaderWriter::Options * 
> options=0x01f0ceb8)  Line 1706C++
>osg48-osgDBd.dll!osgDB::Registry::readImage(const 
> std::basic_string,std::allocator > & 
> fileName="textures/TxMosaic.dds", const osgDB::ReaderWriter::Options * 
> options=0x01f0ceb8)  Line 217 + 0x14 bytes  C++
>>   osg48-osgDBd.dll!osgDB::readImageFile(const 
>> std::basic_string,std::allocator > & 
>> filename="textures/TxMosaic.dds", const osgDB::ReaderWriter::Options * 
>> options=0x01f0ceb8)  Line 43 + 0x1d bytes C++
>
> osgdb_ived.dll!ive::DataInputStream::readImage(std::basic_string,std::allocator
>  > filename="textures/TxMosaic.dds")  Line 950 + 0x44 bytesC++
>osgdb_ived.dll!ive::DataInputStream::readImage(ive::IncludeImageMode 
> mode=IMAGE_REFERENCE_FILE)  Line 1003 + 0x2c bytes C++
>osgdb_ived.dll!ive::DataInputStream::readImage()  Line 976 + 0xc bytes 
>  C++
>osgdb_ived.dll!ive::Texture2D::read(ive::DataInputStream * 
> in=0x00dbec2c)  Line 54 + 0x8 bytes  C++
>osgdb_ived.dll!ive::DataInputStream::readStateAttribute()  Line 1159 + 
> 0xc bytesC++
>osgdb_ived.dll!ive::StateSet::read(ive::DataInputStream * 
> in=0x00dbec2c)  Line 173 + 0x8 bytes  C++
>osgdb_ived.dll!ive::DataInputStream::readStateSet()  Line 1066  C++
>osgdb_ived.dll!ive::Node::read(ive::DataInputStream * in=0x00dbec2c)  
> Line 124 + 0x8 bytes  C++
>osgdb_ived.dll!ive::Geode::read(ive::DataInputStream * in=0x00dbec2c)  
> Line 67  C++
>osgdb_ived.dll!ive::DataInputStream::readNode()  Line 1507 + 0x2d 
> bytes C++
>osgdb_ived.dll!ive::Group::read(ive::DataInputStream * in=0x00dbec2c)  
> Line 74 + 0x8 bytes  C++
>osgdb_ived.dll!ive::DataInputStream::readNode()  Line 1499 + 0xc bytes 
>  C++
>
> osgdb_ived.dll!ReaderWriterIVE::readNode(std::basic_istream
>  > & fin={...}, const osgDB::ReaderWriter::Options * options=0x01f0ceb8)  
> Line 98 + 0xb bytesC++
>osgdb_ived.dll!ReaderWriterIVE::readNode(const 
> std::basic_string,std::allocator > & 
> file="veluwe.ive", const osgDB::ReaderWriter::Options * options=0x01efeb88)  
> Line 69 + 0x23 bytes C++
>
> osg48-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter 
> & rw={...})  Line 1374 + 0x40 bytes   C++
>osg48-osgDBd.dll!osgDB::Registry::read(const 
> osgDB::Registry::ReadFunctor & readFunctor={...})  Line 1527 + 0x22 bytes  C++
>osg48-osgDBd.dll!osgDB::Registry::readImplementation(const 
> osgDB::Registry::ReadFunctor & readFunctor={...}, bool useObjectCache=true)  
> Line 1596 + 0x13 bytes  C++
>osg48-osgDBd.dll!osgDB::Registry::readNodeImplementation(const 
> std::basic_string,std::allocator > & 
> fileName="veluwe.ive", const osgDB::ReaderWriter::Options * 
> options=0x01efeb88)  Line 1814 + 0x57 bytes   C++
>osg48-osgDBd.dll!osgDB::Registry::readNode(const 
> std::basic_string,std::allocator > & 
> fileName="veluwe.ive", const osgDB::ReaderWriter::Options * 
> options=0x01efeb88)  Line 232 + 0x98 bytes  C++
>osg48-osgDBd.dll!osgDB::readNodeFile(const 
> std::basic_string,std::allocator > & 
> filename="veluwe.ive", const osgDB::ReaderWriter::Options * 
> options=0x01efeb88)  Line 69 + 0x1d bytes C++
>osg48-osgDBd.dll!osgDB::readNodeFiles(osg::ArgumentParser & 
> arguments={...}, const osgDB::ReaderWriter::Options * options=0x01efeb88)  
> Line 224 + 0x43 bytesC++
>osgviewerd.exe!osgDB::readNodeFiles(osg::ArgumentParser & 
> parser={...})  Line 132 + 0x32 bytes  C++
>osgviewerd.exe!main(int argc=2, char * * argv=0x01eee120)  Line 134 + 
> 0x9 bytes C++
>osgviewerd.exe!__tmainCRTStartup()  Line 597 + 0x19 bytes   C
>osgviewerd.exe!mainCRTStart

[osg-users] repository

2008-11-25 Thread Cedric Pinson


Hi All,

Maybe it will not interest so much people but i added a mercurial 
repository of OpenSceneGraph trunk. it's updated from the svn each 
hours, and keep
all history. I use it to manipulate patch diff merge and branch code. So 
if other are interested to use it's open.
It can be considerer as backup and or a second source when the svn is 
down too


hg clone hg.plopbyte.net/osg-trunk
else
you can browse it http://hg.plopbyte.net/osg-trunk/

Cheers,
Cedric

--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED] 
http://www.plopbyte.net


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

Re: [osg-users] Multi-threading bug related to Registry

2008-11-25 Thread Rick Appleton

Sorry for the delay on this.

Here's some more information. Below is a complete callstack which should be 
similar to when the issue happened. Basically we are loading a Paged terrain 
database which uses IVE files for data, and DDS textures for images. A quick 
search in OSG reveals that osgDB::readImageFile is called from many plugin 
loaders, so I suspect they would have the same issue.

osg48-osgDBd.dll!osgDB::Registry::readImageImplementation(const 
std::basic_string,std::allocator > & 
fileName="textures/TxMosaic.dds", const osgDB::ReaderWriter::Options * 
options=0x01f0ceb8)  Line 1706C++
osg48-osgDBd.dll!osgDB::Registry::readImage(const 
std::basic_string,std::allocator > & 
fileName="textures/TxMosaic.dds", const osgDB::ReaderWriter::Options * 
options=0x01f0ceb8)  Line 217 + 0x14 bytes  C++
>   osg48-osgDBd.dll!osgDB::readImageFile(const 
> std::basic_string,std::allocator > & 
> filename="textures/TxMosaic.dds", const osgDB::ReaderWriter::Options * 
> options=0x01f0ceb8)  Line 43 + 0x1d bytes C++

osgdb_ived.dll!ive::DataInputStream::readImage(std::basic_string,std::allocator
 > filename="textures/TxMosaic.dds")  Line 950 + 0x44 bytesC++
osgdb_ived.dll!ive::DataInputStream::readImage(ive::IncludeImageMode 
mode=IMAGE_REFERENCE_FILE)  Line 1003 + 0x2c bytes C++
osgdb_ived.dll!ive::DataInputStream::readImage()  Line 976 + 0xc bytes  
C++
osgdb_ived.dll!ive::Texture2D::read(ive::DataInputStream * 
in=0x00dbec2c)  Line 54 + 0x8 bytes  C++
osgdb_ived.dll!ive::DataInputStream::readStateAttribute()  Line 1159 + 
0xc bytesC++
osgdb_ived.dll!ive::StateSet::read(ive::DataInputStream * 
in=0x00dbec2c)  Line 173 + 0x8 bytes  C++
osgdb_ived.dll!ive::DataInputStream::readStateSet()  Line 1066  C++
osgdb_ived.dll!ive::Node::read(ive::DataInputStream * in=0x00dbec2c)  
Line 124 + 0x8 bytes  C++
osgdb_ived.dll!ive::Geode::read(ive::DataInputStream * in=0x00dbec2c)  
Line 67  C++
osgdb_ived.dll!ive::DataInputStream::readNode()  Line 1507 + 0x2d bytes 
C++
osgdb_ived.dll!ive::Group::read(ive::DataInputStream * in=0x00dbec2c)  
Line 74 + 0x8 bytes  C++
osgdb_ived.dll!ive::DataInputStream::readNode()  Line 1499 + 0xc bytes  
C++

osgdb_ived.dll!ReaderWriterIVE::readNode(std::basic_istream
 > & fin={...}, const osgDB::ReaderWriter::Options * options=0x01f0ceb8)  Line 
98 + 0xb bytesC++
osgdb_ived.dll!ReaderWriterIVE::readNode(const 
std::basic_string,std::allocator > & 
file="veluwe.ive", const osgDB::ReaderWriter::Options * options=0x01efeb88)  
Line 69 + 0x23 bytes C++

osg48-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter & 
rw={...})  Line 1374 + 0x40 bytes   C++
osg48-osgDBd.dll!osgDB::Registry::read(const 
osgDB::Registry::ReadFunctor & readFunctor={...})  Line 1527 + 0x22 bytes  C++
osg48-osgDBd.dll!osgDB::Registry::readImplementation(const 
osgDB::Registry::ReadFunctor & readFunctor={...}, bool useObjectCache=true)  
Line 1596 + 0x13 bytes  C++
osg48-osgDBd.dll!osgDB::Registry::readNodeImplementation(const 
std::basic_string,std::allocator > & 
fileName="veluwe.ive", const osgDB::ReaderWriter::Options * options=0x01efeb88) 
 Line 1814 + 0x57 bytes   C++
osg48-osgDBd.dll!osgDB::Registry::readNode(const 
std::basic_string,std::allocator > & 
fileName="veluwe.ive", const osgDB::ReaderWriter::Options * options=0x01efeb88) 
 Line 232 + 0x98 bytes  C++
osg48-osgDBd.dll!osgDB::readNodeFile(const 
std::basic_string,std::allocator > & 
filename="veluwe.ive", const osgDB::ReaderWriter::Options * options=0x01efeb88) 
 Line 69 + 0x1d bytes C++
osg48-osgDBd.dll!osgDB::readNodeFiles(osg::ArgumentParser & 
arguments={...}, const osgDB::ReaderWriter::Options * options=0x01efeb88)  Line 
224 + 0x43 bytesC++
osgviewerd.exe!osgDB::readNodeFiles(osg::ArgumentParser & parser={...}) 
 Line 132 + 0x32 bytes  C++
osgviewerd.exe!main(int argc=2, char * * argv=0x01eee120)  Line 134 + 
0x9 bytes C++
osgviewerd.exe!__tmainCRTStartup()  Line 597 + 0x19 bytes   C
osgviewerd.exe!mainCRTStartup()  Line 414   C
kernel32.dll!7c816d4f() 
[Frames below may be incorrect and/or missing, no symbols loaded for 
kernel32.dll]  
kernel32.dll!7c8399f3() 



-Original Message-
From: [EMAIL PROTECTED] on behalf of Robert Osfield
Sent: Tue 18/11/2008 17:35
To: OpenSceneGraph Users
Subject: Re: [osg-users] Multi-threading bug related to Registry
 
Hi Rick,

The solution is for ref_ptr to be used, but where I can't say
as you don't provide full details on what code is at fault.  Which
plugins are you invoking in this instance?  .osg? .ive?  Others?

Robert.

On Mon, Nov 17, 2008 at 1:23 PM, Rick Appleton
<[EMAIL PROTECTED]> wrote:
> There is a nasty multi-threading bug related to osgDB::DatabasePager and the
> _obj

Re: [osg-users] help building vpb for osg 2.6.1

2008-11-25 Thread santosh


Hi

I am getting same problem.
How you solved ?  I am using osg 2.6.0 version.

Thanks

David _ wrote:

solved


From: [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.org
Date: Thu, 30 Oct 2008 13:07:28 +0100
Subject: [osg-users] help building vpb for osg 2.6.1

Hi

i´m a vista user, visual studio 2005 and i´m trying to compile VPB 
against osg 2.6.1


i cheked the vpb web and it said that i needed the vpb svn r924 
revision in order to make it work with osg 2.6.0


i downloaded the VPB 0.9.7 and overwrote the files that were modified 
in the r924 svn release


set up everything with cmake 2.6 for visual studio 2005 and now i get 
compilations errors like these


.\TaskManager.cpp(192) : error C2039: 'getTerrainTechnique' : is not a 
member of 'osgTerrain::Terrain'
2>
D:\OpenSceneGraph-2.6.1\OpenSceneGraph-2.6.1\include\osgTerrain/Terrain(26) 
: see declaration of 'osgTerrain::Terrain'
2>.\TaskManager.cpp(233) : error C2039: 'getTerrainTechnique' : is not 
a member of 'osgTerrain::Terrain'
2>
D:\OpenSceneGraph-2.6.1\OpenSceneGraph-2.6.1\include\osgTerrain/Terrain(26) 
: see declaration of 'osgTerrain::Terrain'
2>.\TaskManager.cpp(679) : error C2039: 'getTerrainTechnique' : is not 
a member of 'osgTerrain::Terrain'
2>
D:\OpenSceneGraph-2.6.1\OpenSceneGraph-2.6.1\include\osgTerrain/Terrain(26) 
: see declaration of 'osgTerrain::Terrain'



i guess that 2.6.1 is not the right version for the VPB i´m using. 
What do you suggest



thanks


¡Trónchate de risa con los mejores capítulos de South Park en MSN 
Vídeo! 
 



La cartera, las gafas. ¿te falta algo? Ahora llévate Messenger en tu 
móvil 


__ NOD32 3548 (20081023) Information __

This message was checked by NOD32 antivirus system.
http://www.eset.com


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



__ NOD32 3548 (20081023) Information __

This message was checked by NOD32 antivirus system.
http://www.eset.com
  


--
Santosh Gaikwad
MTS Design
Darshan Solutions Limited
#+91 9953099053

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

[osg-users] traverse the list of geometry created during the cull traversal

2008-11-25 Thread oren david

Sorry for the mass, I'm really new into OSG and I just can't find some basic
info.
We (www.jct.ac.il) are doing some 3D non-linear implicit function research
and we draw them on screen, for some reason I need to know the distance of
my camera to the closest polygon/vertex and then run some math issue based
on the distance..
So I thought to traverse the list of geometry created during the cull
traversal and find my closest polygon/vertex.
I've search the group and found nothing.
Oren David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] pragma warnings disabled in headers

2008-11-25 Thread Wojciech Lewandowski


Hi Guys,

I generally agree that suppressing these warnings is bad. Truth is if they 
were not disabled at the early days of OSG most of them would be not present 
today because authors would fix them in other way. And this poses a danger 
for the future. As along as we keep them disabled authors will produce more 
and more of these warnings.


But the other side is that proper fixing would probably require modifying 
hundreds of OSG headers. I doubt that there is anyone brave enough to accept 
this time consuming task and I doubt Robert will authorize this move.


It an impasse in which we have to choose between bad and worse. The good 
thing though, is that its up to you which one you consider worse ;-)


Wojtek



Hi Paul,

Wojtek's change only restores the OSG to how it's been compiling since
the very early days w.r.t disabling the least usefu/most distractingl
of the MSVC warnings.

You can disable this via CMake, so that the OSG doesn't suppress any 
warnings.


Fixing warnings is desirable, but has to be done with care as doing so
can introduce bugs - this has happened to the OSG in the past.
Warnings do often bring up ambiguities in the code that the author
didn't spot - which is good, but they also produce false positives -
highlighting code that is absolutely correct for it's intended usage,
but confuses developer into thinking that something is wrong and
fixing something that isn't broken, or just obfuscates the real
warnings amoungst the sea of false positives.  For this reason I'm
cautious about diving in and doing a warnings purge.

Robert.

On Mon, Nov 24, 2008 at 9:37 PM, Paul Martz <[EMAIL PROTECTED]> 
wrote:

Hi all -- Sorry I'm coming into this a little late.

What I'd really like is a clean compile so that if I introduce some
suspicious code, I clearly see a new warning message displayed in the
output, so that I can investigate it. What I don't want is to have all
warnings disabled so that I never see a message about my bogus change. If
the warning is displayed, but I miss it because it's buried in hundreds 
or
thousands of other warnings unrelated to my code change, then that's just 
as

bad as having it disabled and not displayed at all.


Perhaps the middle ground is to place the #pagma's in the
CMake generated include/osg/Config file?


This seems like the worst solution, because not only does it disable all
warnings in the OSG headers, it also disables it in my own application 
code

that directly or indirectly includes osg/Config. If I change code and
introduce a warning, I'll never see the warning message displayed because
osg/Config disabled it.


The other approach is to do an explicit casts to avoid the
warnings in the first place.  This is more wordy and while of
dubious practical value would at least fix the warnings.


Yes, this is probably the best solution, but is a prohibitive task to 
bite

off for a large existing code base.

A third solution, as Wojtek mentioned, is to wrap each OSG header file 
with

#pragma push/pop so that warnings can be disabled just in the header, and
not in user code that includes the header. This could be done by changing
all OSG headers to include CMake-generated prefix and suffix files that
contain the push/pops and disables. This is still an undesirable solution
because it turns all warnings off in OSG headers, even for future code
changes, but is no worse than what we had before and is relatively easy 
to

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


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

Re: [osg-users] pragma warnings disabled in headers

Hi Wojtek,

On Tue, Nov 25, 2008 at 11:39 AM, Wojciech Lewandowski
<[EMAIL PROTECTED]> wrote:
> But the other side is that proper fixing would probably require modifying
> hundreds of OSG headers. I doubt that there is anyone brave enough to accept
> this time consuming task and I doubt Robert will authorize this move.

Proper fixing for quite a few warnings requires fixing the compiler...

I'm for gradually tightening up on the sensible warnings that are
produced.  I'm against a wholesale warnings purge.  You really need
good engineers to do warnings fixes, as it's very easy to be be lured
into think there is problem in the code and then fixing and breaking
it in the process.  Another danger is that by fixing a "warning" is
that the code can become more obfusticated and more difficult to
maintain which leads to more bugs in the long term.  This is why you
need a engineer that really understands C++, what the actual OSG code
is attempting to do, and the idiosyncrasies of compilers and to see to
the bottom of all warnings in what they really mean in terms of
compiled code and its reliability.

I know that some groups have a non warnings policy in their projects,
but I consider this a bad policy as it can lead to chasing false
positives, fixing things that aren't broken and reducing software
quality as a consequence.

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

Re: [osg-users] Qt >4.4.0 + C locale + collada (dae) plugin

2008-11-25 Thread Ralph Kern

Hi Luc,

you could try to patch the plugin to set the locale to "C" before
reading and restore afterwards.

But you might be careful to threading issues, because setlocale() is
working on a per process basis.

regards Ralph

Frauciel Luc schrieb:
> Hi,
> 
> This summer, a problem have been spotted and solved about .osg format, and 
> the use of Qt that modify C locale
> http://groups.google.com/group/osg-users/browse_thread/thread/f5a53aaeed71b585/2b0454460d959e2d?lnk=gst&q=qt+locale#2b0454460d959e2d
> 
> I've got a similar problem with DAE plugin.
> However, since the atof call is done in collada dom and not the plugin, there 
> is no way to use the same solution (custom osg_atof).
> Do someone have an hint on how this problem can be solved ?
> 
> Luc
> 

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

[osg-users] Qt >4.4.0 + C locale + collada (dae) plugin

2008-11-25 Thread Frauciel Luc

Hi,

This summer, a problem have been spotted and solved about .osg format, and the
use of Qt that modify C locale
http://groups.google.com/group/osg-users/browse_thread/thread/f5a53aaeed71b585/2b0454460d959e2d?lnk=gst&q=qt+locale#2b0454460d959e2d

I've got a similar problem with DAE plugin.
However, since the atof call is done in collada dom and not the plugin, there
is no way to use the same solution (custom osg_atof).
Do someone have an hint on how this problem can be solved ?

Luc

Luc FRAUCIEL - BRGM
Unité Calcul, 3D et réalité virtuelle
Service Systèmes et Technologies de l'Information
3, av C. Guillemin BP 36009 - 45060 Orléans Cedex 2, France
Tél. 02 38 64 35 65
Fax 02 38 64 39 70
**

Pensez à l'environnement avant d'imprimer ce message
Think Environment before printing

Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du
(des) destinataire(s) désigné
(s)
comme tel(s).
En cas de réception par erreur, le signaler à son expéditeur et ne pas en
divulguer le contenu.
L'absence de virus a été vérifiée à l'émission, il convient néanmoins de
s'assurer de l'absence de
contamination à sa réception.

The contents of this email and any attachments areconfidential. They are
intended for the named recipient
(s)
only.
If you have received this email in error please notifythe system manager or the
sender immediately and do
not
disclose the contents to anyone or make copies.
eSafe scanned this email for viruses, vandals and malicious content.

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

Re: [osg-users] traverse the list of geometry created during the cull traversal

Hi Oren,

This is a topic that has been discussed in osg-users before so please
check through the archives.

You started the thread before, and got and  answer that looked for
clarification, but instead of engaging you just ask the same question
again in another thread.  This isn't a good use of the osg-users
lists, please stick to existing threads and not start new ones just to
try and bump your topic up.

Robert.

On Tue, Nov 25, 2008 at 10:48 AM, oren david <[EMAIL PROTECTED]> wrote:
> Hello all,
> how do I traverse the list of geometry created during the cull traversal??
> thank you
> ___
> osg-users 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] traverse the list of geometry created during the cull traversal

2008-11-25 Thread oren david

Hello all,
how do I traverse the list of geometry created during the cull traversal??
thank you
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LightSources duplicated

Oh sorry then,

I'm just asking: what is the effect of calling
lightSource->getOrCreateStateSet()->setAttribute(light, 
osg::StateAttribute::ON);
I guess that's just *stupid* to add a Light structure as a StateSet for the 
LightSource that already has this Light structure, but I'm just trying to 
understand the strange lighting that results.
Thank you.

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


Le Tue, 25 Nov 2008 11:15:35 +0100, Robert Osfield <[EMAIL PROTECTED]> a écrit:

> Hi Sukender,
>
> I'm afraid I don't understand your question.
>
> Robert.
>
> On Tue, Nov 25, 2008 at 10:06 AM, Sukender <[EMAIL PROTECTED]> wrote:
>> Re, Robert!
>>
>> Here is another (stupid?) question. What happens if I call:
>>lightSource->getOrCreateStateSet()->setAttribute(light, 
>> osg::StateAttribute::ON);
>> (Please note that my models are under the "lightSource" node, and that I 
>> called "lightSource->setLocalStateSetModes(osg::StateAttribute::ON);" 
>> before).
>> The result seems odd (combined with the two LightSources having the same 
>> number).
>>
>> Sukender
>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>>
>>
>> Le Tue, 25 Nov 2008 10:51:33 +0100, Sukender <[EMAIL PROTECTED]> a écrit:
>>
>>> Thank you, Robert. I'm still investigating to try to understand the 
>>> "artifact" I found about strange lighting. But what you tell gives me more 
>>> questions than answers! Crap. I'll continue then. Anyway, what you say is 
>>> interesting for me. Thanks again.
>>>
>>> Sukender
>>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>>>
>>> Le Tue, 25 Nov 2008 10:38:36 +0100, Robert Osfield <[EMAIL PROTECTED]> a 
>>> écrit:
>>>
 Hi Sukender,

 If the two LightSource node, that use the same light number, fall in
 the same RenderStage then the last one to be traversed will be the one
 that takes precedence, and the previous one will be ignored.
 Effectively a light can only be in one place at one time.

 Robert.

 On Tue, Nov 25, 2008 at 12:14 AM, Sukender <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Just a stupid question (does it require a stupid answer? ;) ): What 
> happens to OpenGL/OSG when two LightSources with the same number are 
> added to the graph? How does the cull/render behave?
> (Yes, I tried it)
>
> Sukender
> PVLE - Lightweight cross-platform game engine - 
> http://pvle.sourceforge.net/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] LightSources duplicated

Hi Sukender,

I'm afraid I don't understand your question.

Robert.

On Tue, Nov 25, 2008 at 10:06 AM, Sukender <[EMAIL PROTECTED]> wrote:
> Re, Robert!
>
> Here is another (stupid?) question. What happens if I call:
>lightSource->getOrCreateStateSet()->setAttribute(light, 
> osg::StateAttribute::ON);
> (Please note that my models are under the "lightSource" node, and that I 
> called "lightSource->setLocalStateSetModes(osg::StateAttribute::ON);" before).
> The result seems odd (combined with the two LightSources having the same 
> number).
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
>
> Le Tue, 25 Nov 2008 10:51:33 +0100, Sukender <[EMAIL PROTECTED]> a écrit:
>
>> Thank you, Robert. I'm still investigating to try to understand the 
>> "artifact" I found about strange lighting. But what you tell gives me more 
>> questions than answers! Crap. I'll continue then. Anyway, what you say is 
>> interesting for me. Thanks again.
>>
>> Sukender
>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>>
>> Le Tue, 25 Nov 2008 10:38:36 +0100, Robert Osfield <[EMAIL PROTECTED]> a 
>> écrit:
>>
>>> Hi Sukender,
>>>
>>> If the two LightSource node, that use the same light number, fall in
>>> the same RenderStage then the last one to be traversed will be the one
>>> that takes precedence, and the previous one will be ignored.
>>> Effectively a light can only be in one place at one time.
>>>
>>> Robert.
>>>
>>> On Tue, Nov 25, 2008 at 12:14 AM, Sukender <[EMAIL PROTECTED]> wrote:
 Hi all,

 Just a stupid question (does it require a stupid answer? ;) ): What 
 happens to OpenGL/OSG when two LightSources with the same number are added 
 to the graph? How does the cull/render behave?
 (Yes, I tried it)

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

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

Re: [osg-users] Bug in viewer

Hi Tugkan,

I've just tried the same thing on my system and it worked fine.  What
window manager are you using?

A couple of things you could try:

Enable vsync

Disable any 3D desktop effects if they are on

Robert.

On Tue, Nov 25, 2008 at 8:02 AM, Tugkan Calapoglu <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I observe a problem in my own application and also on osgviewer. There are
> two images that show the problem attached to the email. I use following
> command:
>
> osgviewer --window 0 0 1280 1024 cow.osg
>
> After 3D window appears I press S to tun on statistics. The result is
> shot1.jpg. You can see that frame rate and threading model is not visible.
> After I minimize and maximize the window shot2.jpg appears. Sometimes
> osgviewer starts correctly but most of the time not.
>
> Here are details regarding the test environment:
>
> Suse 10.3
> OpenGL renderer string: GeForce 7900 GTX/PCI/SSE2
> OpenGL version string: 2.1.2 NVIDIA 173.13
> OSG version : latest SVN version
>
> Regards,
> Tugkan Calapoglu,
> VIRES Simulationstechnologie GmbH
>
> ___
> osg-users 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] osgWidget Design Advice

HI Jeremy,

On Mon, Nov 24, 2008 at 8:54 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote:
> Hello all! Allow me to talk briefly about osgWidget's current design and
> perhaps how I can change it for the better.

I'm afraid I have yet played with osgWidget enough to give a
definitive answer about WindowManger yet.  I am working towards diving
into osgWidget, my inbox just is so full... but I'm getting there...
just slowly.

I can throw a few general comments.  I'm a strong believer in loosely
coupled highly cohesive design, and the ability to add functionality
to an scene graph application by just adding subgraphs into the scene
graph without need for lots of high level refactoring of the
application to add that functionality.  A good NodeKit's will embody
this - so if you add particle system to your model file and then load
it you application suddenly can do particles systems, if you decorate
the scene with a shadow node then it'll be shadowed.

With osgWidget one of the tasks is moving the events, and in
particular mouse events, from screen space into the local coordinate
system of the widgets.  The OSG has support for an event traversal so
an event callback gets events from the viewer, and this traversal also
provides an ability to grab the current View, which does give you the
ability to then find out the camera that is currently active in the
viewer that sits above the scene graph.  View::computeIntersections()
does this camera selection for you.  The IntersectionVisitor will also
cope with internal Camera's in the parent chain (or a least since I
checked in bugs fixes for it ;-).

For the osgvnc, osgbrowser examples I introduced an
osgView::InteractiveImageHandler (even callback) that does this
conversion of the mouse pointer all done by using the osgViewer::View,
but acquiring this from the event visitor, rather than requiring the
callback itself to know about the view.  This means that you can add
the event handler to the drawable of interest and then getting events
to it, use the View* provided by the event traversal, to compute the
intersection and the reproject the coords, all without the handler or
the geometry it's attach ever know explicitly about the View.  This is
an example of a loosely coupled yet highly cohesive design in action.

Reviewing WindowManager in svn/trunk I see that it takes a pointer to
the view in its constructor, then keeps around this pointer.  This
breaks the loosely coupled requirement, as it links the subgraph with
the viewer, something that can only be done in application code.
However, it wouldn't take much to refactor WindowManger so that it had
a traverse methods that captured event traversals and then dynamically
checked for the osgViewer::View.  This would free up the WindowManager
so that it would act just as a decorator for a widget subgraph, and
could become a node that you could happily serialize in and out
without the need for hardwiring into the application code.

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

Re: [osg-users] LightSources duplicated

Re, Robert!

Here is another (stupid?) question. What happens if I call:
lightSource->getOrCreateStateSet()->setAttribute(light, 
osg::StateAttribute::ON);
(Please note that my models are under the "lightSource" node, and that I called 
"lightSource->setLocalStateSetModes(osg::StateAttribute::ON);" before).
The result seems odd (combined with the two LightSources having the same 
number).

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


Le Tue, 25 Nov 2008 10:51:33 +0100, Sukender <[EMAIL PROTECTED]> a écrit:

> Thank you, Robert. I'm still investigating to try to understand the 
> "artifact" I found about strange lighting. But what you tell gives me more 
> questions than answers! Crap. I'll continue then. Anyway, what you say is 
> interesting for me. Thanks again.
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>
> Le Tue, 25 Nov 2008 10:38:36 +0100, Robert Osfield <[EMAIL PROTECTED]> a 
> écrit:
>
>> Hi Sukender,
>>
>> If the two LightSource node, that use the same light number, fall in
>> the same RenderStage then the last one to be traversed will be the one
>> that takes precedence, and the previous one will be ignored.
>> Effectively a light can only be in one place at one time.
>>
>> Robert.
>>
>> On Tue, Nov 25, 2008 at 12:14 AM, Sukender <[EMAIL PROTECTED]> wrote:
>>> Hi all,
>>>
>>> Just a stupid question (does it require a stupid answer? ;) ): What happens 
>>> to OpenGL/OSG when two LightSources with the same number are added to the 
>>> graph? How does the cull/render behave?
>>> (Yes, I tried it)
>>>
>>> Sukender
>>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] LightSources duplicated

Thank you, Robert. I'm still investigating to try to understand the "artifact" 
I found about strange lighting. But what you tell gives me more questions than 
answers! Crap. I'll continue then. Anyway, what you say is interesting for me. 
Thanks again.

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

Le Tue, 25 Nov 2008 10:38:36 +0100, Robert Osfield <[EMAIL PROTECTED]> a écrit:

> Hi Sukender,
>
> If the two LightSource node, that use the same light number, fall in
> the same RenderStage then the last one to be traversed will be the one
> that takes precedence, and the previous one will be ignored.
> Effectively a light can only be in one place at one time.
>
> Robert.
>
> On Tue, Nov 25, 2008 at 12:14 AM, Sukender <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> Just a stupid question (does it require a stupid answer? ;) ): What happens 
>> to OpenGL/OSG when two LightSources with the same number are added to the 
>> graph? How does the cull/render behave?
>> (Yes, I tried it)
>>
>> Sukender
>> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] LightSources duplicated

Hi Sukender,

If the two LightSource node, that use the same light number, fall in
the same RenderStage then the last one to be traversed will be the one
that takes precedence, and the previous one will be ignored.
Effectively a light can only be in one place at one time.

Robert.

On Tue, Nov 25, 2008 at 12:14 AM, Sukender <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Just a stupid question (does it require a stupid answer? ;) ): What happens 
> to OpenGL/OSG when two LightSources with the same number are added to the 
> graph? How does the cull/render behave?
> (Yes, I tried it)
>
> Sukender
> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] pragma warnings disabled in headers

Hi Paul,

Wojtek's change only restores the OSG to how it's been compiling since
the very early days w.r.t disabling the least usefu/most distractingl
of the MSVC warnings.

You can disable this via CMake, so that the OSG doesn't suppress any warnings.

Fixing warnings is desirable, but has to be done with care as doing so
can introduce bugs - this has happened to the OSG in the past.
Warnings do often bring up ambiguities in the code that the author
didn't spot - which is good, but they also produce false positives -
highlighting code that is absolutely correct for it's intended usage,
but confuses developer into thinking that something is wrong and
fixing something that isn't broken, or just obfuscates the real
warnings amoungst the sea of false positives.  For this reason I'm
cautious about diving in and doing a warnings purge.

Robert.

On Mon, Nov 24, 2008 at 9:37 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> Hi all -- Sorry I'm coming into this a little late.
>
> What I'd really like is a clean compile so that if I introduce some
> suspicious code, I clearly see a new warning message displayed in the
> output, so that I can investigate it. What I don't want is to have all
> warnings disabled so that I never see a message about my bogus change. If
> the warning is displayed, but I miss it because it's buried in hundreds or
> thousands of other warnings unrelated to my code change, then that's just as
> bad as having it disabled and not displayed at all.
>
>> Perhaps the middle ground is to place the #pagma's in the
>> CMake generated include/osg/Config file?
>
> This seems like the worst solution, because not only does it disable all
> warnings in the OSG headers, it also disables it in my own application code
> that directly or indirectly includes osg/Config. If I change code and
> introduce a warning, I'll never see the warning message displayed because
> osg/Config disabled it.
>
>> The other approach is to do an explicit casts to avoid the
>> warnings in the first place.  This is more wordy and while of
>> dubious practical value would at least fix the warnings.
>
> Yes, this is probably the best solution, but is a prohibitive task to bite
> off for a large existing code base.
>
> A third solution, as Wojtek mentioned, is to wrap each OSG header file with
> #pragma push/pop so that warnings can be disabled just in the header, and
> not in user code that includes the header. This could be done by changing
> all OSG headers to include CMake-generated prefix and suffix files that
> contain the push/pops and disables. This is still an undesirable solution
> because it turns all warnings off in OSG headers, even for future code
> changes, but is no worse than what we had before and is relatively easy to
> implement.
>   -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] Effects of locale setting

Hi David,

On Mon, Nov 24, 2008 at 9:26 PM, David Spilling
<[EMAIL PROTECTED]> wrote:
> Only just caught this thread. I'm happy to update the OBJ plugin (reader
> only, presumably) if you want to lose the sscanf, as it's only recently I
> was looking at it anyway.

This would be very helpful, as I'm rather stretched right now trying
to manage all the submissions, fix bugs...

> I assume that you want all sscanf(blah, "%f", &my_float); to be replaced by
> sscanf(blah, "%s", my_char); my_float=atof(my_char), more or less, or did
> you want the whole thing done with std::string or something?

I was wondering if we might be able to reuse the osgDB ascii parsing
code.  In particular I add a set of  osgDB::Input::read(...) methods
that work like osg::ArgumentParser does in adapting generic
parameters.  It means that you can do:

   if (fin.read("mat",myFloat1,myFloat2)) { ... }

Or:

   if (fin.read("texture",myTextureString)) { ... }

This functionality was added to osgDB in the last six months, so its
usage doesn't appear too widely in the .osg plugins yet, but it
certainly makes the task of parsing much more sane.  osgDB::Input
already uses asciiToFloat/asciiToDouble.

> Was the original problem (top of the thread) a recent one, as I seem to have
> missed it if it was...

The .obj plugin not working when the locale is set was what pushed me
to raise this topic.  Earlier I had to fix the .osg plugin to handle
this issue - but I didn't look at this as a general issue.

> And sorry to be dense, but is the issue also whether OBJ writers (modelling
> programs) are locale specific, and how a user might choose the OSG .obj
> plugin to respect locale or assume a default?

For file formats my guess is that none will use a non default locale,
i.e. '.' will always be the decimal place. The only way for this to
not be the case would be where file formats explicitly declare the
locale that the format is in, but I don't know of any formats that we
load that do this.

Robert.

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

Re: [osg-users] CompositeViewer addView threading issue on Windows?

Hi J-S,

It's interesting that opening up the windows at the start allows
things to run, this suggest that it's allocation of new OpenGL that is
problem - which is something that the resize of the GL buffers would
have done the trick.

W.r.t opening 40 windows and the app crashing - this is almost
certainly down to exhustion of OpenGL resouces.

W.r.t my machine build - I have the memory here already (6GB tripple
channel), and will be reusing a case/power supply and Gfx cards from
another machine, but the key components - the CPU and the motherboard
still haven't arrived.  They should arrive today or tomorrow.  Can't
wait to put it together.  Bit nervous about whether Linux + Gfx
drivers will install without problems, the quality of an early
motherboard bios also is a concern...

Whether the new system will work properly right away and if to does
will it reproduce the hang I don't know untill I get to testing, but
test it I will.

Robert.

On Mon, Nov 24, 2008 at 7:55 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> I've had a bit of time to look at this again today. Here's another
> interesting find: adding views at startup works fine. I can add over 30 of
> them (I couldn't get to 40, the program crashes, I presume because of
> exhaustion of OpenGL resources or something).
>
> Here's a modified osgviewer.cpp which demonstrates this.
>
>   --create 20
>
> The default is to create a single view. Starting it up with a single view
> and then pressing 'a' at run time will make the program block after 4 to 6
> views for me. So there's something there.
>
> I also tested adding views after viewer.realize() but before viewer.run(),
> and this seems to work too. You can specify when to create the views
> (default is beforeRealize):
>
>   --create 20 --beforeRealize
>
> or
>
>   --create 20 --afterRealize
>
> Both work for me.
>
> So there's something going on while the viewer is running that causes the
> deadlock to occur if we add views at runtime. Adding them at any time before
> viewer.run() seems to work fine.
>
> As an aside, I've updated my graphics driver from 178.xx to 180.xx last
> Friday, but noticed no difference in this behavior.
>
>> It would be worth looking at exactly when the problem occurs - is it
>> on the stopThreading, the addView, or the startThreading or
>> thereafter?
>
> The deadlock definitely happens after the view has been added (after
> stopThreading, addView, startThreading). It looks to me that it happens on
> the first frame after adding the view.
>
> I'd really like to get to the bottom of this. When did you say you were
> going to be building your new machine? In the mean time, any chance you can
> find some time in your schedule to track down some other machine that would
> reproduce this? (JP's and Don's posts seem to indicate it can be reproduced
> on Linux on some machines...)
>
> Thanks in advance,
>
> J-S
> --
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>   http://www.cm-labs.com/
>http://whitestar02.webhop.org/
>
> /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
>  *
>  * This application is open source and may be redistributed and/or modified
>  * freely and without restriction, both in commericial and non commericial
> applications,
>  * as long as this copyright notice is maintained.
>  *
>  * This application is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> */
>
> #include 
> #include 
> #include 
>
> #include 
> #include 
>
> #include 
> #include 
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #include 
>
>
> // Forward declaration
> void addView(osgViewer::CompositeViewer* viewer, osg::Node* sceneRoot);
>
>
> class AddViewHandler : public osgGA::GUIEventHandler
> {
> public:
>AddViewHandler(osgViewer::CompositeViewer* viewer, osg::Node* sceneRoot)
>: _viewer(viewer), _sceneRoot(sceneRoot) {}
>
>bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter&
> aa)
>{
>if (ea.getEventType() == osgGA::GUIEventAdapter::KEYDOWN &&
> ea.getKey()== 'a')
>{
>addView(_viewer.get(), _sceneRoot);
>return true;
>}
>
>return false;
>}
>
> protected:
>osg::observer_ptr _viewer;
>osg::ref_ptr  _sceneRoot;
> };
>
>
> void addEventHandlers(osgViewer::View* view, osgViewer::CompositeViewer*
> viewer, osg::Node* sceneRoot)
> {
>// set up the camera manipulators.
>view->setCameraManipulator( new osgGA::TrackballManipulator() );
>
>// add the state manipulator
>view->addEventHandler( new
> osgGA::StateSetManipulator(view->getCamera()->getOrCreateStateSet()) );
>
>// add the thread model handler
>view->addEventHandler(new osgViewer::ThreadingH

Re: [osg-users] osgWidget Design Advice

Hi Jeremy,

I really agree with Jean-Sébastien. The main difference is that he seems to 
know more about OSG than me! I just have to tell "That's just what I wanted to 
say!"...

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


Le Tue, 25 Nov 2008 05:22:47 +0100, Jean-Sébastien Guay <[EMAIL PROTECTED]> a 
écrit:

> Hi Jeremy,
>
>> Why does the WindowManager have to know anything about cameras?
>
> I have the same question, but with different results: unless I've missed
> something in your description, why does anyone need to know about the
> camera? If you get your click events (which you act upon to get
> intersections) through an event handler, then you can just get an
> osg::View* with aa.asView(), which then has a camera. No one really
> needs to hold on to a camera pointer.
>
> I would definitely go with calculating intersections directly through
> osgUtil::IntersectionVisitor. You can use the constructor that takes one
> of the WINDOW, PROJECTION, VIEW and MODEL enum values to easily
> construct the right intersector. It should even work for 3D "widgets in
> space... space ... space ..." :-)
>
> As for creating an ortho viewport, perhaps you can return an osg::Camera
> with the right setup, and the user can then assign that to their
> viewer/view/slave camera/scenegraph/whatever. It would be more general.
>
> That way you can remove the dependency between osgWidget and osgViewer
> (not sure if that's the goal here, but if intersections was the only
> thing that forced that dependency, I'd definitely remove it).
>
> Anyways, like the others who replied I don't really know the internals
> of osgWidget, so perhaps there's something I've overlooked, but that's
> how I see it at first glance.
>
> Hope this helps,
>
> J-S

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

Re: [osg-users] osgWidget Design Advice