Re: [osg-users] ScreenSpaceAmbientOcclusion

2008-12-19 Thread Adrian Egli OpenSceneGraph (3D)
Starting point of this first version is this very simple algorithm:
http://mikepan.homeip.net/ssaowcn

once this will perfectly work, then we can implementing a more complex one.

there are many diferent papers describing how we can implementing high
quality SSAO

/adrian

2008/12/18 Raymond de Vries ree...@xs4all.nl

 Hi Adrian,

 This looks very nice! Could you give a little more background info? Did you
 use the nvidia paper as starting point? E.g. I am curious if this technique
 is applicable for large outdoor environments.

 Thanks a lot
 Raymond



 Adrian Egli OpenSceneGraph (3D) wrote:

 Hi Robert,

 i implement a first version of SSAO effect and i have only one issue left
 in the implementation. the whole thing works nicely with GLSL shader,
 mutlipass-rendering when we don't resize the window, actually 512x512. so
 what sould i do, to replace this issue. ?

 Another thing is to remove the last pass GLSL shader, is there a way to
 solve it under common openGL textureing? Mutlitextureing? Or any other idea.

 This version supports:

 (Transparant faces: just disable for transparent faces like window, glass
 the detph writing, the depth buffer will hold only un-transparent z-values
 (alpha  0.9) )

 toggle ssao on/off with key 'a'

 have a look and i will be happy to get any ideas to improve the stuff.
 FPS is about 30.

 /adrian
 --
 
 Adrian Egli
 

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


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




-- 

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


Re: [osg-users] ScreenSpaceAmbientOcclusion

2008-12-19 Thread Adrian Egli OpenSceneGraph (3D)
Next step will be to implement latest NVidia stuff...
http://www.nvidia.com/object/siggraph-2008-HBAO.html

2008/12/19 Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com

 Starting point of this first version is this very simple algorithm:
 http://mikepan.homeip.net/ssaowcn

 once this will perfectly work, then we can implementing a more complex one.


 there are many diferent papers describing how we can implementing high
 quality SSAO

 /adrian

 2008/12/18 Raymond de Vries ree...@xs4all.nl

 Hi Adrian,


 This looks very nice! Could you give a little more background info? Did
 you use the nvidia paper as starting point? E.g. I am curious if this
 technique is applicable for large outdoor environments.

 Thanks a lot
 Raymond



 Adrian Egli OpenSceneGraph (3D) wrote:

 Hi Robert,

 i implement a first version of SSAO effect and i have only one issue left
 in the implementation. the whole thing works nicely with GLSL shader,
 mutlipass-rendering when we don't resize the window, actually 512x512. so
 what sould i do, to replace this issue. ?

 Another thing is to remove the last pass GLSL shader, is there a way to
 solve it under common openGL textureing? Mutlitextureing? Or any other idea.

 This version supports:

 (Transparant faces: just disable for transparent faces like window, glass
 the detph writing, the depth buffer will hold only un-transparent z-values
 (alpha  0.9) )

 toggle ssao on/off with key 'a'

 have a look and i will be happy to get any ideas to improve the stuff.
 FPS is about 30.

 /adrian
 --
 
 Adrian Egli
 

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


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




 --
 
 Adrian Egli




-- 

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


Re: [osg-users] vpb - strange tile corner artifacts

2008-12-19 Thread christophe loustaunau
On Fri, Dec 19, 2008 at 8:28 AM, J.P. Delport jpdelp...@csir.co.za wrote:

 OK,

 931 still OK, 932 starts giving the artifacts.

 Time to consult the diff...


You're near the bug ! :-)

Looking at the log, i see that in destination.cpp ,the function  :
void DestinationTile::equalizeCorner(Position position)

have been change. It may be here.



 jp

 J.P. Delport wrote:

 Hi,

 yes, you are right, I still have not had the coffee, I've been chasing
 this bug till late last night.

 I thought that I tried 948 after 930, but the database did not rebuild.
 Note to self, always clean build directory first.

 So I can confirm:
 930 is OK, 948 not OK.

 Your data makes the testing easier, thanks.

 Will go up through the versions now...

 jp

 christophe loustaunau wrote:

 HI,

 Strange, with rev948 I still have artifacts but not with rev930.
 All is done with rev 9368 of osg.



 On Fri, Dec 19, 2008 at 7:38 AM, J.P. Delport jpdelp...@csir.co.zamailto:
 jpdelp...@csir.co.za wrote:

Hi,

sorry, should have had that coffee first...

I've tested vpb r948 and it still works OK.

jp


J.P. Delport wrote:

Hi,

I've narrowed down the versions that worked a bit more.

With osg r9387 and vpb r930 I'm not getting the artifacts, so at
least the problem is isolated to vpb, as older vpb with osg head
seems to work OK. I will try to find the revision where it
starts breaking.

Christophe, can you try this combination of versions and see if
your artifacts disappear as well?

Still digging...

jp


christophe loustaunau wrote:

sorry copy/paste error, here is the adress for the two geotiff
 :


 http://cloustaunau.free.fr/data/temporaryfile_w111.98_n41.123.tif

 http://cloustaunau.free.fr/data/temporaryfile_w111.975_n41.123.tif

 http://cloustaunau.free.fr/data/temporaryfile_w111.98_n41.123.tif

regards.

-- Christophe Loustaunau.



  

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

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



-- This message is subject to the CSIR's copyright terms and
conditions, e-mail legal notice, and implemented Open Document
Format (ODF) standard. The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.  MailScanner thanks
Transtec Computers for their support.

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

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




 --
 Christophe Loustaunau.


 

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



 --
 This message is subject to the CSIR's copyright terms and conditions,
 e-mail legal notice, and implemented Open Document Format (ODF) standard.
 The full disclaimer details can be found at
 http://www.csir.co.za/disclaimer.html.

 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.  MailScanner thanks Transtec
 Computers for their support.

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




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


Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4

2008-12-19 Thread Robert Osfield
Hi Paul,

On Thu, Dec 18, 2008 at 6:37 PM, Paul Fotheringham osg_u...@yahoo.co.uk wrote:
 Hi Robert,

 Thanks for looking into this.

 --- On Thu, 18/12/08, Robert Osfield robert.osfi...@gmail.com wrote:
 snip
 The core OSG library does link against the MATH_LIBRARY,
 but the other
 non of the other core libraries do.

 Apparently not on MacOSX using cmake :)

Please read what I've already written.  I've been using Cmake under
OSX as others have been as well, without problems.


 Take a look at

 src/osgText/CMakeFiles/osgText.dir/link.txt

 without the change you just made. In fact take a look at any of the link.txt 
 files for each OSG library. Thay all have /usr/lib/libm.dylib in there.

 I've added a entry of
 MATH_LIBRARY into the linking of osgText.  Could you do an
 svn update
 and see if the error is fixed?

 I got the svn version and no it doesn't fix it. All it does is move the

 /usr/lib/libm.dylib

 reference on the link line to a different place!

 The fact you've got errors but others under OSX
 haven't reported this
 (including myself) suggests that must be something else
 going w.r.t
 gcc/SDK's you are using on your machine.

 I'm sorry I haven't explained this well enough. The goal here is to *not* 
 have any explicit reference to libm.dylib on the link line.

 The symbols reside in the SDK version of the library at

 /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib

 and *not* necessarily at

 /usr/lib/libm.dylib

 which is what the MATH_LIBRARY is set to. This is fine for UNIX but not Mac 
 as it should be the former that is used for a consistent build (if there are 
 Mac developers out there who disagree please correct me - I'm new to this).

 By omitting the explicit reference to libm.dylib the Mac build system takes 
 care of this automatically and gets the symbols from the SDK version of the 
 library.

 Users who are not seeing this problem have all the symbols they require in 
 /usr/lib/libm.dylib and are, as I understand it, lucky ;)

I'll will check what value is used on the OSX box that I was remote
compiling on.

Could you please remove the MATH_LIBRARY entry in the
src/osg/CMakeLists.txt and src/osgText/CMakeLists.txt to test your
theory about not needing it.

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


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Paul Melis

Hi J-S,

Jean-Sébastien Guay wrote:
I am currently chasing memory leaks in our application, which is like 
a modeling tool where the user will open/work on/save/close data files 
multiple times during the same application run. What we are seeing is 
that when a file is closed, not all memory related to scene graph 
objects seems to be released.


First question:

I enabled the DEBUG_OBJECT_ALLOCATION_DESTRUCTION define in 
src/osg/Referenced.cpp, and have set up a small test which just 
creates two viewers one after the other in different scopes. Pseudocode:

[...]

What I see is this (all in debug):

Breakpoint #1 :8 Referenced objects,  12MB
First viewer run  : ~505 Referenced objects, 266MB
Breakpoint #2 :  247 Referenced objects, 167MB
Second viewer run : ~505 Referenced objects, 266MB
Breakpoint #3 :  247 Referenced objects, 172MB

But then, when I pass breakpoint #3, all the destructors for those 
Referenced objects are called, and at the end no objects are left 
allocated. (I can see that the final number of objects is 0)


Other than seeing that there are no real leaks per se, my question 
about that is, what are those objects that are staying alive outside 
the scopes? 
You could perhaps hack on the DEBUG_OBJECT_ALLOCATION_DESTRUCTION code 
in src/osg/Referenced.cpp a bit and, for instances that derive from 
Object, print their libraryName()+className() as they get 
created/destoyed instead of just the total number of objects. Maybe that 
can give you some information on which objects stay around.


Paul

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


[osg-users] OSG2.6 libs created by VC2008 are lower than the ones created by VC2003?

2008-12-19 Thread Leeten
Hi, all

I use OSG2.6.0 on Windows XP SP3. I generated both OSG2.6 libs under VC 2008 
and VC 2003, both under Debug mode. When I test my app's FPS, I found an 
interesting thing: when I load the same file in the same app, the FPS is 
different when using different libs. The details are shown in followed table.

Geode Num in Input ModelOSG vertionIDEModeFPS
23002.6VC2008Debug2
23002.6VC2003Debug75
23002.2VC2003Debug75


To be attantion, the refresh frequence of my screen is set to 75Hz. When I used 
VC2008 debug libs, the apps is too slow to stand.

I wonder why it happens? did I generate the libs in a wrong way? Thank you for 
any help.

2008-12-19 



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


Re: [osg-users] vpb - strange tile corner artifacts

2008-12-19 Thread J.P. Delport

Hi,

christophe loustaunau wrote:
 
You're near the bug ! :-)


Looking at the log, i see that in destination.cpp ,the function  :
void DestinationTile::equalizeCorner(Position position)

have been change. It may be here.



Yes, this was my first place to look too.

I think I found the error, getImageSet(layerNum) was called on the wrong 
DestinationTile.


Could you try this file with r932 and see if you get OK results, I want 
to double check before I see if the fix works with vpb HEAD.


jp

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.




Destination.cpp.gz
Description: GNU Zip compressed data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Stephan Huber
Hi Jean-Sébastien,

Jean-Sébastien Guay schrieb:

 However, running IBM Purify on the application reveals no massive leaks,
 only a few false positives. Are there any tools or techniques that
 someone could recommend to make finding and fixing memory leaks easy,
 and which work well with OSG? I tried Visual Leak Detector which is open
 source, but it reported so many false positives related to variables
 stored in ref_ptrs (over 400) that I gave up on it.

For that type of debugging I am using a custom singleton-class called
AllocationObserver which observes the refcount for osg::Referenced. You
have to register every instance of objects you want to track and the
AllocationObserver saves these instances as a

std::mapstd::string, std::listosg::observer_ptrosg::Referenced  

I am using a custom NodeVisitor to feed the scene graph to the
allocation-observer which prints out the refcounts / updates a
line-graph for the different object-types and cleans up the std::lists
of already deleted objects on a regular basis.

This works quite well for my high dynamic scene graphs, but has a slight
impact on performance and does not cover all referenced objects.

I am using Memory Validator on Windows and Shark / MallocDebug on Mac OS
X to track other memory-leaks, but these tools do not help me when using
refcounted-objects or finding circular-references.

If you are interested in the code (it's integrated with other code, but
the principle should be clear) drop me a line.

Cheers,
Stephan


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


Re: [osg-users] another VPB question...

2008-12-19 Thread Robert Osfield
HI Shayne,

This isn't a error message that I've written so it must be some that
GDAL is emitting.  As to why I cannot say.  Perhaps the GDAL community
might be familiar with it.

Robert.

On Thu, Dec 18, 2008 at 9:58 PM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:
 All,



 Occasionally I get the following warning when I'm building a database using
 VPB:



 Warning 1: PackBitsDecode:Discarding 52 bytes to avoid buffer overrun



 Does anyone know what this pertains to or why it is happening?



 Thanks,

 -Shayne

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


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


Re: [osg-users] vpb - strange tile corner artifacts

2008-12-19 Thread christophe loustaunau
Hi,

I have no bug with r932 and your file.
It seems to be good !

On Fri, Dec 19, 2008 at 10:05 AM, J.P. Delport jpdelp...@csir.co.za wrote:

 Hi,

 christophe loustaunau wrote:

  You're near the bug ! :-)

 Looking at the log, i see that in destination.cpp ,the function  :
 void DestinationTile::equalizeCorner(Position position)

 have been change. It may be here.


 Yes, this was my first place to look too.

 I think I found the error, getImageSet(layerNum) was called on the wrong
 DestinationTile.

 Could you try this file with r932 and see if you get OK results, I want to
 double check before I see if the fix works with vpb HEAD.

 jp


 --
 This message is subject to the CSIR's copyright terms and conditions,
 e-mail legal notice, and implemented Open Document Format (ODF) standard.
 The full disclaimer details can be found at
 http://www.csir.co.za/disclaimer.html.

 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.  MailScanner thanks Transtec
 Computers for their support.


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




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


Re: [osg-users] osgDB::DynamicLibrary dlopen flags?

2008-12-19 Thread Robert Osfield
Hi Hartmut,

I haven't been following you discussion too closely, but I've read
through it.  I didn't have any insight to add, more just trying to
learn about stuff I'm not too involved in.

Do the the symptoms of this problem appear when running the
osgintrospection example?

W.r.t changing/adding options for different flags in DynamicLibrary, I
don't see why this couldn't be done.  Could you try tweaking
DynamicLibrary and if it's successful at addressing the problems you
are seeing then we can look to get something checked in.

Robert.

On Thu, Dec 18, 2008 at 10:04 PM, Hartmut Seichter
li...@technotecture.com wrote:

 Hi Robert,

 not sure if you followed my discussion with Jose-Luis regarding osgLua and
 the problem of stripped RTTI - actually I figured I was barking up the wrong
 tree. osgIntrospection wrappers will not work on dlopen based systems with
 gcc  3.x as the osgDB::DynamicLibrary has hardwired the RTLD_LAZY flag in
 there. Is there a chance that we can get the possibility to set these flags
 in order to use the introspection. For the time being I need to implement my
 own loader.

 Cheers,
 Hartmut




 --
 Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ

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

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


Re: [osg-users] vpb - strange tile corner artifacts

2008-12-19 Thread J.P. Delport

Hi,

good, I've also tested the fix with vpb HEAD and it seems OK. Busy 
testing on a larger database and if it works I'll submit the fix.


jp

christophe loustaunau wrote:

Hi,

I have no bug with r932 and your file.
It seems to be good !

On Fri, Dec 19, 2008 at 10:05 AM, J.P. Delport jpdelp...@csir.co.za 
mailto:jpdelp...@csir.co.za wrote:


Hi,


christophe loustaunau wrote:

 You're near the bug ! :-)

Looking at the log, i see that in destination.cpp ,the function  :
void DestinationTile::equalizeCorner(Position position)

have been change. It may be here.


Yes, this was my first place to look too.

I think I found the error, getImageSet(layerNum) was called on the
wrong DestinationTile.

Could you try this file with r932 and see if you get OK results, I
want to double check before I see if the fix works with vpb HEAD.

jp


-- 
This message is subject to the CSIR's copyright terms and

conditions, e-mail legal notice, and implemented Open Document
Format (ODF) standard. The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.  MailScanner thanks
Transtec Computers for their support.


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




--
Christophe Loustaunau.




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


--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


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


Re: [osg-users] depth partition

2008-12-19 Thread Robert Osfield
HI David?  (Please sign with the name you wish to be addressed with so
we know who to address)

I'm not very familiar with the osgdepthpartiion example but I do
understand the general concept.  My expectation is that for a specific
type of application you could probably come up with your own mechanism
for management of the mid depth that divides the two regions, you may
even be able to use a fixed range, this way would you could avoid the
need to traversing the scene for the purposes of depth partitioning.

Robert.

On Fri, Dec 19, 2008 at 7:37 AM, ZHMW david@gmail.com wrote:
 Hi everyone!
 In my application, there is many terrain object, each terrain object is
 a tree organized by paged lod, just like the structure generated by virtual
 planet builder.
 The problem is I cannot integrate many terrain object in one scene. It
 seems to be the depth problem, And I have tried the osgdepthpartation
 example. but the visitor in that example cannot process lod nodes. so, I 'm
 over writting the apply method for PagedLOD.
 I want to know, what I'm doing is in the right way, And is there any
 other better solutions?
 Thanks!
 Best Wishes.

 ___
 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] osgLua?

2008-12-19 Thread Jose Luis Hidalgo
Hi Haltmut,

On Thu, Dec 18, 2008 at 1:23 AM, Hartmut Seichter
li...@technotecture.com wrote:
 Are you still working on osgLua? I can flick you a few patches that might
 fix a couple of problems.

Yes please :) send them to me :) I've switched to mac (again) and I'm
trying to make osgLua work, with very little time, but trying to catch
up with the current OSG trunk.

The RTTI problem, apart from the LD_GLOBAL, and the linker flags (
-Wl,-E ).. I can't tell what's going on sorry.

Cheers,
   Jose-Luis.

-- 
  Jose L. Hidalgo Valiño (PpluX)
   http://www.pplux.com 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Paul Melis

Paul Melis wrote:

Hi J-S,

Jean-Sébastien Guay wrote:
I am currently chasing memory leaks in our application, which is like 
a modeling tool where the user will open/work on/save/close data 
files multiple times during the same application run. What we are 
seeing is that when a file is closed, not all memory related to scene 
graph objects seems to be released.


First question:

I enabled the DEBUG_OBJECT_ALLOCATION_DESTRUCTION define in 
src/osg/Referenced.cpp, and have set up a small test which just 
creates two viewers one after the other in different scopes. Pseudocode:

[...]

What I see is this (all in debug):

Breakpoint #1 :8 Referenced objects,  12MB
First viewer run  : ~505 Referenced objects, 266MB
Breakpoint #2 :  247 Referenced objects, 167MB
Second viewer run : ~505 Referenced objects, 266MB
Breakpoint #3 :  247 Referenced objects, 172MB

But then, when I pass breakpoint #3, all the destructors for those 
Referenced objects are called, and at the end no objects are left 
allocated. (I can see that the final number of objects is 0)


Other than seeing that there are no real leaks per se, my question 
about that is, what are those objects that are staying alive outside 
the scopes? 
You could perhaps hack on the DEBUG_OBJECT_ALLOCATION_DESTRUCTION code 
in src/osg/Referenced.cpp a bit and, for instances that derive from 
Object, print their libraryName()+className() as they get 
created/destoyed instead of just the total number of objects. Maybe 
that can give you some information on which objects stay around.
Just tried to add this myself, but this is problematic as (part of) the 
debug info is printed from Referenced's constructor. At that point 
dynamic_cast and typeid don't give the actual type being constructed, 
but merely the constructor's type (i.e. Referenced). Browsing some more 
for that it seems the C++ spec says the results are actually undefined.  
So there's no way to dyncast a Referenced to an Object (to get to its 
className()), at least not at the point where currently the object 
tracking is done.


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


Re: [osg-users] ScreenSpaceAmbientOcclusion

2008-12-19 Thread Raymond de Vries

Hi Adrian,

Thnx for the info, cool that it's already implemented in Blender :-)

Cheers, have fun.

Raymond


Adrian Egli OpenSceneGraph (3D) wrote:

Starting point of this first version is this very simple algorithm:
http://mikepan.homeip.net/ssaowcn

once this will perfectly work, then we can implementing a more complex 
one.


there are many diferent papers describing how we can implementing high 
quality SSAO


/adrian

2008/12/18 Raymond de Vries ree...@xs4all.nl mailto:ree...@xs4all.nl

Hi Adrian,

This looks very nice! Could you give a little more background
info? Did you use the nvidia paper as starting point? E.g. I am
curious if this technique is applicable for large outdoor
environments.

Thanks a lot
Raymond



Adrian Egli OpenSceneGraph (3D) wrote:

Hi Robert,

i implement a first version of SSAO effect and i have only one
issue left in the implementation. the whole thing works nicely
with GLSL shader, mutlipass-rendering when we don't resize the
window, actually 512x512. so
what sould i do, to replace this issue. ?

Another thing is to remove the last pass GLSL shader, is there
a way to solve it under common openGL textureing?
Mutlitextureing? Or any other idea.

This version supports:

(Transparant faces: just disable for transparent faces like
window, glass the detph writing, the depth buffer will hold
only un-transparent z-values (alpha  0.9) )

toggle ssao on/off with key 'a'

have a look and i will be happy to get any ideas to improve
the stuff.
FPS is about 30.

/adrian
-- 


Adrian Egli


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

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


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




--

Adrian Egli


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


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


Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4

2008-12-19 Thread Paul Fotheringham
--- On Fri, 19/12/08, Robert Osfield robert.osfi...@gmail.com wrote:

 From: Robert Osfield robert.osfi...@gmail.com
 Subject: Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4
 To: osg_u...@yahoo.co.uk, OpenSceneGraph Users 
 osg-users@lists.openscenegraph.org
 Date: Friday, 19 December, 2008, 8:46 AM
 Hi Paul,
 
 On Thu, Dec 18, 2008 at 6:37 PM, Paul Fotheringham
 osg_u...@yahoo.co.uk wrote:
  Hi Robert,
 
  Thanks for looking into this.
 
  --- On Thu, 18/12/08, Robert Osfield
 robert.osfi...@gmail.com wrote:
  snip
  The core OSG library does link against the
 MATH_LIBRARY,
  but the other
  non of the other core libraries do.
 
  Apparently not on MacOSX using cmake :)
 
 Please read what I've already written.  I've been
 using Cmake under
 OSX as others have been as well, without problems.

I've already explained not once, but twice now, why that is.

  Take a look at
 
  src/osgText/CMakeFiles/osgText.dir/link.txt
 
  without the change you just made. In fact take a look
 at any of the link.txt files for each OSG library. Thay all
 have /usr/lib/libm.dylib in there.
 
  I've added a entry of
  MATH_LIBRARY into the linking of osgText.  Could
 you do an
  svn update
  and see if the error is fixed?
 
  I got the svn version and no it doesn't fix it.
 All it does is move the
 
  /usr/lib/libm.dylib
 
  reference on the link line to a different place!
 
  The fact you've got errors but others under
 OSX
  haven't reported this
  (including myself) suggests that must be something
 else
  going w.r.t
  gcc/SDK's you are using on your machine.
 
  I'm sorry I haven't explained this well
 enough. The goal here is to *not* have any explicit
 reference to libm.dylib on the link line.
 
  The symbols reside in the SDK version of the library
 at
 
  /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib
 
  and *not* necessarily at
 
  /usr/lib/libm.dylib
 
  which is what the MATH_LIBRARY is set to. This is fine
 for UNIX but not Mac as it should be the former that is used
 for a consistent build (if there are Mac developers out
 there who disagree please correct me - I'm new to this).
 
  By omitting the explicit reference to libm.dylib the
 Mac build system takes care of this automatically and gets
 the symbols from the SDK version of the library.
 
  Users who are not seeing this problem have all the
 symbols they require in /usr/lib/libm.dylib and are, as I
 understand it, lucky ;)
 
 I'll will check what value is used on the OSX box that
 I was remote
 compiling on.
 
 Could you please remove the MATH_LIBRARY entry in the
 src/osg/CMakeLists.txt and src/osgText/CMakeLists.txt to
 test your
 theory about not needing it.

I agree that only libosg needs it. osgText only needs it indirectly. If I 
remove the MATH_LIBRARY entry from src/osgText/CMakeLists.txt then 
/usr/lib/libm.dylib still apears in the link line. To be more precise, it 
appears in src/osgText/CMakeFiles/osgDB.dir/link.txt which, with my limited 
knowledge of cmake, is what I assume it uses to perform the link.

As I implied in my first post, all these references to /usr/lib/libm.dylib on 
the link lines seem to come from the FIND_LIBRARY(MATH_LIBRARY m) line in the 
top-level CMakeLists.txt as they all go away if I remove that.


 Robert.

Paul


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


Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4

2008-12-19 Thread Robert Osfield
Hi Paul,

What happens if, using ccamke, you manually set the MATH_LIBRARY to 
or to your frameworks version?

Robert.

On Fri, Dec 19, 2008 at 11:06 AM, Paul Fotheringham
osg_u...@yahoo.co.uk wrote:
 --- On Fri, 19/12/08, Robert Osfield robert.osfi...@gmail.com wrote:

 From: Robert Osfield robert.osfi...@gmail.com
 Subject: Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4
 To: osg_u...@yahoo.co.uk, OpenSceneGraph Users 
 osg-users@lists.openscenegraph.org
 Date: Friday, 19 December, 2008, 8:46 AM
 Hi Paul,

 On Thu, Dec 18, 2008 at 6:37 PM, Paul Fotheringham
 osg_u...@yahoo.co.uk wrote:
  Hi Robert,
 
  Thanks for looking into this.
 
  --- On Thu, 18/12/08, Robert Osfield
 robert.osfi...@gmail.com wrote:
  snip
  The core OSG library does link against the
 MATH_LIBRARY,
  but the other
  non of the other core libraries do.
 
  Apparently not on MacOSX using cmake :)

 Please read what I've already written.  I've been
 using Cmake under
 OSX as others have been as well, without problems.

 I've already explained not once, but twice now, why that is.

  Take a look at
 
  src/osgText/CMakeFiles/osgText.dir/link.txt
 
  without the change you just made. In fact take a look
 at any of the link.txt files for each OSG library. Thay all
 have /usr/lib/libm.dylib in there.
 
  I've added a entry of
  MATH_LIBRARY into the linking of osgText.  Could
 you do an
  svn update
  and see if the error is fixed?
 
  I got the svn version and no it doesn't fix it.
 All it does is move the
 
  /usr/lib/libm.dylib
 
  reference on the link line to a different place!
 
  The fact you've got errors but others under
 OSX
  haven't reported this
  (including myself) suggests that must be something
 else
  going w.r.t
  gcc/SDK's you are using on your machine.
 
  I'm sorry I haven't explained this well
 enough. The goal here is to *not* have any explicit
 reference to libm.dylib on the link line.
 
  The symbols reside in the SDK version of the library
 at
 
  /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib
 
  and *not* necessarily at
 
  /usr/lib/libm.dylib
 
  which is what the MATH_LIBRARY is set to. This is fine
 for UNIX but not Mac as it should be the former that is used
 for a consistent build (if there are Mac developers out
 there who disagree please correct me - I'm new to this).
 
  By omitting the explicit reference to libm.dylib the
 Mac build system takes care of this automatically and gets
 the symbols from the SDK version of the library.
 
  Users who are not seeing this problem have all the
 symbols they require in /usr/lib/libm.dylib and are, as I
 understand it, lucky ;)

 I'll will check what value is used on the OSX box that
 I was remote
 compiling on.

 Could you please remove the MATH_LIBRARY entry in the
 src/osg/CMakeLists.txt and src/osgText/CMakeLists.txt to
 test your
 theory about not needing it.

 I agree that only libosg needs it. osgText only needs it indirectly. If I 
 remove the MATH_LIBRARY entry from src/osgText/CMakeLists.txt then 
 /usr/lib/libm.dylib still apears in the link line. To be more precise, it 
 appears in src/osgText/CMakeFiles/osgDB.dir/link.txt which, with my limited 
 knowledge of cmake, is what I assume it uses to perform the link.

 As I implied in my first post, all these references to /usr/lib/libm.dylib on 
 the link lines seem to come from the FIND_LIBRARY(MATH_LIBRARY m) line in the 
 top-level CMakeLists.txt as they all go away if I remove that.


 Robert.

 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] Strange error on 2.7.7 VC8.1 INSTALL(Release) target

2008-12-19 Thread Roger James




I just did a build on a clean 2.7.7 source tree using Visual Studio
8.1. When I came to do the Release INSTALL target I got a failure
whilst it was copying header files into the "\Program
Files\OpensceneGraph\Include" directory. The error message was not very
informative, it just said "failed to copy". I looked into the directory
and all the files up to the one the failed had a new date stamp. On a
whim I reran the INSTALL target and this time it got past the file it
had failed on and failed on another header file further on. I reran it
a couple more times and it got further each time eventually completing
without error. It looks like there may be an error in the Cmake file
install scripts when they have to copy a large a number of files. The
reason it appeared to get further each time appeared to be because the
header files it had already copied now showed as "up to date" rather
than "Installing". If anyone else sees this don't worry just rerun the
INSTALL. I leave this to anyone who understands CMake to fix!


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


Re: [osg-users] High resolution screencast

2008-12-19 Thread Simon Loic
Hi, thanks guys for your help,

Ümit:
I'm indeed using Ubuntu...
I don't see how using an external camera can help. In fact the lags are not
due to istanbul but to the complexity of the scene : even without
screencasting my graphic card is not able to render at a sufficient frame
rate.

Sukender:
Your proposal seems to fit what I wanna do. Though I need some more help
about some points.

First, a point you didn't referred to in your pseudo code : How will I move
around the scene? Are you thinking of traversing along an osg::AnimationPath
like I proposed? If so, do you have any Idea of how to do this?

Second, I tried some times ago to do an offscreen rendering but If you know
an easy way in osg to do it I'm interested (I think there are ways based on
osg::Camera::DrawCallBack).

Eventually, do you know some good (easy to handle) API for compressing
video?

Thanks a lot for your support.

On Thu, Dec 18, 2008 at 11:00 PM, Sukender suky0...@free.fr wrote:

 Hi Simon,

 I got a solution for you, which is not an out-of-the-box one and requires a
 little coding, but I already did a similar thing to capture the output of an
 OpenGL/SDL app and it worked properly:

 You may tweak the main loop and control yourself the simulation time of the
 scene graph. That way, you could render and capture a constant frame-rate
 video (25fps for example). The video rendering is then not realtime: if your
 PC is fast, the redering will last less than the video, but the video itslef
 would always have a constant frame rate. Here is my solution in pseudo-code:
 while( !viewer.done() ) {
videoTime += 1/25.f;  // Advance 1/25th of second
viewer.frame(videoTime);  // ... and tell the scene graph
Capture the rendered image
If you have an API for compressing video, send the captured image to it.
 Else save it to disk for manual encoding.
 }

 Hope it helps.

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


 Le Thu, 18 Dec 2008 20:38:12 +0100, Simon Loic simon1l...@gmail.com a
 écrit:

  Hi,
 
  I apology in advance if this thread have been heavily answered before (if
 so
  just tell where I can find the solution). Still I would like to know the
  different alternative (the good ones) to record a video of my scene.
  So far I was using an external tool for screenCast (called istanbul). But
  I'm not satisfied by this because when my scene is very complex, my osg
  based application is lagging and this leads to a poor quality of th
 video.
 
  I'm especially interested if there is a way to create an
  RecordCameraPathHandler to record a path, and then instead of saving it
 as a
  .path file compute the video in a batch mode. By batch mode I mean that
 the
  creation of the video doesn't need to be real time. In that way I could
  hopefully control the lag effects and eventually the resolution of the
  video.
 
  Sincerely,

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




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


Re: [osg-users] Strange error on 2.7.7 VC8.1 INSTALL(Release) target

2008-12-19 Thread Mattias Helsing
Hi Roger,

On 12/19/08, Roger James ro...@beardandsandals.co.uk wrote:
 I just did a build on a clean 2.7.7 source tree using Visual Studio 8.1.
 When I came to do the Release INSTALL target I got a failure whilst it was
 copying header files into the \Program Files\OpensceneGraph\Include
 directory. The error message was not very informative, it just said failed
 to copy. I looked into the directory and all the files up to the one the
 failed had a new date stamp. On a whim I reran the INSTALL target and this
 time it got past the file it had failed on and failed on another header file
 further on. I reran it a couple more times and it got further each time
 eventually completing without error. It looks like there may be an error in
 the Cmake file install scripts when they have to copy a large a number of
 files. The reason it appeared to get further each time appeared to be
 because the header files it had already copied now showed as up to date
 rather than Installing. If anyone else sees this don't worry just rerun
 the INSTALL. I leave this to anyone who understands CMake to fix!


I'm not sure it needs fixing. I just ran an install of my entire build
tree including the reference docs (1 files). I'm on winxp with
msvc8 sp1 with osg-2.7.8. No problems reported (except that with an
encrypted ntfs drive it takes a bit of time :)

What you are seeing could have many causes. Could be that you are
installing to a network drive, antivirus software, hard drive
failures, ...

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


[osg-users] Chinese character problem in PagedLod

2008-12-19 Thread Simba
Hi all,
   I found that if filenames in pagedlod node contain Chinese character, osg 
will not be able to load file correctly, have anyone met this before? Even if I 
use setlocale(LC_ALL,chs), it will still not do. Help...
   This is one of my pagedlod node:
   PagedLOD {
nodeMask 0x
cullingActive TRUE
Radius 100
RangeMode DISTANCE_FROM_EYE_POINT
RangeList 1 {
  0 3000
}
NumChildrenThatCannotBeExpired 0
FileNameList 1 {
  a-暨济春天园-01.ive
}
num_children 0
  }
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OSG2.6 libs created by VC2008 are lower than the onescreated by VC2003?

2008-12-19 Thread Erik den Dekker
I think that as a general rule it is not advisable to do performance tests
in Debug mode, you should always use Release mode for that. Also, are you
using the default optimization flags given by cmake for both compilers?
These should be ok.

 Erik

  _  

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Leeten
Sent: Friday, December 19, 2008 10:04
To: osg-users
Subject: [osg-users] OSG2.6 libs created by VC2008 are lower than the
onescreated by VC2003?

 

Hi, all

 

I use OSG2.6.0 on Windows XP SP3. I generated both OSG2.6 libs under VC 2008
and VC 2003, both under Debug mode. When I test my app's FPS, I found an
interesting thing: when I load the same file in the same app, the FPS is
different when using different libs. The details are shown in followed
table.

 


Geode Num in Input Model

OSG vertion

IDE

Mode

FPS


2300

2.6

VC2008

Debug

2


2300

2.6

VC2003

Debug

75


2300

2.2

VC2003

Debug

75

 

To be attantion, the refresh frequence of my screen is set to 75Hz. When I
used VC2008 debug libs, the apps is too slow to stand.

 

I wonder why it happens? did I generate the libs in a wrong way? Thank you
for any help.

 

2008-12-19 

  _  

Leeten 

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


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Simon Hammett
2008/12/19 Pierre Bourdin (gmail) pierre.bour...@imerir.com:
 Hi,
 valgrind is very powerfull if you're on an Linux/Unix environnement, if you
 are using MSVC you can use this:

 add this bloc at the beginning of each file you want to trace (after all
 includes):
 #ifdef _WIN32
 # ifdef _MSC_VER
 # ifdef _DEBUG
 # include crtdbg.h
 # undef THIS_FILE
 static char THIS_FILE[] = __FILE__;
 # define malloc(s) _malloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
 # define calloc(s) _calloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
 # define realloc(s) _recalloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
 # define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
 # define delete delete(_NORMAL_BLOCK, __FILE__, __LINE__)
 # endif /* _DEBUG */
 # endif /* _MSC_VER */
 #endif /* _WIN32 */


Doesn't crtDbg.h do what you want?

#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW
#include crtDbg.h

-- 
The truth is out there. Usually in header files.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Chinese character problem in PagedLod

2008-12-19 Thread Robert Osfield
Hi Simba,

What OSG version and platform are you using?

Robert.

On Fri, Dec 19, 2008 at 1:38 PM, Simba forrestg...@126.com wrote:
 Hi all,
I found that if filenames in pagedlod node contain Chinese character, osg
 will not be able to load file correctly, have anyone met this before? Even
 if I use setlocale(LC_ALL,chs), it will still not do. Help...
This is one of my pagedlod node:
PagedLOD {
 nodeMask 0x
 cullingActive TRUE
 Radius 100
 RangeMode DISTANCE_FROM_EYE_POINT
 RangeList 1 {
   0 3000
 }
 NumChildrenThatCannotBeExpired 0
 FileNameList 1 {
   a-暨济春天园-01.ive
 }
 num_children 0
   }


 
 网易免费邮,全球最大的中文免费邮箱
 ___
 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] OSG2.6 libs created by VC2008 are lower than the onescreated by VC2003?

2008-12-19 Thread Serge Lages
I agree with Erik, don't make such tests in Debug mode. Lots of thing have
changed since VS2003 on the debugger, and it's normal to have really poor
performances in this mode.

On Fri, Dec 19, 2008 at 2:42 PM, Erik den Dekker e...@ch.tudelft.nl wrote:

  I think that as a general rule it is not advisable to do performance
 tests in Debug mode, you should always use Release mode for that. Also, are
 you using the default optimization flags given by cmake for both compilers?
 These should be ok.

  Erik
   --

 *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
 osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Leeten
 *Sent:* Friday, December 19, 2008 10:04
 *To:* osg-users
 *Subject:* [osg-users] OSG2.6 libs created by VC2008 are lower than the
 onescreated by VC2003?



 Hi, all



 I use OSG2.6.0 on Windows XP SP3. I generated both OSG2.6 libs under VC
 2008 and VC 2003, both under Debug mode. When I test my app's FPS, I found
 an interesting thing: when I load the same file in the same app, the FPS is
 different when using different libs. The details are shown in followed
 table.



 Geode Num in Input Model

 OSG vertion

 IDE

 Mode

 FPS

 2300

 2.6

 VC2008

 Debug

 2

 2300

 2.6

 VC2003

 Debug

 75

 2300

 2.2

 VC2003

 Debug

 75



 To be attantion, the refresh frequence of my screen is set to 75Hz. When I
 used VC2008 debug libs, the apps is too slow to stand.



 I wonder why it happens? did I generate the libs in a wrong way? Thank you
 for any help.



 2008-12-19
  --

 Leeten

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




-- 
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] ScreenSpaceAmbientOcclusion

2008-12-19 Thread yann le paih
Third step could be to implement this new paper : SSDO (Approximating
Dynamic Global Illumination in Image Space)

http://www.uni-koblenz.de/~ritschel/




On Fri, Dec 19, 2008 at 11:45 AM, Raymond de Vries ree...@xs4all.nl wrote:

 Hi Adrian,

 Thnx for the info, cool that it's already implemented in Blender :-)

 Cheers, have fun.

 Raymond


 Adrian Egli OpenSceneGraph (3D) wrote:

 Starting point of this first version is this very simple algorithm:
 http://mikepan.homeip.net/ssaowcn

 once this will perfectly work, then we can implementing a more complex
 one.

 there are many diferent papers describing how we can implementing high
 quality SSAO

 /adrian

 2008/12/18 Raymond de Vries ree...@xs4all.nl mailto:ree...@xs4all.nl


Hi Adrian,

This looks very nice! Could you give a little more background
info? Did you use the nvidia paper as starting point? E.g. I am
curious if this technique is applicable for large outdoor
environments.

Thanks a lot
Raymond



Adrian Egli OpenSceneGraph (3D) wrote:

Hi Robert,

i implement a first version of SSAO effect and i have only one
issue left in the implementation. the whole thing works nicely
with GLSL shader, mutlipass-rendering when we don't resize the
window, actually 512x512. so
what sould i do, to replace this issue. ?

Another thing is to remove the last pass GLSL shader, is there
a way to solve it under common openGL textureing?
Mutlitextureing? Or any other idea.

This version supports:

(Transparant faces: just disable for transparent faces like
window, glass the detph writing, the depth buffer will hold
only un-transparent z-values (alpha  0.9) )

toggle ssao on/off with key 'a'

have a look and i will be happy to get any ideas to improve
the stuff.
FPS is about 30.

/adrian
--
Adrian Egli

  

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

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


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

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




 --
 
 Adrian Egli
 

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



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




-- 
Yann Le Paih
Keraudrono
56150 BAUD
Portable: +33(0)610524356
lepaih.y...@gmail.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Pierre Bourdin (gmail)
Le vendredi 19 décembre 2008 à 13:43 +, Simon Hammett a écrit :

 2008/12/19 Pierre Bourdin (gmail) pierre.bour...@imerir.com:
  Hi,
  valgrind is very powerfull if you're on an Linux/Unix environnement, if you
  are using MSVC you can use this:
 
  add this bloc at the beginning of each file you want to trace (after all
  includes):
  #ifdef _WIN32
  # ifdef _MSC_VER
  # ifdef _DEBUG
  # include crtdbg.h
  # undef THIS_FILE
  static char THIS_FILE[] = __FILE__;
  # define malloc(s) _malloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
  # define calloc(s) _calloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
  # define realloc(s) _recalloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
  # define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
  # define delete delete(_NORMAL_BLOCK, __FILE__, __LINE__)
  # endif /* _DEBUG */
  # endif /* _MSC_VER */
  #endif /* _WIN32 */
 
 
 Doesn't crtDbg.h do what you want?
 
 #define _CRTDBG_MAP_ALLOC
 #define _CRTDBG_MAP_ALLOC_NEW
 #include crtDbg.h
 

Yes it does except I don't know if it allows to go back to the allocated
bloc when it finds some memory leaks...

By the way, just putting before the # include crtdbg.h

 
 #define _CRTDBG_MAP_ALLOC
 #define _CRTDBG_MAP_ALLOC_NEW
 #include crtDbg.h
 

in stead of after the # include crtdbg.h


  # define malloc(s) _malloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
  # define calloc(s) _calloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
  # define realloc(s) _recalloc_dbg(s, _NORMAL_BLOCK, __FILE__, __LINE__)
  # define new new(_NORMAL_BLOCK, __FILE__, __LINE__)
  # define delete delete(_NORMAL_BLOCK, __FILE__, __LINE__)
 

makes a link error on msvc 2008, complaining operator new is already defined...
So there's maybe something else missing ?




Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 80 18
fax: 04 68 55 03 86
email: bour...@imerir.com

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


Re: [osg-users] Chinese character problem in PagedLod

2008-12-19 Thread Simba
 
 Hi Robert,
   I'm using osg 2.4 and window xp. Thank you for your reply, (:
 Simba



在2008-12-19?21:46:09,Robert?Osfield?robert.osfi...@gmail.com?写道:
Hi?Simba,

What?OSG?version?and?platform?are?you?using?

Robert.

On?Fri,?Dec?19,?2008?at?1:38?PM,?Simba?forrestg...@126.com?wrote:
?Hi?all,
I?found?that?if?filenames?in?pagedlod?node?contain?Chinese?character,?osg
?will?not?be?able?to?load?file?correctly,?have?anyone?met?this?before??Even
?if?I?use?setlocale(LC_ALL,chs),?it?will?still?not?do.?Help...
This?is?one?of?my?pagedlod?node:
PagedLOD?{
?nodeMask?0x
?cullingActive?TRUE
?Radius?100
?RangeMode?DISTANCE_FROM_EYE_POINT
?RangeList?1?{
???0?3000
?}
?NumChildrenThatCannotBeExpired?0
?FileNameList?1?{
???a-暨济春天园-01.ive
?}
?num_children?0
???}


?
?网易免费邮,全球最大的中文免费邮箱
?___
?osg-users?mailing?list
?osg-us...@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] Please test svn/trunk in prep for OpenSceneGraph-2.7.8 dev release

2008-12-19 Thread Robert Osfield
Hi All,

I have now completed all my work in prep for the 2.7.8 and am
personally ready to tag 2.7.8, but is the code ready... we I know it
works fine for my under Kubunutu 8.10, but need some feedback from
testing on other plartforms to know if things are working elsewhere.

Since 2.7.7 I've made done a purge on warnings this has taken me a
couple of days to complete, and now all fixable warnings (under g++
4.3.2) are fixed, the ones that remain are down to 3rd party libs save
for one the wrappers (that would break code to fix).  To do the
warnings purged I've enable the OSG_USE_AGGRESSIVE_WARNINGS to ON,
rather than the default of OFF.   With other compilers we may well see
other warnings generated, this may be bogus or may be not, so it may
or may not be appropriate to fix them. Feel free to post the warnigs
for peer review.

I had to fix hundreds of warnings so have touched many files in the
OSG, an while I've have tried to be really careful about the changes,
a number weren't as simple remove a comma or semi colon, requiring
re-factoring of the code to avoid what the compiler saw as a possible
ambiguity, this re-factoring does up the chance of me inadvertently
introducing a bug.  The warnings did highlight a couple of bugs too,
so these are fixed, lets just hope that the net improvement is
positive...  but don't assume this, test the code like it may well be
buggy with new problems arising in previously solid code.

If testing looks good then I'll tag 2.7.8. If necessary I could make
2.7.8 the branch point for OpenSceneGraph-2.8, but will only go ahead
an do this if the FligthGear project need a more formal tag to base
their own release on.  I'd rather not branch OpenSeneGraph-2.8 today
though as I still some some dev work to complete, and bugs to fix that
I want to make it into 2.8.

Thanks in advance for your help with testing,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Chinese character problem in PagedLod

2008-12-19 Thread Robert Osfield
Hi Simba,

Then it's time to upgrade to 2.7.x or svn/trunk as support of wide
character sets has been added.  Have a look through the osg-users
archives from the last two month to track down the discussion on it.
I didn't implement the feature, but helped coordinate, you are best
find the posts from the author of this functionality, Michael
Platings, to see how he's enabled the support.

Robert.

2008/12/19 Simba forrestg...@126.com:

  Hi Robert,
I'm using osg 2.4 and window xp. Thank you for your reply, (:
  Simba

 在2008-12-19 21:46:09,Robert Osfield robert.osfi...@gmail.com 写道:
Hi Simba,

What OSG version and platform are you using?

Robert.

On Fri, Dec 19, 2008 at 1:38 PM, Simba forrestg...@126.com wrote:
 Hi all,
I found that if filenames in pagedlod node contain Chinese character, osg
 will not be able to load file correctly, have anyone met this before? Even
 if I use setlocale(LC_ALL,chs), it will still not do. Help...
This is one of my pagedlod node:
PagedLOD {
 nodeMask 0x
 cullingActive TRUE
 Radius 100
 RangeMode DISTANCE_FROM_EYE_POINT
 RangeList 1 {
   0 3000
 }
 NumChildrenThatCannotBeExpired 0
 FileNameList 1 {
   a-暨济春天园-01.ive
 }
 num_children 0
   }


 
 网易免费邮,全球最大的中文免费邮箱
 ___
 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] OSG2.6 libs created by VC2008 are lower than the ones created by VC2003?

2008-12-19 Thread Fabrice LALLAURET - PSV
Leeten a écrit :
 Hi, all
 I use OSG2.6.0 on Windows XP SP3. I generated both OSG2.6 libs under
 VC 2008 and VC 2003, both under Debug mode. When I test my app's FPS,
 I found an interesting thing: when I load the same file in the same
 app, the FPS is different when using different libs. The details are
 shown in followed table.

vs2005 and vs2008 too have a lot of new check in debug mode: Please see
here :

http://www.virtualdub.org/blog/pivot/entry.php?id=108


Fabrice

-- 
 .--.Fabrice LALLAURET - PSV Team
|o_o |   Tel: (33) (01 34) 22 83 47
|:_/ |   Thales Training  Simulation
   //   \ \  1, rue du General de Gaulle
  (| | ) Z.I. les beaux soleils
 /'\_   _/`\ Osny. B.P. 226
 \___)=(___/ 95523 Cergy-Pontoise Cedex
 E-mail: fabrice.lallau...@external.thalesgroup.com
 Power corrupts. PowerPoint corrupts absolutely.
 My personnal (french) Websites: http://www.xbee.net
 and http://www.french-comics-zone.fr.st


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


Re: [osg-users] osgPPU and change in colors

2008-12-19 Thread Art Tevs
Hi,

I would suppose, that your lighting cnditions are different. It could be that 
in one case the scene is lit by some lights and in another case there is no 
lighting (no lights in use). Check it out.

Cheers


--- guher b gb...@yahoo.com schrieb am Fr, 19.12.2008:

 Von: guher b gb...@yahoo.com
 Betreff: [osg-users] osgPPU and change in colors
 An: osg-users@lists.openscenegraph.org
 Datum: Freitag, 19. Dezember 2008, 15:17
 Hi, 
 I used osgPPU nodekit and I only used 
 UnitByPass and UnitOut to only render the scene graph to
 fbo  and then finally to framebuffer. In the result, my
 skybox color has changed color (become darker)
 Has anybody else encountered this behaviour before?  May
 writing the fbo to a texture with viewport dimensions 
 (resolution change) cause this behaviour? 
 
 
 
 Thanks in advance
 
 
   ___
 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] ScreenSpaceAmbientOcclusion (SSAO) with osgPPU

2008-12-19 Thread Art Tevs
Hi folks,

I have implemented a very simple (yeah it is just a real big faken) SSAO 
example with osgPPU. The example is build in the same way as Adrian's osgFX 
effect and is described here: http://mikepan.homeip.net/ssaowcn
The current one computes the AO-term in multisampling way (hence in higher 
resolution then the screen resolution is). hence less artifacts are visible.

The current speed is 200FPS, however this value isn't really correct. The  
computation is indeed very simple and require only few operations. So I suppose 
I could be able to find the bug making it so slow (I am sure there is one, 
because the DepthOfField-example runs much faster but need more operations). 

As Adrian said. the next step is to implement more complex and realistic 
algorithms than this one.

Just check out osgPPU from the svn and try the given example out (don't forget 
to setup OSG_FILE_PATH to the trunk/ directory ;) 

Best regards,
Art



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


Re: [osg-users] Callback when loading nodes in the database pager

2008-12-19 Thread Maciej Krol
Hi Ralf, Christophe

We use ReadFileCallback to modify requested nodes from database pager. It
works fine, but make sure Your code is thread safe.

Regards,
Maciej

2008/12/18 christophe loustaunau christophe.loustau...@gmail.com

 Hi Ralf,

 look at ReadFileCallback in the example osgCallBack, it may be what you
 wan't.

 Regards.

 On Thu, Dec 18, 2008 at 2:20 PM, Ralf Stokholm alfma...@arenalogic.comwrote:

 Hi List

 Is it possible to attach a callback to handle/modify loaded nodes in the
 database thread?

 Background:

 We are using VPB generatet terrain database in a delta3d application, to
 get the terrain mesh into our simulation we are using a cull visitor which
 takes care of loading loading and removing collision meshes from the physics
 engine when the accociatet node is generatet and removed.

 Even though this approach works well, it is rather slow and it annoys me
 that I have to dublikate bookkeeping which must already be implementet in
 the databasepager. I would also like to put the work in the database thread
 when possible.

 Is there any callbacks or similar for plugging in this code at the moment?

 Brgs.

 Ralf Stokholm.
 www.arenalogic.com

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




 --
 Christophe Loustaunau.

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




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


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Paul Melis

Hey guys,

Stephan Huber wrote:

However, running IBM Purify on the application reveals no massive leaks,
only a few false positives. Are there any tools or techniques that
someone could recommend to make finding and fixing memory leaks easy,
and which work well with OSG? I tried Visual Leak Detector which is open
source, but it reported so many false positives related to variables
stored in ref_ptrs (over 400) that I gave up on it.



For that type of debugging I am using a custom singleton-class called
AllocationObserver which observes the refcount for osg::Referenced. You
  
That gave me an idea. You can't determine the actual type being 
constructed in either the Referenced constructor or destructor, but you 
can set a delete handler on Referenced that extracts this info before 
the destructor is called. See attached small diff to 
src/osg/Referenced.cpp (against the 2.6 branch, includes end-of-line 
whitespace trimming as my editor is set up like that and I'm too lazy to 
turn it off). This forces a line of output to be written to stdout every 
time a Referenced instance is allocated or deallocated, together with 
the instance's address. By using the deallocations you can figure out 
the allocations (which don't have type info), which is what the alloc.py 
script does. It filters the original output of a program run and 
replaces the unknown allocated instance types with the actual ones 
gotten from deallocations.


This gives quite nice statistics on the number of objects created, but 
unfortunately there seems to be a group of objects that is never 
deallocated. Their type can therefore not be determined. See below for 
example (processed by alloc.py) output when running osgviewer on the 
cow, and doing some viewpoint interaction and stuff.


What I don't understand is why osg::Matrix ends up in the list (at a 
count of a few thousand in this case), as that isn't a Referenced subclass.


In J-S's original simple test case I get around 250 Referenced instances 
that are never deallocated when stopping at breakpoint 2, but sadly 
can't tell where they come from. Perhaps moving class/libraryName() up 
into Referenced might help here?


Regards,
Paul

P.S. Stephan, you say AllocationObserver which observes the refcount 
for osg::Referenced, but it only observes the refcount going to 0 
right? I don't seen any other 'events' for observers.



SUMMARY
osg::AlphaFunc   3 
A  3 D  (0)
osg::AnimationPath   2 
A  2 D  (0)
osg::AnimationPathCallback   1 
A  1 D  (0)
osg::AutoTransform   1 
A  1 D  (0)
osg::Billboard   1 
A  1 D  (0)
osg::BlendColor  1 
A  1 D  (0)
osg::BlendEquation   1 
A  1 D  (0)
osg::BlendFunc  12 A 
12 D  (0)
osg::Box 1 
A  1 D  (0)
osg::Camera 13 A 
13 D  (0)
osg::CameraView  1 
A  1 D  (0)
osg::Capsule 1 
A  1 D  (0)
osg::ClearNode   2 
A  2 D  (0)
osg::ClipNode1 
A  1 D  (0)
osg::ClipPlane   1 
A  1 D  (0)
osg::ClusterCullingCallback  1 
A  1 D  (0)
osg::ColorMask   5 
A  5 D  (0)
osg::ColorMatrix 1 
A  1 D  (0)
osg::CompositeShape  1 
A  1 D  (0)
osg::Cone1 
A  1 D  (0)
osg::ConvexPlanarOccluder1 
A  1 D  (0)
osg::CoordinateSystemNode1 
A  1 D  (0)
osg::CullFace1 
A  1 D  (0)
osg::Cylinder1 
A  1 D  (0)
osg::Depth   2 
A  2 D  (0)
osg::DrawArrayLengths1 
A  1 D  (0)
osg::DrawArrays  7 
A  7 D  (0)
osg::DrawCallback   13 A 
13 D  (0)
osg::DrawElementsUShort  2 
A  2 D  (0)
osg::EllipsoidModel  1 
A  1 D  (0)
osg::FloatArray 14 A 
14 D 

Re: [osg-users] Memory management in OSG

2008-12-19 Thread Jean-Sébastien Guay

Hello Pierre,

valgrind is very powerfull if you're on an Linux/Unix environnement, if 
you are using MSVC you can use this:


...

when you stop debugging you program, it make a memory leaks report in 
the msvc output console...


Does this work well with ref_ptrs? i.e. will it spit out hundreds of 
false positives for things that are ref counted and do not actually leak?


What I'd really like is to compare the state of memory (preferably with 
where the memory was allocated) at two points of the program's run. If I 
can just get a dump of that, and then diff the two, I could see what 
leaks between when the first file is opened and when the second one is.


The project we're working on currently does not run on Linux though it 
will eventually, so valgrind is not an alternative right now.


Thanks,

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


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Paul Melis

Paul Melis wrote:

Hey guys,

Stephan Huber wrote:
However, running IBM Purify on the application reveals no massive 
leaks,

only a few false positives. Are there any tools or techniques that
someone could recommend to make finding and fixing memory leaks easy,
and which work well with OSG? I tried Visual Leak Detector which is 
open

source, but it reported so many false positives related to variables
stored in ref_ptrs (over 400) that I gave up on it.



For that type of debugging I am using a custom singleton-class called
AllocationObserver which observes the refcount for osg::Referenced. You
  
That gave me an idea. You can't determine the actual type being 
constructed in either the Referenced constructor or destructor, but 
you can set a delete handler on Referenced that extracts this info 
before the destructor is called. See attached small diff to 
src/osg/Referenced.cpp (against the 2.6 branch, includes end-of-line 
whitespace trimming as my editor is set up like that and I'm too lazy 
to turn it off). This forces a line of output to be written to stdout 
every time a Referenced instance is allocated or deallocated, together 
with the instance's address. By using the deallocations you can figure 
out the allocations (which don't have type info), which is what the 
alloc.py script does. It filters the original output of a program run 
and replaces the unknown allocated instance types with the actual ones 
gotten from deallocations.


This gives quite nice statistics on the number of objects created, but 
unfortunately there seems to be a group of objects that is never 
deallocated. Their type can therefore not be determined. See below for 
example (processed by alloc.py) output when running osgviewer on the 
cow, and doing some viewpoint interaction and stuff.


What I don't understand is why osg::Matrix ends up in the list (at a 
count of a few thousand in this case), as that isn't a Referenced 
subclass.

Just figured it out that these must be RefMatrix's...

Paul


In J-S's original simple test case I get around 250 Referenced 
instances that are never deallocated when stopping at breakpoint 2, 
but sadly can't tell where they come from. Perhaps moving 
class/libraryName() up into Referenced might help here?


Regards,
Paul

P.S. Stephan, you say AllocationObserver which observes the refcount 
for osg::Referenced, but it only observes the refcount going to 0 
right? I don't seen any other 'events' for observers.



SUMMARY
osg::AlphaFunc   3 
A  3 D  (0)
osg::AnimationPath   2 
A  2 D  (0)
osg::AnimationPathCallback   1 
A  1 D  (0)
osg::AutoTransform   1 
A  1 D  (0)
osg::Billboard   1 
A  1 D  (0)
osg::BlendColor  1 
A  1 D  (0)
osg::BlendEquation   1 
A  1 D  (0)
osg::BlendFunc  12 
A 12 D  (0)
osg::Box 1 
A  1 D  (0)
osg::Camera 13 
A 13 D  (0)
osg::CameraView  1 
A  1 D  (0)
osg::Capsule 1 
A  1 D  (0)
osg::ClearNode   2 
A  2 D  (0)
osg::ClipNode1 
A  1 D  (0)
osg::ClipPlane   1 
A  1 D  (0)
osg::ClusterCullingCallback  1 
A  1 D  (0)
osg::ColorMask   5 
A  5 D  (0)
osg::ColorMatrix 1 
A  1 D  (0)
osg::CompositeShape  1 
A  1 D  (0)
osg::Cone1 
A  1 D  (0)
osg::ConvexPlanarOccluder1 
A  1 D  (0)
osg::CoordinateSystemNode1 
A  1 D  (0)
osg::CullFace1 
A  1 D  (0)
osg::Cylinder1 
A  1 D  (0)
osg::Depth   2 
A  2 D  (0)
osg::DrawArrayLengths1 
A  1 D  (0)
osg::DrawArrays  7 
A  7 D  (0)
osg::DrawCallback   13 
A 13 D  (0)
osg::DrawElementsUShort  2 
A  2 D  (0)
osg::EllipsoidModel  1 
A  1 D 

Re: [osg-users] osgPPU and change in colors

2008-12-19 Thread J.P. Delport

Hi,

also check if the geom you are applying the final texture to has a white 
colour, or set the texture mode to GL_REPLACE.


jp

Art Tevs wrote:

Hi,

I would suppose, that your lighting cnditions are different. It could be that 
in one case the scene is lit by some lights and in another case there is no 
lighting (no lights in use). Check it out.

Cheers


--- guher b gb...@yahoo.com schrieb am Fr, 19.12.2008:


Von: guher b gb...@yahoo.com
Betreff: [osg-users] osgPPU and change in colors
An: osg-users@lists.openscenegraph.org
Datum: Freitag, 19. Dezember 2008, 15:17
Hi, 
I used osgPPU nodekit and I only used 
UnitByPass and UnitOut to only render the scene graph to

fbo  and then finally to framebuffer. In the result, my
skybox color has changed color (become darker)
Has anybody else encountered this behaviour before?  May
writing the fbo to a texture with viewport dimensions 
(resolution change) cause this behaviour? 




Thanks in advance


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



  
___

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


--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


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


Re: [osg-users] Strange error on 2.7.7 VC8.1 INSTALL(Release) target

2008-12-19 Thread Roger James




Hi Matt,

Mattias Helsing wrote:

  Hi Roger,

On 12/19/08, Roger James ro...@beardandsandals.co.uk wrote:
  
  
I just did a build on a clean 2.7.7 source tree using Visual Studio 8.1.
When I came to do the Release INSTALL target I got a failure whilst it was
copying header files into the "\Program Files\OpensceneGraph\Include"
directory. The error message was not very informative, it just said "failed
to copy". I looked into the directory and all the files up to the one the
failed had a new date stamp. On a whim I reran the INSTALL target and this
time it got past the file it had failed on and failed on another header file
further on. I reran it a couple more times and it got further each time
eventually completing without error. It looks like there may be an error in
the Cmake file install scripts when they have to copy a large a number of
files. The reason it appeared to get further each time appeared to be
because the header files it had already copied now showed as "up to date"
rather than "Installing". If anyone else sees this don't worry just rerun
the INSTALL. I leave this to anyone who understands CMake to fix!


  
  
I'm not sure it needs fixing. I just ran an install of my entire build
tree including the reference docs (1 files). I'm on winxp with
msvc8 sp1 with osg-2.7.8. No problems reported (except that with an
encrypted ntfs drive it takes a bit of time :)

What you are seeing could have many causes. Could be that you are
installing to a network drive, antivirus software, hard drive
failures, ...

cheers
Mattias

  

Agreed, I am not going to worry about it :-) I have to run in
adninistrator mode in Vista to do the INSTALL so who knows what arcane
paths are being invoked!

Roger


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


Re: [osg-users] High resolution screencast

2008-12-19 Thread Jean-Sébastien Guay

Hello Simon,

Second, I tried some times ago to do an offscreen rendering but If you 
know an easy way in osg to do it I'm interested (I think there are ways 
based on osg::Camera::DrawCallBack).


There is now (since OSG 2.6) an osgViewer::ScreenCaptureHandler which 
you can use. Unfortunately it only responds to key presses right now, 
but you can subclass it like this to get it to capture programmatically:


class OurScreenCaptureHandler :
public osgViewer::ScreenCaptureHandler
{
public:
OurScreenCaptureHandler(CaptureOperation* defaultOperation = 0)
   : osgViewer::ScreenCaptureHandler(defaultOperation)
{
}

/** Capture the given viewer's views on the next frame. */
virtual void captureNextFrame(osgViewer::ViewerBase viewer)
{
addCallbackToViewer(viewer);
}
};

Then in your frame loop, you can just call

screenCaptureHandler-captureNextFrame(viewer);

(note: I'll be sending a new version of ScreenCaptureHandler which 
includes this method soon, I had to do it for our framework recently, so 
it will probably be included in OSG after that, no need to subclass)


Eventually, do you know some good (easy to handle) API for compressing 
video?


Once you have images of each frame, you can just use ffmpeg to compress 
the sequence into a video. See the ffmpeg man page or web page for more 
information.


Hope this helps,

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


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Jean-Sébastien Guay

Hi Stephan,


If you are interested in the code (it's integrated with other code, but
the principle should be clear) drop me a line.


Yes, I am very interested. You mentioned circular references, and this 
is my current area of focus - does your code help finding these? For 
example, a node callback that would have a ref_ptr to a node somewhere 
above it in the graph, causing that subgraph never to be deleted?


Thanks in advance,

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


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

2008-12-19 Thread Vincent Bourdier
Hi Robert,

Compilation ok : 0 error, 0 warnings on OSG only (no examples, no wrappers,
...)
Under : VS 2005 SP1, Windows XP SP2

Regards,
   Vincent.

2008/12/19 Robert Osfield robert.osfi...@gmail.com

 Hi All,

 I have now completed all my work in prep for the 2.7.8 and am
 personally ready to tag 2.7.8, but is the code ready... we I know it
 works fine for my under Kubunutu 8.10, but need some feedback from
 testing on other plartforms to know if things are working elsewhere.

 Since 2.7.7 I've made done a purge on warnings this has taken me a
 couple of days to complete, and now all fixable warnings (under g++
 4.3.2) are fixed, the ones that remain are down to 3rd party libs save
 for one the wrappers (that would break code to fix).  To do the
 warnings purged I've enable the OSG_USE_AGGRESSIVE_WARNINGS to ON,
 rather than the default of OFF.   With other compilers we may well see
 other warnings generated, this may be bogus or may be not, so it may
 or may not be appropriate to fix them. Feel free to post the warnigs
 for peer review.

 I had to fix hundreds of warnings so have touched many files in the
 OSG, an while I've have tried to be really careful about the changes,
 a number weren't as simple remove a comma or semi colon, requiring
 re-factoring of the code to avoid what the compiler saw as a possible
 ambiguity, this re-factoring does up the chance of me inadvertently
 introducing a bug.  The warnings did highlight a couple of bugs too,
 so these are fixed, lets just hope that the net improvement is
 positive...  but don't assume this, test the code like it may well be
 buggy with new problems arising in previously solid code.

 If testing looks good then I'll tag 2.7.8. If necessary I could make
 2.7.8 the branch point for OpenSceneGraph-2.8, but will only go ahead
 an do this if the FligthGear project need a more formal tag to base
 their own release on.  I'd rather not branch OpenSeneGraph-2.8 today
 though as I still some some dev work to complete, and bugs to fix that
 I want to make it into 2.8.

 Thanks in advance for your help with testing,
 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] another VPB question...

2008-12-19 Thread Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Thanks Robert. I'll give the GDAL folks a shout to see what they have to
say...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Friday, December 19, 2008 2:27 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] another VPB question...

HI Shayne,

This isn't a error message that I've written so it must be some that
GDAL is emitting.  As to why I cannot say.  Perhaps the GDAL community
might be familiar with it.

Robert.

On Thu, Dec 18, 2008 at 9:58 PM, Tueller,  Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:
 All,



 Occasionally I get the following warning when I'm building a database
using
 VPB:



 Warning 1: PackBitsDecode:Discarding 52 bytes to avoid buffer overrun



 Does anyone know what this pertains to or why it is happening?



 Thanks,

 -Shayne

 ___
 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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] vpb - strange tile corner artifacts

2008-12-19 Thread Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Guys,

Is this fix able to be rolled into older versions of VPB? I'm using 0.9.7...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
Delport
Sent: Friday, December 19, 2008 2:35 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] vpb - strange tile corner artifacts

Hi,

good, I've also tested the fix with vpb HEAD and it seems OK. Busy 
testing on a larger database and if it works I'll submit the fix.

jp

christophe loustaunau wrote:
 Hi,
 
 I have no bug with r932 and your file.
 It seems to be good !
 
 On Fri, Dec 19, 2008 at 10:05 AM, J.P. Delport jpdelp...@csir.co.za 
 mailto:jpdelp...@csir.co.za wrote:
 
 Hi,
 
 
 christophe loustaunau wrote:
 
  You're near the bug ! :-)
 
 Looking at the log, i see that in destination.cpp ,the function  :
 void DestinationTile::equalizeCorner(Position position)
 
 have been change. It may be here.
 
 
 Yes, this was my first place to look too.
 
 I think I found the error, getImageSet(layerNum) was called on the
 wrong DestinationTile.
 
 Could you try this file with r932 and see if you get OK results, I
 want to double check before I see if the fix works with vpb HEAD.
 
 jp
 
 
 -- 
 This message is subject to the CSIR's copyright terms and
 conditions, e-mail legal notice, and implemented Open Document
 Format (ODF) standard. The full disclaimer details can be found at
 http://www.csir.co.za/disclaimer.html.
 
 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.  MailScanner thanks
 Transtec Computers for their support.
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 mailto:osg-users@lists.openscenegraph.org

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

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by
MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for
their support.

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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Callback when loading nodes in the database pager

2008-12-19 Thread Ralf Stokholm
Hi Both

Thanks for the hints, ReadFileCallback defenatly seams like it would solve
most of my problem.

How do I determine if the file loaded was part of my terrain or another
specifik pagedLod dataset, and as such should be handled in the
filecallback?

Brgs.

Ralf Stokholm

2008/12/19 Maciej Krol mack...@gmail.com

 Hi Ralf, Christophe

 We use ReadFileCallback to modify requested nodes from database pager. It
 works fine, but make sure Your code is thread safe.

 Regards,
 Maciej

 2008/12/18 christophe loustaunau christophe.loustau...@gmail.com

 Hi Ralf,

 look at ReadFileCallback in the example osgCallBack, it may be what you
 wan't.

 Regards.

   On Thu, Dec 18, 2008 at 2:20 PM, Ralf Stokholm alfma...@arenalogic.com
  wrote:

   Hi List

 Is it possible to attach a callback to handle/modify loaded nodes in the
 database thread?

 Background:

 We are using VPB generatet terrain database in a delta3d application, to
 get the terrain mesh into our simulation we are using a cull visitor which
 takes care of loading loading and removing collision meshes from the physics
 engine when the accociatet node is generatet and removed.

 Even though this approach works well, it is rather slow and it annoys me
 that I have to dublikate bookkeeping which must already be implementet in
 the databasepager. I would also like to put the work in the database thread
 when possible.

 Is there any callbacks or similar for plugging in this code at the
 moment?

 Brgs.

 Ralf Stokholm.
 www.arenalogic.com

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




 --
 Christophe Loustaunau.

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




 --
 Regards,
 Maciej Krol

 ___
 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] Build error on MAc OSX 10.4 and OSG 2.7.4

2008-12-19 Thread Paul Fotheringham
Hi Robert,

If I set MATH_LIBRARY to  then it builds fine (with nothing on any on the 
link lines).

Also, if I set it to /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib it also 
works fine (with /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib on each 
link line).

I must admit I'm puzzled as to why the string associated with MATH_LIBRARY is 
appearing on the link lines for all the libraries and not just libosg itself as 
none of the CMakeLists.txt files other than the one in the osg folder refer to 
it. Are the other libraries somehow inheriting this setting from the cmake 
settings in libosg?

Paul

--- On Fri, 19/12/08, Robert Osfield robert.osfi...@gmail.com wrote:

 From: Robert Osfield robert.osfi...@gmail.com
 Subject: Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Date: Friday, 19 December, 2008, 11:15 AM
 Hi Paul,
 
 What happens if, using ccamke, you manually set the
 MATH_LIBRARY to 
 or to your frameworks version?
 
 Robert.
 
 On Fri, Dec 19, 2008 at 11:06 AM, Paul Fotheringham
 osg_u...@yahoo.co.uk wrote:
  --- On Fri, 19/12/08, Robert Osfield
 robert.osfi...@gmail.com wrote:
 
  From: Robert Osfield
 robert.osfi...@gmail.com
  Subject: Re: [osg-users] Build error on MAc OSX
 10.4 and OSG 2.7.4
  To: osg_u...@yahoo.co.uk, OpenSceneGraph
 Users osg-users@lists.openscenegraph.org
  Date: Friday, 19 December, 2008, 8:46 AM
  Hi Paul,
 
  On Thu, Dec 18, 2008 at 6:37 PM, Paul Fotheringham
  osg_u...@yahoo.co.uk wrote:
   Hi Robert,
  
   Thanks for looking into this.
  
   --- On Thu, 18/12/08, Robert Osfield
  robert.osfi...@gmail.com wrote:
   snip
   The core OSG library does link against
 the
  MATH_LIBRARY,
   but the other
   non of the other core libraries do.
  
   Apparently not on MacOSX using cmake :)
 
  Please read what I've already written. 
 I've been
  using Cmake under
  OSX as others have been as well, without problems.
 
  I've already explained not once, but twice now,
 why that is.
 
   Take a look at
  
   src/osgText/CMakeFiles/osgText.dir/link.txt
  
   without the change you just made. In fact
 take a look
  at any of the link.txt files for each OSG library.
 Thay all
  have /usr/lib/libm.dylib in there.
  
   I've added a entry of
   MATH_LIBRARY into the linking of osgText.
  Could
  you do an
   svn update
   and see if the error is fixed?
  
   I got the svn version and no it doesn't
 fix it.
  All it does is move the
  
   /usr/lib/libm.dylib
  
   reference on the link line to a different
 place!
  
   The fact you've got errors but others
 under
  OSX
   haven't reported this
   (including myself) suggests that must be
 something
  else
   going w.r.t
   gcc/SDK's you are using on your
 machine.
  
   I'm sorry I haven't explained this
 well
  enough. The goal here is to *not* have any
 explicit
  reference to libm.dylib on the link line.
  
   The symbols reside in the SDK version of the
 library
  at
  
  
 /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib
  
   and *not* necessarily at
  
   /usr/lib/libm.dylib
  
   which is what the MATH_LIBRARY is set to.
 This is fine
  for UNIX but not Mac as it should be the former
 that is used
  for a consistent build (if there are Mac
 developers out
  there who disagree please correct me - I'm new
 to this).
  
   By omitting the explicit reference to
 libm.dylib the
  Mac build system takes care of this automatically
 and gets
  the symbols from the SDK version of the library.
  
   Users who are not seeing this problem have
 all the
  symbols they require in /usr/lib/libm.dylib and
 are, as I
  understand it, lucky ;)
 
  I'll will check what value is used on the OSX
 box that
  I was remote
  compiling on.
 
  Could you please remove the MATH_LIBRARY entry in
 the
  src/osg/CMakeLists.txt and
 src/osgText/CMakeLists.txt to
  test your
  theory about not needing it.
 
  I agree that only libosg needs it. osgText only needs
 it indirectly. If I remove the MATH_LIBRARY entry from
 src/osgText/CMakeLists.txt then /usr/lib/libm.dylib still
 apears in the link line. To be more precise, it appears in
 src/osgText/CMakeFiles/osgDB.dir/link.txt which, with my
 limited knowledge of cmake, is what I assume it uses to
 perform the link.
 
  As I implied in my first post, all these references to
 /usr/lib/libm.dylib on the link lines seem to come from the
 FIND_LIBRARY(MATH_LIBRARY m) line in the top-level
 CMakeLists.txt as they all go away if I remove that.
 
 
  Robert.
 
  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

Re: [osg-users] Memory management in OSG

2008-12-19 Thread Jean-Sébastien Guay

Hi Paul,

Good sleuthing, I'll try your code out and see if I can improve on it a 
bit too...


In J-S's original simple test case I get around 250 Referenced instances 
that are never deallocated when stopping at breakpoint 2, but sadly 
can't tell where they come from. Perhaps moving class/libraryName() up 
into Referenced might help here?


I think those objects could be inspected by creating an atexit() 
handler, since they actually *are* deallocated at the end of the program 
(put a breakpoint in the Referenced destructor after breakpoint 2 and 
you'll see). I imagine they must be static objects or something, but 
~250 seems like a lot to me. So getting info about what they are would 
be instructional if not that useful :-)


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


Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4

2008-12-19 Thread Robert Osfield
Hi Paul,

When I was removing the MATH_LIBRARY entry from the
src/osgText/CMakeLists.txt  (the one that I had added to see it would
help you) I noticed that FreeType was listed but this isn't needed by
osgText, just by the freetype plugin so I have removed this as it's
not needed and potentially could extra complications that it needn't
have.  Could you try svn/trunk to see if it makes any difference.
I've attached the cleaned up osgText/CMakeLists.txt in case you just
want to try this on its own.

Robert.


On Fri, Dec 19, 2008 at 3:53 PM, Paul Fotheringham osg_u...@yahoo.co.uk wrote:
 Hi Robert,

 If I set MATH_LIBRARY to  then it builds fine (with nothing on any on the 
 link lines).

 Also, if I set it to /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib it 
 also works fine (with /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib on 
 each link line).

 I must admit I'm puzzled as to why the string associated with MATH_LIBRARY is 
 appearing on the link lines for all the libraries and not just libosg itself 
 as none of the CMakeLists.txt files other than the one in the osg folder 
 refer to it. Are the other libraries somehow inheriting this setting from the 
 cmake settings in libosg?

 Paul

 --- On Fri, 19/12/08, Robert Osfield robert.osfi...@gmail.com wrote:

 From: Robert Osfield robert.osfi...@gmail.com
 Subject: Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Date: Friday, 19 December, 2008, 11:15 AM
 Hi Paul,

 What happens if, using ccamke, you manually set the
 MATH_LIBRARY to 
 or to your frameworks version?

 Robert.

 On Fri, Dec 19, 2008 at 11:06 AM, Paul Fotheringham
 osg_u...@yahoo.co.uk wrote:
  --- On Fri, 19/12/08, Robert Osfield
 robert.osfi...@gmail.com wrote:
 
  From: Robert Osfield
 robert.osfi...@gmail.com
  Subject: Re: [osg-users] Build error on MAc OSX
 10.4 and OSG 2.7.4
  To: osg_u...@yahoo.co.uk, OpenSceneGraph
 Users osg-users@lists.openscenegraph.org
  Date: Friday, 19 December, 2008, 8:46 AM
  Hi Paul,
 
  On Thu, Dec 18, 2008 at 6:37 PM, Paul Fotheringham
  osg_u...@yahoo.co.uk wrote:
   Hi Robert,
  
   Thanks for looking into this.
  
   --- On Thu, 18/12/08, Robert Osfield
  robert.osfi...@gmail.com wrote:
   snip
   The core OSG library does link against
 the
  MATH_LIBRARY,
   but the other
   non of the other core libraries do.
  
   Apparently not on MacOSX using cmake :)
 
  Please read what I've already written.
 I've been
  using Cmake under
  OSX as others have been as well, without problems.
 
  I've already explained not once, but twice now,
 why that is.
 
   Take a look at
  
   src/osgText/CMakeFiles/osgText.dir/link.txt
  
   without the change you just made. In fact
 take a look
  at any of the link.txt files for each OSG library.
 Thay all
  have /usr/lib/libm.dylib in there.
  
   I've added a entry of
   MATH_LIBRARY into the linking of osgText.
  Could
  you do an
   svn update
   and see if the error is fixed?
  
   I got the svn version and no it doesn't
 fix it.
  All it does is move the
  
   /usr/lib/libm.dylib
  
   reference on the link line to a different
 place!
  
   The fact you've got errors but others
 under
  OSX
   haven't reported this
   (including myself) suggests that must be
 something
  else
   going w.r.t
   gcc/SDK's you are using on your
 machine.
  
   I'm sorry I haven't explained this
 well
  enough. The goal here is to *not* have any
 explicit
  reference to libm.dylib on the link line.
  
   The symbols reside in the SDK version of the
 library
  at
  
  
 /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib
  
   and *not* necessarily at
  
   /usr/lib/libm.dylib
  
   which is what the MATH_LIBRARY is set to.
 This is fine
  for UNIX but not Mac as it should be the former
 that is used
  for a consistent build (if there are Mac
 developers out
  there who disagree please correct me - I'm new
 to this).
  
   By omitting the explicit reference to
 libm.dylib the
  Mac build system takes care of this automatically
 and gets
  the symbols from the SDK version of the library.
  
   Users who are not seeing this problem have
 all the
  symbols they require in /usr/lib/libm.dylib and
 are, as I
  understand it, lucky ;)
 
  I'll will check what value is used on the OSX
 box that
  I was remote
  compiling on.
 
  Could you please remove the MATH_LIBRARY entry in
 the
  src/osg/CMakeLists.txt and
 src/osgText/CMakeLists.txt to
  test your
  theory about not needing it.
 
  I agree that only libosg needs it. osgText only needs
 it indirectly. If I remove the MATH_LIBRARY entry from
 src/osgText/CMakeLists.txt then /usr/lib/libm.dylib still
 apears in the link line. To be more precise, it appears in
 src/osgText/CMakeFiles/osgDB.dir/link.txt which, with my
 limited knowledge of cmake, is what I assume it uses to
 perform the link.
 
  As I implied in my first post, all these references to
 /usr/lib/libm.dylib on the link lines seem to come from the
 

Re: [osg-users] vpb - strange tile corner artifacts

2008-12-19 Thread Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Ok I misunderstood. I thought you were referring to earlier versions of VPB
that manifested the artifact. 0.9.7 seems just fine.

Thanks,
-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
Delport
Sent: Friday, December 19, 2008 8:56 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] vpb - strange tile corner artifacts

Hi Shayne,

no, the fix is for a problem that was introduced after 0.9.7.

The problem came with r932 and from the vpb trac site 0.9.7 was r904.

Do you have problems with 0.9.7?

regards
jp

Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:
 Guys,
 
 Is this fix able to be rolled into older versions of VPB? I'm using
0.9.7...
 
 -Shayne
 
 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
 Delport
 Sent: Friday, December 19, 2008 2:35 AM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] vpb - strange tile corner artifacts
 
 Hi,
 
 good, I've also tested the fix with vpb HEAD and it seems OK. Busy 
 testing on a larger database and if it works I'll submit the fix.
 
 jp
 
 christophe loustaunau wrote:
 Hi,

 I have no bug with r932 and your file.
 It seems to be good !

 On Fri, Dec 19, 2008 at 10:05 AM, J.P. Delport jpdelp...@csir.co.za 
 mailto:jpdelp...@csir.co.za wrote:

 Hi,


 christophe loustaunau wrote:

  You're near the bug ! :-)

 Looking at the log, i see that in destination.cpp ,the function
:
 void DestinationTile::equalizeCorner(Position position)

 have been change. It may be here.


 Yes, this was my first place to look too.

 I think I found the error, getImageSet(layerNum) was called on the
 wrong DestinationTile.

 Could you try this file with r932 and see if you get OK results, I
 want to double check before I see if the fix works with vpb HEAD.

 jp


 -- 
 This message is subject to the CSIR's copyright terms and
 conditions, e-mail legal notice, and implemented Open Document
 Format (ODF) standard. The full disclaimer details can be found at
 http://www.csir.co.za/disclaimer.html.

 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.  MailScanner thanks
 Transtec Computers for their support.


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

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



 -- 
 Christophe Loustaunau.


 

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

-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail
legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by
MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for
their support.

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


smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2008-12-19 Thread Gerrick Bivins
Hi Robert,
Mac OSX 10.5.6, cmake (makefiles) build
 
I ran into this error when compiling plugins:
[ 68%] Building CXX object
src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o
/Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInv
entor.cpp: In function Œvoid postProcessField(const SbIntList,
osg::PrimitiveSet::Mode, SoMFInt32*, osg::Geometry::AttributeBinding)¹:
/Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInv
entor.cpp:653: error: Œdst2¹ was not declared in this scope
make[2]: *** 
[src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o]
Error 1
make[1]: *** [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/all] Error 2
make: *** [all] Error 2

Looks like this line needs to either not reference dst2 or be removed.
assert(dst2+newNum == dst  Something wrong in the loop.);

I didn¹t dig into what the intent for the check was but maybe someone knows
if that can be gotten rid of or not.

 Gerrick



On 12/19/08 9:42 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote:

 Hi Robert,
 
 Compilation ok : 0 error, 0 warnings on OSG only (no examples, no wrappers,
 ...)
 Under : VS 2005 SP1, Windows XP SP2
 
 Regards,
Vincent.
 
 2008/12/19 Robert Osfield robert.osfi...@gmail.com
 Hi All,
 
 I have now completed all my work in prep for the 2.7.8 and am
 personally ready to tag 2.7.8, but is the code ready... we I know it
 works fine for my under Kubunutu 8.10, but need some feedback from
 testing on other plartforms to know if things are working elsewhere.
 
 Since 2.7.7 I've made done a purge on warnings this has taken me a
 couple of days to complete, and now all fixable warnings (under g++
 4.3.2) are fixed, the ones that remain are down to 3rd party libs save
 for one the wrappers (that would break code to fix).  To do the
 warnings purged I've enable the OSG_USE_AGGRESSIVE_WARNINGS to ON,
 rather than the default of OFF.   With other compilers we may well see
 other warnings generated, this may be bogus or may be not, so it may
 or may not be appropriate to fix them. Feel free to post the warnigs
 for peer review.
 
 I had to fix hundreds of warnings so have touched many files in the
 OSG, an while I've have tried to be really careful about the changes,
 a number weren't as simple remove a comma or semi colon, requiring
 re-factoring of the code to avoid what the compiler saw as a possible
 ambiguity, this re-factoring does up the chance of me inadvertently
 introducing a bug.  The warnings did highlight a couple of bugs too,
 so these are fixed, lets just hope that the net improvement is
 positive...  but don't assume this, test the code like it may well be
 buggy with new problems arising in previously solid code.
 
 If testing looks good then I'll tag 2.7.8. If necessary I could make
 2.7.8 the branch point for OpenSceneGraph-2.8, but will only go ahead
 an do this if the FligthGear project need a more formal tag to base
 their own release on.  I'd rather not branch OpenSeneGraph-2.8 today
 though as I still some some dev work to complete, and bugs to fix that
 I want to make it into 2.8.
 
 Thanks in advance for your help with testing,
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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


Re: [osg-users] Precipitation effect coming too fast, and hiding on some areas

2008-12-19 Thread Robert Osfield
Hi Fred and Jefferson,

On Thu, Dec 18, 2008 at 8:39 AM,  fredlis...@free.fr wrote:
 Unfortunately, it doesn't seem to work ( at least for me ). I modified the 
 osgprecipitation example to add a simple clip plane, and although the model 
 is clipped, the rain continues to appear in the half space clipped.

 Attached the modified example.

I tested the modified example and it didn't function for a number of reasons..

First up the clipping plane has to be placed in eye coordinates and
osg::ClipNode didn't provide an option for placing it in an absolute
reference frame (an absolute/identity view matrix puts you in eye
coords) so I went ahead an added this to osg::ClipNode, so there now
is a ClipNode::setReferenceFrame(RefernceFrame) method along the same
lines as the same method in osg::LightSource, osg::TexGenNode and
osg::Camera (all instance have the same menaning.)

The next problem was that ClipNode was decorating the whole scene, not
just the precipitation effect so I restructed the example.  So it now
looks like (note the setReferenceFrame and CliPlane in eye coords) :

osg::ref_ptrosg::Group group = new osg::Group;

if (clipDistance!=0.0)
{
osg::ref_ptrosg::ClipNode clipNode = new osg::ClipNode;
clipNode-addClipPlane( new osg::ClipPlane( 0 ) );
clipNode-getClipPlane(0)-setClipPlane( 0.0, 0.0, -1.0,
-clipDistance );
clipNode-setReferenceFrame(osg::ClipNode::ABSOLUTE_RF);
clipNode-addChild(precipitationEffect.get());

group-addChild(clipNode.get());
}
else
{
group-addChild(precipitationEffect.get());
}

group-addChild(loadedModel.get());

The osgprecitpitation example also now has a --clip distance command
line option to allow us to enable the above optional code path.  Try
values like 10 or 20 when loading the standard test example lz.osg.

Once this was all in place the precipitation effect still wasn't being
clipped, so I investigated user defined clipping plane and GLSL and
found that we need to explicitly set the gl_ClipVertex variable the
vertex shader.  Adding this fixed the clipping problem and hey presto
we can clip the precipitation effect and not the scene.

All these changes are now checked into svn/trunk and will be part of
the up coming 2.7.8 dev release.

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


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

2008-12-19 Thread Robert Osfield
HI Gerrick,

Are you compiling th with debug build?  I've been compiling this
plugin and fixing warnings in it, but didn't test the debug build.
I'll go and try a debug build.

Robert.

On Fri, Dec 19, 2008 at 4:24 PM, Gerrick Bivins
gbiv...@objectreservoir.com wrote:
 Hi Robert,
 Mac OSX 10.5.6, cmake (makefiles) build

 I ran into this error when compiling plugins:
 [ 68%] Building CXX object
 src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o
 /Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:
 In function 'void postProcessField(const SbIntList,
 osg::PrimitiveSet::Mode, SoMFInt32*, osg::Geometry::AttributeBinding)':
 /Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:653:
 error: 'dst2' was not declared in this scope
 make[2]: ***
 [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o]
 Error 1
 make[1]: *** [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/all] Error 2
 make: *** [all] Error 2

 Looks like this line needs to either not reference dst2 or be removed.
 assert(dst2+newNum == dst  Something wrong in the loop.);

 I didn't dig into what the intent for the check was but maybe someone knows
 if that can be gotten rid of or not.

  Gerrick



 On 12/19/08 9:42 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote:

 Hi Robert,

 Compilation ok : 0 error, 0 warnings on OSG only (no examples, no wrappers,
 ...)
 Under : VS 2005 SP1, Windows XP SP2

 Regards,
Vincent.

 2008/12/19 Robert Osfield robert.osfi...@gmail.com

 Hi All,

 I have now completed all my work in prep for the 2.7.8 and am
 personally ready to tag 2.7.8, but is the code ready... we I know it
 works fine for my under Kubunutu 8.10, but need some feedback from
 testing on other plartforms to know if things are working elsewhere.

 Since 2.7.7 I've made done a purge on warnings this has taken me a
 couple of days to complete, and now all fixable warnings (under g++
 4.3.2) are fixed, the ones that remain are down to 3rd party libs save
 for one the wrappers (that would break code to fix).  To do the
 warnings purged I've enable the OSG_USE_AGGRESSIVE_WARNINGS to ON,
 rather than the default of OFF.   With other compilers we may well see
 other warnings generated, this may be bogus or may be not, so it may
 or may not be appropriate to fix them. Feel free to post the warnigs
 for peer review.

 I had to fix hundreds of warnings so have touched many files in the
 OSG, an while I've have tried to be really careful about the changes,
 a number weren't as simple remove a comma or semi colon, requiring
 re-factoring of the code to avoid what the compiler saw as a possible
 ambiguity, this re-factoring does up the chance of me inadvertently
 introducing a bug.  The warnings did highlight a couple of bugs too,
 so these are fixed, lets just hope that the net improvement is
 positive...  but don't assume this, test the code like it may well be
 buggy with new problems arising in previously solid code.

 If testing looks good then I'll tag 2.7.8. If necessary I could make
 2.7.8 the branch point for OpenSceneGraph-2.8, but will only go ahead
 an do this if the FligthGear project need a more formal tag to base
 their own release on.  I'd rather not branch OpenSeneGraph-2.8 today
 though as I still some some dev work to complete, and bugs to fix that
 I want to make it into 2.8.

 Thanks in advance for your help with testing,
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

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


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


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

2008-12-19 Thread Robert Osfield
Hi Gerrick,

A debug build at my end reproduces the problem.  I've simply removed
the assert.  This change is now checked in svn/trunk.

Robert.

On Fri, Dec 19, 2008 at 4:24 PM, Gerrick Bivins
gbiv...@objectreservoir.com wrote:
 Hi Robert,
 Mac OSX 10.5.6, cmake (makefiles) build

 I ran into this error when compiling plugins:
 [ 68%] Building CXX object
 src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o
 /Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:
 In function 'void postProcessField(const SbIntList,
 osg::PrimitiveSet::Mode, SoMFInt32*, osg::Geometry::AttributeBinding)':
 /Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:653:
 error: 'dst2' was not declared in this scope
 make[2]: ***
 [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o]
 Error 1
 make[1]: *** [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/all] Error 2
 make: *** [all] Error 2

 Looks like this line needs to either not reference dst2 or be removed.
 assert(dst2+newNum == dst  Something wrong in the loop.);

 I didn't dig into what the intent for the check was but maybe someone knows
 if that can be gotten rid of or not.

  Gerrick



 On 12/19/08 9:42 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote:

 Hi Robert,

 Compilation ok : 0 error, 0 warnings on OSG only (no examples, no wrappers,
 ...)
 Under : VS 2005 SP1, Windows XP SP2

 Regards,
Vincent.

 2008/12/19 Robert Osfield robert.osfi...@gmail.com

 Hi All,

 I have now completed all my work in prep for the 2.7.8 and am
 personally ready to tag 2.7.8, but is the code ready... we I know it
 works fine for my under Kubunutu 8.10, but need some feedback from
 testing on other plartforms to know if things are working elsewhere.

 Since 2.7.7 I've made done a purge on warnings this has taken me a
 couple of days to complete, and now all fixable warnings (under g++
 4.3.2) are fixed, the ones that remain are down to 3rd party libs save
 for one the wrappers (that would break code to fix).  To do the
 warnings purged I've enable the OSG_USE_AGGRESSIVE_WARNINGS to ON,
 rather than the default of OFF.   With other compilers we may well see
 other warnings generated, this may be bogus or may be not, so it may
 or may not be appropriate to fix them. Feel free to post the warnigs
 for peer review.

 I had to fix hundreds of warnings so have touched many files in the
 OSG, an while I've have tried to be really careful about the changes,
 a number weren't as simple remove a comma or semi colon, requiring
 re-factoring of the code to avoid what the compiler saw as a possible
 ambiguity, this re-factoring does up the chance of me inadvertently
 introducing a bug.  The warnings did highlight a couple of bugs too,
 so these are fixed, lets just hope that the net improvement is
 positive...  but don't assume this, test the code like it may well be
 buggy with new problems arising in previously solid code.

 If testing looks good then I'll tag 2.7.8. If necessary I could make
 2.7.8 the branch point for OpenSceneGraph-2.8, but will only go ahead
 an do this if the FligthGear project need a more formal tag to base
 their own release on.  I'd rather not branch OpenSeneGraph-2.8 today
 though as I still some some dev work to complete, and bugs to fix that
 I want to make it into 2.8.

 Thanks in advance for your help with testing,
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

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


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


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

2008-12-19 Thread Gerrick Bivins
Good question. It depends on what the default build is from Cmake settings.
I haven't manually changed the complier options so I assumed it was opt
(make install) but I'll need to check that.
 Gerrick


On 12/19/08 10:27 AM, Robert Osfield robert.osfi...@gmail.com wrote:

 HI Gerrick,
 
 Are you compiling th with debug build?  I've been compiling this
 plugin and fixing warnings in it, but didn't test the debug build.
 I'll go and try a debug build.
 
 Robert.
 
 On Fri, Dec 19, 2008 at 4:24 PM, Gerrick Bivins
 gbiv...@objectreservoir.com wrote:
 Hi Robert,
 Mac OSX 10.5.6, cmake (makefiles) build
 
 I ran into this error when compiling plugins:
 [ 68%] Building CXX object
 src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o
 /Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInve
 ntor.cpp:
 In function 'void postProcessField(const SbIntList,
 osg::PrimitiveSet::Mode, SoMFInt32*, osg::Geometry::AttributeBinding)':
 /Users/gbivins/work/APIs/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInve
 ntor.cpp:653:
 error: 'dst2' was not declared in this scope
 make[2]: ***
 [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/ConvertToInventor.cpp.o]
 Error 1
 make[1]: *** [src/osgPlugins/Inventor/CMakeFiles/osgdb_iv.dir/all] Error 2
 make: *** [all] Error 2
 
 Looks like this line needs to either not reference dst2 or be removed.
 assert(dst2+newNum == dst  Something wrong in the loop.);
 
 I didn't dig into what the intent for the check was but maybe someone knows
 if that can be gotten rid of or not.
 
  Gerrick
 
 
 
 On 12/19/08 9:42 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote:
 
 Hi Robert,
 
 Compilation ok : 0 error, 0 warnings on OSG only (no examples, no wrappers,
 ...)
 Under : VS 2005 SP1, Windows XP SP2
 
 Regards,
Vincent.
 
 2008/12/19 Robert Osfield robert.osfi...@gmail.com
 
 Hi All,
 
 I have now completed all my work in prep for the 2.7.8 and am
 personally ready to tag 2.7.8, but is the code ready... we I know it
 works fine for my under Kubunutu 8.10, but need some feedback from
 testing on other plartforms to know if things are working elsewhere.
 
 Since 2.7.7 I've made done a purge on warnings this has taken me a
 couple of days to complete, and now all fixable warnings (under g++
 4.3.2) are fixed, the ones that remain are down to 3rd party libs save
 for one the wrappers (that would break code to fix).  To do the
 warnings purged I've enable the OSG_USE_AGGRESSIVE_WARNINGS to ON,
 rather than the default of OFF.   With other compilers we may well see
 other warnings generated, this may be bogus or may be not, so it may
 or may not be appropriate to fix them. Feel free to post the warnigs
 for peer review.
 
 I had to fix hundreds of warnings so have touched many files in the
 OSG, an while I've have tried to be really careful about the changes,
 a number weren't as simple remove a comma or semi colon, requiring
 re-factoring of the code to avoid what the compiler saw as a possible
 ambiguity, this re-factoring does up the chance of me inadvertently
 introducing a bug.  The warnings did highlight a couple of bugs too,
 so these are fixed, lets just hope that the net improvement is
 positive...  but don't assume this, test the code like it may well be
 buggy with new problems arising in previously solid code.
 
 If testing looks good then I'll tag 2.7.8. If necessary I could make
 2.7.8 the branch point for OpenSceneGraph-2.8, but will only go ahead
 an do this if the FligthGear project need a more formal tag to base
 their own release on.  I'd rather not branch OpenSeneGraph-2.8 today
 though as I still some some dev work to complete, and bugs to fix that
 I want to make it into 2.8.
 
 Thanks in advance for your help with testing,
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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


Re: [osg-users] Memory management in OSG

2008-12-19 Thread Pierre Bourdin (gmail)
Le vendredi 19 décembre 2008 à 10:31 -0500, Jean-Sébastien Guay a
écrit :

 Hello Pierre,
 
  valgrind is very powerfull if you're on an Linux/Unix environnement, if 
  you are using MSVC you can use this:
 
 ...
 
  when you stop debugging you program, it make a memory leaks report in 
  the msvc output console...
 
 Does this work well with ref_ptrs? i.e. will it spit out hundreds of 
 false positives for things that are ref counted and do not actually leak?
 
 What I'd really like is to compare the state of memory (preferably with 
 where the memory was allocated) at two points of the program's run. If I 
 can just get a dump of that, and then diff the two, I could see what 
 leaks between when the first file is opened and when the second one is.
 
 The project we're working on currently does not run on Linux though it 
 will eventually, so valgrind is not an alternative right now.
 
 Thanks,
 
 J-S

I'm afraid you will have some false positive, but I've not tested...

I understand pretty well what you would like to do, but I don't know if
ti's possible...
Maybe using the _CRTDBG_DELAY_FREE_MEM_DF (Keep freed memory blocks in
the heap's linked list, assign them the _FREE_BLOCK type, and fill them
with the byte value 0xDD. OFF: Do not keep freed blocks in the heap's
linked list. )

The best way is probably to log every allocation and deletion to a file
using a macro to override the normal new, delete, malloc or free...
Then you will have a complete liste of allocated and liberated bloc...

Maybe it can be of any help ?
http://www.codeproject.com/KB/cpp/MLFDef.aspx

Pierre.

Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 80 18
fax: 04 68 55 03 86
email: bour...@imerir.com

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


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

2008-12-19 Thread Jean-Sébastien Guay

Hi Robert,


I have now completed all my work in prep for the 2.7.8 and am
personally ready to tag 2.7.8, but is the code ready... we I know it
works fine for my under Kubunutu 8.10, but need some feedback from
testing on other plartforms to know if things are working elsewhere.


Seems like your warning purge was successful on Windows too, at least 
for the core and main nodekits:


1OpenThreads - 0 error(s), 0 warning(s)
2osg - 0 error(s), 0 warning(s)
3osgDB - 0 error(s), 0 warning(s)
4osgUtil - 0 error(s), 0 warning(s)
5osgAnimation - 0 error(s), 0 warning(s)
6osgText - 0 error(s), 0 warning(s)
7osgGA - 0 error(s), 0 warning(s)
8osgVolume - 0 error(s), 0 warning(s)
9osgFX - 0 error(s), 0 warning(s)
10osgParticle - 0 error(s), 0 warning(s)
11osgShadow - 0 error(s), 0 warning(s)
12osgSim - 0 error(s), 0 warning(s)
13osgViewer - 0 error(s), 0 warning(s)
14osgManipulator - 0 error(s), 0 warning(s)
15osgWidget - 0 error(s), 0 warning(s)
16osgTerrain - 0 error(s), 0 warning(s)

The examples also all compile without warnings. Some plugins have some 
warnings caused by dependencies, as you said.


The one warning I get which we can fix is:

116..\..\..\..\src\osgPlugins\gz\ReaderWriterGZ.cpp(255) : warning 
C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)


The offending line is this:

if (ret != Z_OK)
return ret;

changing that to return false; would fix it, as is done further down in 
the function when there's an error.


So other than that, current SVN trunk compiles fine for me, Windows 
Vista, VS2005 SP1. I'll run a few tests next to make sure most things 
run well too.


Very nice. Thanks,

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


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

2008-12-19 Thread Gerrick Bivins
Hi Robert,
Success!

I built plugins and examples as well.
 Gerrick


On 12/19/08 10:45 AM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:

 Hi Robert,
 
 I have now completed all my work in prep for the 2.7.8 and am
 personally ready to tag 2.7.8, but is the code ready... we I know it
 works fine for my under Kubunutu 8.10, but need some feedback from
 testing on other plartforms to know if things are working elsewhere.
 
 Seems like your warning purge was successful on Windows too, at least
 for the core and main nodekits:
 
 1OpenThreads - 0 error(s), 0 warning(s)
 2osg - 0 error(s), 0 warning(s)
 3osgDB - 0 error(s), 0 warning(s)
 4osgUtil - 0 error(s), 0 warning(s)
 5osgAnimation - 0 error(s), 0 warning(s)
 6osgText - 0 error(s), 0 warning(s)
 7osgGA - 0 error(s), 0 warning(s)
 8osgVolume - 0 error(s), 0 warning(s)
 9osgFX - 0 error(s), 0 warning(s)
 10osgParticle - 0 error(s), 0 warning(s)
 11osgShadow - 0 error(s), 0 warning(s)
 12osgSim - 0 error(s), 0 warning(s)
 13osgViewer - 0 error(s), 0 warning(s)
 14osgManipulator - 0 error(s), 0 warning(s)
 15osgWidget - 0 error(s), 0 warning(s)
 16osgTerrain - 0 error(s), 0 warning(s)
 
 The examples also all compile without warnings. Some plugins have some
 warnings caused by dependencies, as you said.
 
 The one warning I get which we can fix is:
 
 116..\..\..\..\src\osgPlugins\gz\ReaderWriterGZ.cpp(255) : warning
 C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)
 
 The offending line is this:
 
  if (ret != Z_OK)
  return ret;
 
 changing that to return false; would fix it, as is done further down in
 the function when there's an error.
 
 So other than that, current SVN trunk compiles fine for me, Windows
 Vista, VS2005 SP1. I'll run a few tests next to make sure most things
 run well too.
 
 Very nice. Thanks,
 
 J-S

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


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

2008-12-19 Thread Robert Osfield
Hi J-S,

On Fri, Dec 19, 2008 at 4:45 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
 The offending line is this:

if (ret != Z_OK)
return ret;

 changing that to return false; would fix it, as is done further down in the
 function when there's an error.

Now fixed this and checked it in.

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


[osg-users] reducing detail in 3d models

2008-12-19 Thread Joe Lyga
Hi osg-users,

I was wondering if anyone knew something that allows you to reduce the
geometric detail of a model, but keeps material settings in tact.  I'm
working on creating LODs out of my models, and I normally use ac3d to
simplify the geometry of the models I'm working with.  This works fine
on models that just use textures, but I have a few that just use
materials, and ac3d wipes the material settings when it simplifies the
geometry.  I've tried osg's simplifier, but it doesn't seem to
accomplish what I'm trying to do.

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


Re: [osg-users] ScreenSpaceAmbientOcclusion

2008-12-19 Thread Adrian Egli OpenSceneGraph (3D)
Nivdia stuff.

:-) tangent and depth maps are no in first texture

missing
(1) fovy / ratio (x,y) one step == meters
(2) radian insteat of box (squre)

but this will become nie

2008/12/19 yann le paih lepaih.y...@gmail.com

 Third step could be to implement this new paper : SSDO (Approximating
 Dynamic Global Illumination in Image Space)

 http://www.uni-koblenz.de/~ritschel/http://www.uni-koblenz.de/%7Eritschel/





 On Fri, Dec 19, 2008 at 11:45 AM, Raymond de Vries ree...@xs4all.nlwrote:

 Hi Adrian,

 Thnx for the info, cool that it's already implemented in Blender :-)

 Cheers, have fun.

 Raymond


 Adrian Egli OpenSceneGraph (3D) wrote:

 Starting point of this first version is this very simple algorithm:
 http://mikepan.homeip.net/ssaowcn

 once this will perfectly work, then we can implementing a more complex
 one.

 there are many diferent papers describing how we can implementing high
 quality SSAO

 /adrian

 2008/12/18 Raymond de Vries ree...@xs4all.nl mailto:ree...@xs4all.nl


Hi Adrian,

This looks very nice! Could you give a little more background
info? Did you use the nvidia paper as starting point? E.g. I am
curious if this technique is applicable for large outdoor
environments.

Thanks a lot
Raymond



Adrian Egli OpenSceneGraph (3D) wrote:

Hi Robert,

i implement a first version of SSAO effect and i have only one
issue left in the implementation. the whole thing works nicely
with GLSL shader, mutlipass-rendering when we don't resize the
window, actually 512x512. so
what sould i do, to replace this issue. ?

Another thing is to remove the last pass GLSL shader, is there
a way to solve it under common openGL textureing?
Mutlitextureing? Or any other idea.

This version supports:

(Transparant faces: just disable for transparent faces like
window, glass the detph writing, the depth buffer will hold
only un-transparent z-values (alpha  0.9) )

toggle ssao on/off with key 'a'

have a look and i will be happy to get any ideas to improve
the stuff.
FPS is about 30.

/adrian
--
Adrian Egli

  

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

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


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

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




 --
 
 Adrian Egli
 

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



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




 --
 Yann Le Paih
 Keraudrono
 56150 BAUD
 Portable: +33(0)610524356
 lepaih.y...@gmail.com

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




-- 

Adrian Egli

/* -*-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 osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode

#include osg/Switch
#include osg/Uniform

#include osgText/Text
#include osg/ShapeDrawable
#include osg/Geometry
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/BlendFunc

#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator

#include iostream

#include osgFX/Effect
#include osgFX/Technique
#include osgFX/Registry

#include osg/TexGen
#include osg/Texture2D

#include osg/PolygonOffset
#include osgDB/WriteFile





struct WriteCameraPostDrawCallback : public 

[osg-users] OpenSceneGraph-2.7.8 dev release tagged

2008-12-19 Thread Robert Osfield
7.8Hi All,

I have just tagged the 2.7.8 dev release, what should be out last dev
release before I tag the OpenSceneGraph-2.8 stable branch.  Details on
the DeveloprReleases page:

   http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases

* OpenSceneGraph-2.7.8, released on 19th December 2008.
OpenSceneGraph-2.7.8, changes include:
  o DatabasePager now by default using the
TargetMaximumNumberOfPagedLOD to enable better memory management, and
switched off the pre-compile option to enable faster merging of tiles.
  o Warnings purge for 2.8 release.
  o Cmake/Cpack packaging support
  o Build and bug fixes

source package : OpenSceneGraph-2.7.8.zip
svn tag: svn co
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.7.8
OpenSceneGraph

As we are now so close to making a stable release I'd appreciate
testing, testing, testing!

Thanks in advance,
Robert.

ps.  FlightGear contributors... you guys have gone quite over the last
two days, no doubt busy with other pressing work... any chance of an
update?  Is FG going for a release today?  Is 2.7.8 sufficient for
your purposes?  Do you need a 2.8 branch?

ChnageLog between 2.7.7 and 2.7.8:

2008-12-19 18:37  require
  system, architecture or compiler

2008-12-15 22:18  robert

* include/osgTerrain/Terrain, include/osgTerrain/TerrainTile,
  src/osgTerrain/GeometryTechnique.cpp, src/osgTerrain/Terrain.cpp,
  src/osgTerrain/TerrainTile.cpp: Added support for a
  Terrain::s/getTerrainTechniquePrototype()

2008-12-15 20:38  robert

* src/osgViewer/GraphicsWindowCarbon.cpp: From Tatsuhiro Nishioka,
  I found a bug in GraphicsWindowCarbon.
  GraphicsWindowCarbon::requestWarpPointer() places the mouse
  pointer in a (global?) display coordination, but it must be in a
  local window coordination. This problem is critical because the
  mouse cursor can go off a window especially when you place the
  window on the secondary screen.

  Attached is the file to fix this problem.

  I tested this modified file with the following situations (on
  FlightGear) and all works fine.
  - two windows on two screens (each has one window).
  - two windows on two screens (secondary screen has all windows).
  - two windows on two screens (primary screen has all windows).

  In all scenarios, warp requests (by right-click the mouse)
  successfully moves the mouse pointer to the center of the main
  window,
  and it is what it's supposed to be in the flightgear.

2008-12-15 20:32  robert

* applications/CMakeLists.txt: Limited the static build to just
  osversion and osgstaticviewer

2008-12-15 19:37  robert

* include/osg/GLExtensions, src/osg/GLExtensions.cpp,
  src/osg/Texture.cpp: Aded
  osg::isGLExtensionOrVersionSupported(uint contextID, char*
  extensionName, float minVersionRequired) method that
  returns true if (the extension string is supported or GL version
  is greater than or equal to a specified version) and
  non extension disable is used. This makes it possible to disable
  extensions that are now
  available as parts of the core OpenGL spec.

  Updated Texture.cpp is use this method.

2008-12-15 16:46  robert

* src/osg/StateAttribute.cpp, src/osg/StateSet.cpp,
  src/osg/Uniform.cpp: From Paul Martz, I'm not sure why this
  message was added, but it doesn't appear to merit INFO verbosity.
  Changing this from INFO to DEBUG_FP.

2008-12-15 16:42  robert

* src/osg/BufferObject.cpp: From Peter Hrenka, I implemented a
  free list reallocation scheme in
  VertexBufferObject::compileBuffer().

  The offsets of newly added Arrays were not properly
  calculated. This submission tries to find a
  matching empty slot when the total size of
  the VBO has not changed (e.g. when an array
  is replaced by another array of the same size).


  This fixes the overwriting issue that I showed in my posting
  Bug in VertexBufferObject::compileBuffer on OSG-Users.
  

2008-12-15 16:41  robert

* src/osgDB/DatabasePager.cpp: Reduced the default number
  _targetMaximumNumberOfPageLOD to 300 to keep the memory
  consumption on large databases a bit lower.

2008-12-15 16:10  robert

* include/osgDB/DatabasePager: Added deprecated messages to get/set
  methods of outgoing expiry schemes.

2008-12-15 14:07  robert

* CMakeLists.txt, CMakeModules/OsgCPack.cmake,
  src/osgWrappers/CMakeLists.txt: From Mathias Helsing, Cpack
  support submission with:

  Better package naming. example
  

[osg-users] osgwidgets shader fix

2008-12-19 Thread Gerrick Bivins
This shader failed to compile on my mac and I noticed there was a TODO note
in the code to fix it...
This should work now, although I don't have a linux or windows box to test
it at the moment.
Gerrick 




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


[osg-users] osgviewerWX example fails to build with debug

2008-12-19 Thread Mark Acosta

Hi guys,

   I'm running  Fedora 10 and trying to build OSG from the latest svn 
version. Everything compiles fine except for the osgviewerWX example. I'm 
getting these errors:


CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o: In function 
`wxStringBase':
/usr/include/wx-2.8/wx/string.h:351: undefined reference to 
`wxOnAssert(wchar_t const*, int, char const*, wchar_t const*, wchar_t 
const*)'
CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o:(.rodata._ZTV8wxOsgApp[vtable 
for wxOsgApp]+0x130): undefined reference to `wxApp::OnAssertFailure(wchar_t 
const*, int, wchar_t const*, wchar_t const*, wchar_t const*)'
CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o:(.rodata._ZTV8wxOsgApp[vtable 
for wxOsgApp]+0x138): undefined reference to `wxAppConsole::OnAssert(wchar_t 
const*, int, wchar_t const*, wchar_t const*)'


   I looked into this a bit and the routines listed above are only defined 
if __WXDEBUG__ is defined. Looking at /usr/include/wx-2.8/wx/debug.h, it's 
not clear to me how __WXDEBUG__ is getting defined. I noticed that if I 
define NDEBUG that it will undefine __WXDEBUG__. The example compiles if I 
do this, but it's more of a kluge than a solution.


   I'm no wx expert. Maybe someone on the list has an idea of what's going 
on here and what the proper fix is.


Mark 


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


Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4

2008-12-19 Thread Paul Fotheringham
Hi Robert,

Thanks for that. I tried with the latest code from SVN and a fresh build 
directory and I still got the same two unresolved symbols.

I'm off on holiday now so I won't have access to the MacOSX machine at work 
until I get back in January. I didn't realise you were busy doing the 2.7.8 
release. If you do get a spare moment at some point then IMO the blog entry I 
linked to in my first post is quite informative. Since I'm new to the Mac I 
have no idea if it's a really bad thing that the 10.4 SDK libs on my system 
have different symbols from the 10.4 system libs. It does sound dodgy to me and 
even though I can tweak things to get osgText to build I wouldn't be surprised 
if it doesn't run (I'm actually not bothered as we don't use that particular 
library).

Oh well, thanks anyway, and have a good christmas and maybe we can resume this 
in January. Hopefully in the meantime someone with good Mac knowledge can maybe 
wade in to clarify it all :)

Paul

--- On Fri, 19/12/08, Robert Osfield robert.osfi...@gmail.com wrote:

 From: Robert Osfield robert.osfi...@gmail.com
 Subject: Re: [osg-users] Build error on MAc OSX 10.4 and OSG 2.7.4
 To: osg_u...@yahoo.co.uk, OpenSceneGraph Users 
 osg-users@lists.openscenegraph.org
 Date: Friday, 19 December, 2008, 4:14 PM
 Hi Paul,
 
 When I was removing the MATH_LIBRARY entry from the
 src/osgText/CMakeLists.txt  (the one that I had added to
 see it would
 help you) I noticed that FreeType was listed but this
 isn't needed by
 osgText, just by the freetype plugin so I have removed this
 as it's
 not needed and potentially could extra complications that
 it needn't
 have.  Could you try svn/trunk to see if it makes any
 difference.
 I've attached the cleaned up osgText/CMakeLists.txt in
 case you just
 want to try this on its own.
 
 Robert.
 
 
 On Fri, Dec 19, 2008 at 3:53 PM, Paul Fotheringham
 osg_u...@yahoo.co.uk wrote:
  Hi Robert,
 
  If I set MATH_LIBRARY to  then it builds
 fine (with nothing on any on the link lines).
 
  Also, if I set it to
 /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib it also
 works fine (with
 /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libm.dylib on each
 link line).
 
  I must admit I'm puzzled as to why the string
 associated with MATH_LIBRARY is appearing on the link lines
 for all the libraries and not just libosg itself as none of
 the CMakeLists.txt files other than the one in the osg
 folder refer to it. Are the other libraries somehow
 inheriting this setting from the cmake settings in libosg?
 
  Paul
 
  --- On Fri, 19/12/08, Robert Osfield
 robert.osfi...@gmail.com wrote:
 
  From: Robert Osfield
 robert.osfi...@gmail.com
  Subject: Re: [osg-users] Build error on MAc OSX
 10.4 and OSG 2.7.4
  To: OpenSceneGraph Users
 osg-users@lists.openscenegraph.org
  Date: Friday, 19 December, 2008, 11:15 AM
  Hi Paul,
 
  What happens if, using ccamke, you manually set
 the
  MATH_LIBRARY to 
  or to your frameworks version?
 
  Robert.
 
  On Fri, Dec 19, 2008 at 11:06 AM, Paul
 Fotheringham
  osg_u...@yahoo.co.uk wrote:
   --- On Fri, 19/12/08, Robert Osfield
  robert.osfi...@gmail.com wrote:
  
   From: Robert Osfield
  robert.osfi...@gmail.com
   Subject: Re: [osg-users] Build error on
 MAc OSX
  10.4 and OSG 2.7.4
   To: osg_u...@yahoo.co.uk,
 OpenSceneGraph
  Users
 osg-users@lists.openscenegraph.org
   Date: Friday, 19 December, 2008, 8:46 AM
   Hi Paul,
  
   On Thu, Dec 18, 2008 at 6:37 PM, Paul
 Fotheringham
   osg_u...@yahoo.co.uk wrote:
Hi Robert,
   
Thanks for looking into this.
   
--- On Thu, 18/12/08, Robert Osfield
   robert.osfi...@gmail.com wrote:
snip
The core OSG library does link
 against
  the
   MATH_LIBRARY,
but the other
non of the other core libraries
 do.
   
Apparently not on MacOSX using cmake
 :)
  
   Please read what I've already
 written.
  I've been
   using Cmake under
   OSX as others have been as well, without
 problems.
  
   I've already explained not once, but
 twice now,
  why that is.
  
Take a look at
   
   
 src/osgText/CMakeFiles/osgText.dir/link.txt
   
without the change you just made. In
 fact
  take a look
   at any of the link.txt files for each OSG
 library.
  Thay all
   have /usr/lib/libm.dylib in there.
   
I've added a entry of
MATH_LIBRARY into the linking of
 osgText.
   Could
   you do an
svn update
and see if the error is fixed?
   
I got the svn version and no it
 doesn't
  fix it.
   All it does is move the
   
/usr/lib/libm.dylib
   
reference on the link line to a
 different
  place!
   
The fact you've got errors
 but others
  under
   OSX
haven't reported this
(including myself) suggests that
 must be
  something
   else
going w.r.t
gcc/SDK's you are using on
 your
  machine.
   
I'm sorry I haven't
 explained this
  well
   enough. The goal here is to *not* have
 any
  explicit
   reference to libm.dylib on the link line.
   
The symbols reside in the SDK
 

Re: [osg-users] Building the Collada plugin

2008-12-19 Thread Randolph Fritz
DOM 2.1 isn't even available on sourceforge any more. Basically I think 
I'm scrod, or some other sort of fish. I'll experiment some more with 
2.2, and I suppose I can try the 2.7.8 release, but writing an OSG 
export script for SketchUp is looking better and better.


Randolph

Smeenk, R.J.M. (Roland) wrote:

Randolph,

The Collada plugin has only be used with the Collada DOM 2.1 library.
DOM 2.2 was silently released two weeks ago, but I haven't tested it
yet. 
There have been a few changes to the Cmake files since osg 2.6.1 so

maybe the older version does not work right out of the box.

--
Roland


  

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of R Fritz

Sent: donderdag 18 december 2008 3:14
To: OpenSceneGraph Users
Subject: [osg-users] Building the Collada plugin

OSG 2.6.1, VS 2008.

So far I've downloaded COLLADA_1.4.1_DOM_1.3.0.zip, built it, 
and got a slew of errors trying to build the plugin.  
(Collada DOM 2.2, which looks like it might be downward 
compatible, uses a different library structure, and I've no 
idea which files are still needed.)


Which version of Collada is known to work?  Does the plugin 
work at all with VS 2008?


Randolph

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


negraph.org
  
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html


___
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] RenderInfo UserData property: how to set it?

2008-12-19 Thread Russell East
   I use the approach outlined in
http://www.3drealtimesimulation.com/osg/osg_faq_1.htm#f40 for embedding OSG
within an existing application, and I'm using OSG 2.6.0 on Windows XP.

I have some custom Drawables that I add to the scenegraph, and I pass them
some frame rendering context data into their drawImplementation method
during the rendering phase like this:

// sets up the application context data
osg::ref_ptr MyRenderInfoUserData  rpUserData = new
MyRenderInfoUserData({my frame rendering context data});
// makes the context data available to Drawables that do *not* use GL
DisplayLists
mySceneView-getRenderInfo().setUserData( rpUserData.get() );
// makes the context data available to Drawables that *do* use GL
DisplayLists
osg::NodeVisitor *pNodeVisitor = mySceneView-getInitVisitor();
osgUtil::GLObjectsVisitor *pGLObjectsVisitor =
dynamic_castosgUtil::GLObjectsVisitor *(pNodeVisitor);
if (pGLObjectsVisitor)
{
  pGLObjectsVisitor-getRenderInfo().setUserData( rpUserData.get() );
}
// make the rendering calls
mySceneView-update ();
mySceneView-cull ();
mySceneView-draw ();

where

class MyRenderInfoUserData : public osg::Referenced { ... }

This seems a bit convoluted, is there a more elegant way to do what I want?

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


[osg-users] Stereo with HMD in OpenSceneGraph

2008-12-19 Thread tien dat
Hi all,

I have a question about controlling stereo with HMD in OpenSceneGraph.

Basically to setup stereo display you need the distance of two eyes
and the convergence angle. When I take a look at OpenSceneGraph code
for setting up stereo with HMD, I see two other variables which are
screen distance and fusion distance. There is also a matrix to
multiple with each view for each eye that uses these variables. So
could any of you tell me what they mean and what happens if I change
these variables.

Thank you very much,

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