Re: [osg-users] osg::LOD range distance Coordinate System Question

2009-10-09 Thread Robert Osfield
Hi Sean,

You are correct the range distance of LOD's are in the LOD's own local
co-coordinate system.  This is appropriate as you almost aways want
LOD's to scale relative to a screen size, and doing the calc in local
coordinate allows you to decorate subgraphs with LOD's with transforms
that scale up or down the subgraph and still have the LOD ranges
computed appropriate for that new scaling.  This behavior is key to
get a scene graph to be well encapsulated.

It sounds like in your case you have transforms above your LOD's that
scale your objects, but you still want their ranges to set in world
coords, that ignore any transforms.  This would present the problem
that is the transforms scale change then the LOD would choose
different children - choosing an in-apprioriate level of detail for
the on screen size.

Robert.

On Fri, Oct 9, 2009 at 5:21 AM, Sean Spicer sean.spi...@aqumin.com wrote:
 Studying the source a bit harder, I think the range-distance is
 definitely in Object (local) coordinate.  The distance calculation
 (osg::LOD.cpp) is:

 required_range = nv.getDistanceToViewPoint(getCenter(),true);

 where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp)

 (pos-getViewPointLocal()).length()*getLODScale();

 So, this raises the question: is there a good reason why there is no
 option to specify the LOD range distance in World Coordinates?  This
 would make complex LOD graphs like the one I'm working on much, much
 simpler.  Perhaps there is another method that I just do not see?

 cheers,

 sean

 On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer sean.spi...@aqumin.com wrote:

 This may be a simple question - is the LOD range distance specified in 
 object or world coordinates?  I seems as if it should be in world 
 coordinates, but I've got an example with numerous LOD nodes in sub-graphs, 
 and if I sent a constant distance range in each of them (0.0, 30.0f) so that 
 each LOD node has the same range - the LOD switch only behaves as expected 
 if the transforms above each LOD node are identical.  The moment I have a 
 scale matrix above the LOD the switch becomes dependent on the 
 scaling...e.g. larger LODs switch before smaller ones.  This leads me to 
 think that the LOD range distance is in object coordinates, and needs to be 
 scaled by the localToWorld transform.
 I've had a look at the source, and it seems logical (not to mention that I'd 
 be shocked if someone hadn't had a problem before this if it were incorrect) 
  Comments?  Thoughts?
 cheers,
 sean
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.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] osgUtil::simplifier parameters

2009-10-09 Thread Vincent Bourdier

Hi,

A little update, nobody can explain me the simplifier in details ?

Thanks.

Regards,
  Vincent

Vincent Bourdier a écrit :

Hi,

I do an update on this topic, because I would like to understand well 
the osgUtil::simlifier.
This implementation seems to be very complex and powerful, but I don't 
know how to manage it better.


/For that I would like to know what do the following methods and how 
to set the values to have the expected result :/


   void setSampleRatio(float sampleRatio) { _sampleRatio =
   sampleRatio; }


   /** Set the maximum point error that all point removals must
   be less than to permit removal of a point.
 * Note, Only used when down sampling. i.e. sampleRatio  
1.0*/

   void setMaximumError(float error) { _maximumError = error; }


   /** Set the maximum length target that all edges must be
   shorted than.
 * Note, Only used when up sampling i.e. sampleRatio  1.0.*/

Maybe this is a noob question, but I think it can help/inform other 
osg users to know precisely how to configure the Simplifier...


I set the Sample ratio to values  1, and this seems to do some good 
job on my model, but not enough... I am looking at a way to destruct a 
mesh from 800 Mbyte (.ive) to 100Mbyte (.ive) (for LOD usage mainly)
I know the size of the ive file is not a good reference, but it is 
important for my application. And I know that if a file is lesser, the 
mesh will be lighter too...

Relative to that,
/What can make an ive file heavy// or light ?/ (example : 20M 
triangles in a 850Mbyts ive file, not proportional to 13M triangles in 
a 710Mbytes file)


Thanks for your help.

Regards,
  Vincent.

Vincent Bourdier a écrit :

Hi Andrew

Thanks for the tip on the simplifier, lower the sample ratio is, 
lower the vertex number is. (I get a crash under 0.6 but I'm not sure 
this is an osg crash)
Concerning the optimiser, this do not reduce the vertex number but 
the inverse... on a 460k vertices model, the optimizer returns me a 
480k vertices model ...


I'm looking for a destructive optimizer/simplifier for my model... Do 
you have any other tips or idea ?


Thanks.

Regards,
   Vincent.

2009/9/21 Andrew Burnett-Thompson aburnettthomp...@googlemail.com 
mailto:aburnettthomp...@googlemail.com


Hi there,

I've experimented with the simplifier, but am not using it.

I found the setSampleRatio() method affects how coarse or fine a
result you get. The simplification with a sample ratio less that
1.0 appears to be destructive (i.e. Geometry out does not equal
Geometry in). So far I've not found the right settings to be
beneficial for my needs (which is reduction of memory consumption
while keeping the mesh the same or similar).

Another way of reducing the vertex count in your scene is to use
the Optimizer. Here I have found that using the Optimizer with the
options MERGE_GEOMETRY, CHECK_GEOMETRY and TRISTRIP_GEOMETRY can
significantly reduce the number of vertices/primitives in each
Geometry object, while giving you essentially the same mesh out.


On Mon, Sep 21, 2009 at 10:10 AM, Vincent Bourdier
vincent.bourd...@gmail.com mailto:vincent.bourd...@gmail.com
wrote:

Up ?

No one does osg simplifications ?

Thanks,
   Vincent.

2009/9/17 Vincent Bourdier vincent.bourd...@gmail.com
mailto:vincent.bourd...@gmail.com

Hi all,

Using the osg simplifier on a geometry, I'm just surprised
to see that there is no way to set a level of
simplification or something like that.
Maybe I didn't saw it, but for the moment I just found

_sm-setDoTriStrip(true);  //what for ? do triangle strip
are more optimized ?
_sm-setSampleRatio(?); //what does it mean ? what does it
changes ?
...

How can I control the simplification level ?
Is this simplifier a destructive one ? (can deform the
geometry)

Thanks.

Regards,
   Vincent.




___
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 







__ Information from ESET NOD32 Antivirus, version of virus 
signature database 4487 (20091007) __


The message was checked by ESET NOD32 Antivirus.

http://www.eset.com





__ Information from ESET NOD32 Antivirus, version of virus signature 
database 4492 (20091009) __

The message

Re: [osg-users] osgUtil::simplifier parameters

2009-10-09 Thread Robert Osfield
On Fri, Oct 9, 2009 at 10:09 AM, Vincent Bourdier
vincent.bourd...@gmail.com wrote:
 A little update, nobody can explain me the simplifier in details ?

I've explained details before so have a look through the osg-users archives.

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


Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?

2009-10-09 Thread Ralf Stokholm
Hi All

Just wantet to add that we are also using Delta3d and as a consequence we
are using the composite viewer.

Brgs.

Ralf Stokholm

2009/10/8 Michael Bach Jensen mich...@ifad.dk

 Hello everyone,

 We are having the exact same problem at our company for quite some time
 (currently on osg 2.8.0 via Delta3D and using TerraPage terrains). I have
 verified that viewing the terrain in the osgViewer works fine, but in our
 app, which also uses multiple cameras, the memory-keeps-growing-until-crash
 issue occurs when the cameras are not looking at the exact same thing (have
 the same projection and view matrices with the same LOD scale). The more
 different they are, the easier it is to trigger the issue, it seems.

 What we did to work around the issue, is to make sure that no two cameras
 in the graph render the same PagedLOD node. That is, we load the terrain
 multiple times using osgDB::readNodeFile and point each camera to each
 instance.

 I hope this helps on shedding some light on what is going on.

 Additional info:
 Delta3D design currently limits OSG to single-threaded mode. I am on
 WindowsXP, using an NVidia card, not that I think that makes a difference.

 I also seem to recall, that the active lod node list in the pager starts to
 grow rapidly when I put the second camera into the scene graph at runtime.

 Cheers,
 Michael

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





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.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] New OpenGL texture object and buffer object pool support

2009-10-09 Thread Eric Deko

pankajnagarkoti80 wrote:
 The benefit the GL object pools provide is that we can scale up the
 scene graph in main memory without blowing OpenGL driver and GPU
 memory as we would do without the new pools.


I agree, that is really a great benifit especially with the GL users.

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





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


Re: [osg-users] [3rdparty] osgOcean collision detection

2009-10-09 Thread Jan Ciger
Hello,

Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote:
 Hi Jan,
 
 While I was at it, I started integrating the changes for getting the
 ocean surface height at a position. I went with a combination of
 Jean-Claude's and Dimitrios' code, with a few small modifications.
 
 The only problem is I have no way of testing it (it builds, thus it
 works by definition, right? :-) ). Would it be possible (for either you,
 Dimitrios, or Jean-Claude) to make a very simple test using the
 oceanExample as base code, perhaps just making the Cessna from OSG-Data
 float on the water the way you want? Then I could test if the
 modifications I made work.
 
 I really dislike committing work-in-progress code... So I'd prefer to do
 it that way.

Right, of course. I have a bit of code that makes an object bob on the 
surface, but my code is likely a bit different from Dimitrios's, so it would 
need to be changed based on what you have done. Is there a place where I can 
get your changes? Ideally, just make an experimental branch, commit it there 
and once it is tested, merge into the trunk. That is fairly easy to do with 
SVN.

 I totally agree. OceanTechnique (and thus FFTOceanSurface) already had
 getSurfaceHeight(), so I added this method as getSurfaceHeightAt() and
 added comments explaining that the former gets the average height,
 whereas the latter gets it at a specific position.

Great! That will make my life simpler. 

Regards,

Jan


signature.asc
Description: This is a digitally signed message part.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [3rdparty] How to run osgOcean

2009-10-09 Thread Jan Ciger
Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote:
 In concrete terms, I've personally tested osgOcean on nVidia cards of 
 the 7800, 7900, 8800 and 9800 lines. Realistically, I think anything 
 above 7800 should run it fine. There are even some really good deals in 
 the recent GTX 2xx line that will run it admirably well. Perhaps the 
 6x00 line might run it as well, but I haven't tested it personally. And 
 I doubt the 5x00 line and below will run it at all. Those (the 5x00s) 
 had finicky shader support IIRC.
 

I have it running on GeForce Go 7600 (laptop) and Quadro FX 4500 (GeForce 7800 
equivalent), but do not expect super high framerates on such hardware. The 
shaders are quite slow on those cards. On the other hand, my 8800GT runs it 
smoothly at 1920x1200. 

Regards,

Jan



signature.asc
Description: This is a digitally signed message part.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [3rdparty] osgOcean 1.0 (LGPL) Released

2009-10-09 Thread Jan Ciger
Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote:
 Whether or not debug is replaced by release in the absence of the debug
 versions for the COLLADA plugin, I do not know, though.
 This was the only thing I was wondering about.
 
 I was aware of all the rest. I've done my share of development on Linux 
 you know. I just use Windows at work, but I'm not for or against one or 
 the other.
 

OK, I have misunderstood then, sorry. I thought you are asking whether it is 
safe to mix release and debug on Linux. 

Regards,

Jan


signature.asc
Description: This is a digitally signed message part.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] osg::LOD range distance Coordinate System Question

2009-10-09 Thread Sean Spicer
Thanks Robert,

This is an odd corner-case I guess, I want the LODs to be selected
based upon global distance from the eye-point.  For various reasons,
onscreen size is inappropriate as a selector.  I think I can put
together a small example/patch and send it in for review.

cheers,

sean
_
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Fri, Oct 9, 2009 at 2:06 AM, Robert Osfield robert.osfi...@gmail.com wrote:
 Hi Sean,

 You are correct the range distance of LOD's are in the LOD's own local
 co-coordinate system.  This is appropriate as you almost aways want
 LOD's to scale relative to a screen size, and doing the calc in local
 coordinate allows you to decorate subgraphs with LOD's with transforms
 that scale up or down the subgraph and still have the LOD ranges
 computed appropriate for that new scaling.  This behavior is key to
 get a scene graph to be well encapsulated.

 It sounds like in your case you have transforms above your LOD's that
 scale your objects, but you still want their ranges to set in world
 coords, that ignore any transforms.  This would present the problem
 that is the transforms scale change then the LOD would choose
 different children - choosing an in-apprioriate level of detail for
 the on screen size.

 Robert.

 On Fri, Oct 9, 2009 at 5:21 AM, Sean Spicer sean.spi...@aqumin.com wrote:
 Studying the source a bit harder, I think the range-distance is
 definitely in Object (local) coordinate.  The distance calculation
 (osg::LOD.cpp) is:

 required_range = nv.getDistanceToViewPoint(getCenter(),true);

 where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp)

 (pos-getViewPointLocal()).length()*getLODScale();

 So, this raises the question: is there a good reason why there is no
 option to specify the LOD range distance in World Coordinates?  This
 would make complex LOD graphs like the one I'm working on much, much
 simpler.  Perhaps there is another method that I just do not see?

 cheers,

 sean

 On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer sean.spi...@aqumin.com wrote:

 This may be a simple question - is the LOD range distance specified in 
 object or world coordinates?  I seems as if it should be in world 
 coordinates, but I've got an example with numerous LOD nodes in sub-graphs, 
 and if I sent a constant distance range in each of them (0.0, 30.0f) so 
 that each LOD node has the same range - the LOD switch only behaves as 
 expected if the transforms above each LOD node are identical.  The moment I 
 have a scale matrix above the LOD the switch becomes dependent on the 
 scaling...e.g. larger LODs switch before smaller ones.  This leads me to 
 think that the LOD range distance is in object coordinates, and needs to be 
 scaled by the localToWorld transform.
 I've had a look at the source, and it seems logical (not to mention that 
 I'd be shocked if someone hadn't had a problem before this if it were 
 incorrect)  Comments?  Thoughts?
 cheers,
 sean
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.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] New OpenGL texture object and buffer object pool support

2009-10-09 Thread Robert Osfield
Hi Cedric,

Thanks for keep on digging into this problem.  I don't think this is a
bug in your code, rather you've just set up a set of circumstances
that the normal clean up is circumvented and an errors occurs.   If
possible we should find a way of avoid the problem in full range of
usage.

Does the little example app you provided in your email reproduce the
crash on exit?  Could we use this as a unit test?

Robert.

On Fri, Oct 9, 2009 at 1:49 PM, Cedric Pinson
cedric.pin...@plopbyte.net wrote:
 Hi again,

 ok i found my mistake and it could help other people that have a strange
 behaviour when quitting. I make a small code to reproduce the problem.
 At the end i did
 myviewer.setSceneData(0);
 in order to remove scene. With the new texture manager it produces this
 valgrind output in attached file. I did not think it was bad to do that.
 anyway if this post can save time for other people...


 #include osg/ref_ptr
 #include osgDB/ReadFile
 #include osgDB/Registry
 #include osgViewer/Viewer
 #include osg/StateSet
 #include osgText/Text
 #include osg/Texture2D

 int main(int argc, char** argv)
 {
    osg::ref_ptrosg::Group grp = new osg::Group;
    osgViewer::Viewer myviewer;
    myviewer.setSceneData(grp);

    osg::ref_ptrosg::Geode geode = new osg::Geode;
    osg::ref_ptrosgText::Text chipsText = new osgText::Text;
    std::string fontName = ../data/Vera.ttf;
    int size = 20;
    osg::Vec3 pos(0,0,0);
    osg::ref_ptrosgText::Font font =
 osgText::readFontFile(fontName.c_str());
    chipsText-setFont(font);
    chipsText-setText(blabla);
    geode-addDrawable(chipsText);
    grp-addChild(geode);

    myviewer.realize();
    myviewer.run();
    myviewer.setSceneData(0);
    return 0;
 }



 --
 +33 659 598 614  Cedric Pinson mailto:cedric.pin...@plopbyte.net
 http://www.plopbyte.net


 On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:
 Hi Robert,

 I updated to the svn trunk today, and i can notice a crash when quitting
 my application. To be sure it was with the new texture manager i defined
 USE_NEW_TEXTURE_POOL to 0 and then to 1.

 I dont have yet found the problem, but i guess it's linked with my
 texture manager, i own some static that reference texture.

 The segfault appear when quitting
 Program received signal SIGSEGV, Segmentation fault.
 #0  0xb6ef7ddf in ?? () from /lib/libc.so.6
 #1  0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
 #2  0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
 #3  0xb54f2008 in ?? ()
 #4  0xb54f2008 in ?? ()
 #5  0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
 #6  0xb6fd0bcb in ?? () from /lib/libc.so.6
 #7  0xb6fd26e8 in ?? () from /lib/libc.so.6
 #8  0xb6fcf469 in ?? () from /lib/libc.so.6
 #9  0xb6fcf442 in ?? () from /lib/libc.so.6
 #10 0xbfc68254 in ?? ()
 #11 0xa7200010 in ?? ()
 #12 0x001d in ?? ()
 #13 0x in ?? ()

 I guess there is something wrong with my texture management and the new
 texture pool.

 I continue to dig

 Cheers,
 Cedric

 --
 +33 659 598 614  Cedric Pinson mailto:cedric.pin...@plopbyte.net
 http://www.plopbyte.net


 On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote:
  Hi All,
 
  I've been pretty quiet and the public list/forum through September,
  keeping my head down developing new functionality for the OSG...  and
  the new functionality I'm pleased to announce today is that we now
  have a loverly new back-end implementation for texture objects and
  buffer objects (VertexBufferObject, ElementBufferObjects and
  PixelBufferObjects's) that provides a set of GL objects pools that
  enable recycling of both orphaned GL objects and reuse of GL objects
  that are still attached to the scene graph, but are stale - i.e.
  haven't been rendered in the last frame.
 
  The benefit the GL object pools provide is that we can scale up the
  scene graph in main memory without blowing OpenGL driver and GPU
  memory as we would do without the new pools.  This feature also
  reduces the likely-hood of thrashing of OpenGL driver and GPU memory
  so that where we might have previously seen frame drops due to memory
  management we avoid them completely or reduce there impact.  The
  memory pools will come in there own once we scale down the GPU memory
  size, such as embedded systems, or on desktop/workstation applications
  where GPU memory can be overflowed due to massive databases being kept
  in main memory.  In the later case this issue is more compounded on
  some OS's, such as Vista, that limits the amount of memory that OpenGL
  drivers can allocate, so here it should help make the app more stable
  (avoid the crashes due to out of memory errors) and faster.
 
  So... how to try out the new texture and buffer object pools?   First
  up you'll need to update to the latest OpenScenGraph svn/trunk.  Next
  you'll need to enable the pools by setting the env vars: (example
  below for bash)
 
    export OSG_TEXTURE_POOL_SIZE=1 // size in bytes (100Mb)
 

Re: [osg-users] [3rdparty] How to run osgOcean

2009-10-09 Thread Jean-Sébastien Guay

Hi Jan,

I have it running on GeForce Go 7600 (laptop) and Quadro FX 4500 (GeForce 7800 
equivalent), but do not expect super high framerates on such hardware. The 
shaders are quite slow on those cards. On the other hand, my 8800GT runs it 
smoothly at 1920x1200. 


Interesting, thanks for the additional data. I'll look about starting 
that wiki page soon.


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] [3rdparty] osgOcean collision detection

2009-10-09 Thread Jean-Sébastien Guay

Hi Jan,

Right, of course. I have a bit of code that makes an object bob on the 
surface, but my code is likely a bit different from Dimitrios's, so it would 
need to be changed based on what you have done.


Likely it's just the method name that would change. I don't mind doing that.

Is there a place where I can 
get your changes? Ideally, just make an experimental branch, commit it there 
and once it is tested, merge into the trunk. That is fairly easy to do with 
SVN.


I'll try to get that done before the end of the day.

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] Texture missing when adding slaves dynamically to osgViewer

2009-10-09 Thread Drolet, Frederic
Hello,

I tried with Texture::setUnRefImageDataAfterApply(false) and it works well. 
However, as I read about this, texture memory is now duplicated (once in OpenGL 
and once in OSG). Isn't there a way to do the same thing in OpenGL by sharing 
the contexts or something like that? As I said, I tried to share a single 
context in the traits configuration but it didn't work. For now, our 
application doesn't use too much memory but this could become a problem when 
we'll be generating visual data from our database!

As for the osgUtil::Optimizer, we're not using it anywhere in our code... Is it 
called by the Viewer class during initialization or something?

Would there be another way to enable texture sharing for dynamically created 
rendering contexts while optimizing memory usage?

Thanks again for your help!

Frédéric Drolet


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: October-08-09 5:01 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Texture missing when adding slaves dynamically 
toosgViewer

Hi Frederic,

If you are creating new graphics contexts and applying and old scene
graph to it then you can't use the
Texture::setUnRefImageDataAfterApply(true) feature of osg::Texture as
this will discard the imagery once it's applied to all the graphics
contexts that it knows about.  By default the osgUtil::Optimizer will
switch this on to save memory, so try not calling the Optimizer to see
if makes a difference.  It's possible that the original database also
has this options set, but for most databases it'll be off, which is
the default.

Robert.

On Thu, Oct 8, 2009 at 8:21 PM, Drolet, Frederic
frederic.dro...@drdc-rddc.gc.ca wrote:
 Hello,



 I'm having trouble with textures on slave cameras added to an osgViewer.
 Textures won't appear if I add the slaves after a first call to
 osgViewer::frame().



 My application is composed of a rendering thread calling osgViewer::frame()
 every 15 ms (for a 60 Hz framerate) and a main thread handling windows and
 menus interactions (using MFC on Windows). One of those interactions is to
 add and remove camera slaves on the go (adding a projection and camera
 offset for multiple points of view). Here's the steps I follow to add a
 slave camera:



 · Pause my rendering thread calling osgViewer::frame() and wait for
 it to be idle;

 · Call osgViewer::stopThreading() to make sure the last frame is
 done drawing;

 · Create a child window with its own graphics context;

 · Add a slave to osgViewer using the newly created window handle
 (each slave camera uses its own osg::GraphicsContext object);

 · Call osgViewer::realize() to reinitialize the viewer and start
 threading again;

 · Unpause my rendring thread which starts calling osgViewer::frame()
 again.



 I use a similar approach to destroy slaves. Everything works fine except for
 the textures which are not displayed on the slave windows (but I can see the
 primitives).



 Note that if I add slaves before the first call to osgViewer::frame(),
 textures are ok. But removing and adding them again makes the textures
 disappear.



 I tried all the threading models in osgViewer, I also tried to share the
 master context in the osg::GraphicsContext::Traits object of every slave.
 None of those solutions is working. My comprehension of OpenGL state sets is
 limited so I'm probably missing something here.



 What am I doing wrong? Is adding slaves dynamically to an osgViewer even
 possible?



 Thanks for your help!



 Frederic Drolet, M. Sc.

 Computing Solutions and Experimentations | Solutions informatiques et
 expérimentations

 Systems of Systems | Systèmes de systèmes

 DRDC Valcartier | RDDC Valcartier

 2459, boul. Pie-XI North

 Quebec, Quebec

 G3J 1X5 CANADA

 Phone | Téléphone: (418) 844-4000 ext : 4820

 Fax | Télécopieur: (418) 844-4538

 E-mail | Courriel: frederic.dro...@drdc-rddc.gc.ca

 Web : www.valcartier.drdc-rddc.gc.ca

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.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] Texture missing when adding slaves dynamically to osgViewer

2009-10-09 Thread Robert Osfield
Hi Frederic,

 I tried with Texture::setUnRefImageDataAfterApply(false) and it works well. 
 However, as I read about this, texture memory is now duplicated (once in 
 OpenGL and once in OSG). Isn't there a way to do the same thing in OpenGL by 
 sharing the contexts or something like that? As I said, I tried to share a 
 single context in the traits configuration but it didn't work. For now, our 
 application doesn't use too much memory but this could become a problem when 
 we'll be generating visual data from our database!

It's possible to share contexts in the OSG, I have no clue as to why
it hasn't worked in your case, there is just too many unknowns -  you
have your code, I don't so you're the only one really in a position to
debug it.

As for general desirability of share GL objects between contexts, yes
it can reduce memory usage, but it forces you to use the OSG single
threaded otherwise two contexts will be contended for the same
resources that deliberately aren't mutex locked for performance
reasons.   There is also on a limited set of cases where
drivers/hardware will actually share OpenGL contexts.

 As for the osgUtil::Optimizer, we're not using it anywhere in our code... Is 
 it called by the Viewer class during initialization or something?

The Viewer doesn't run the Optimizer.  Some plugins run it on their
own data though.

 Would there be another way to enable texture sharing for dynamically created 
 rendering contexts while optimizing memory usage?

?? Sounds a bit like a magic wand. OpenGL only allows you to share all
OpenGL objects or none, you don't get to share some.

If you want to tightly manage the OpenGL memory footprint then the new
texture + buffer object pool is what you'll want to use.

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


Re: [osg-users] [3rdparty] How to run osgOcean

2009-10-09 Thread Jean-Sébastien Guay

Hi again,


I'll look about starting that wiki page soon.


Here you go,

http://code.google.com/p/osgocean/wiki/HarwareSupport

I'll add details as time passes...

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] New OpenGL texture object and buffer object pool support

2009-10-09 Thread Cedric Pinson
Hi Robert,

Yes you will be able to reproduce the valgrind output with the the code
sample in the email.

Cheers,
Cedric

-- 
+33 659 598 614  Cedric Pinson mailto:cedric.pin...@plopbyte.net
http://www.plopbyte.net


On Fri, 2009-10-09 at 14:24 +0100, Robert Osfield wrote:
 Hi Cedric,
 
 Thanks for keep on digging into this problem.  I don't think this is a
 bug in your code, rather you've just set up a set of circumstances
 that the normal clean up is circumvented and an errors occurs.   If
 possible we should find a way of avoid the problem in full range of
 usage.
 
 Does the little example app you provided in your email reproduce the
 crash on exit?  Could we use this as a unit test?
 
 Robert.
 
 On Fri, Oct 9, 2009 at 1:49 PM, Cedric Pinson
 cedric.pin...@plopbyte.net wrote:
  Hi again,
 
  ok i found my mistake and it could help other people that have a strange
  behaviour when quitting. I make a small code to reproduce the problem.
  At the end i did
  myviewer.setSceneData(0);
  in order to remove scene. With the new texture manager it produces this
  valgrind output in attached file. I did not think it was bad to do that.
  anyway if this post can save time for other people...
 
 
  #include osg/ref_ptr
  #include osgDB/ReadFile
  #include osgDB/Registry
  #include osgViewer/Viewer
  #include osg/StateSet
  #include osgText/Text
  #include osg/Texture2D
 
  int main(int argc, char** argv)
  {
 osg::ref_ptrosg::Group grp = new osg::Group;
 osgViewer::Viewer myviewer;
 myviewer.setSceneData(grp);
 
 osg::ref_ptrosg::Geode geode = new osg::Geode;
 osg::ref_ptrosgText::Text chipsText = new osgText::Text;
 std::string fontName = ../data/Vera.ttf;
 int size = 20;
 osg::Vec3 pos(0,0,0);
 osg::ref_ptrosgText::Font font =
  osgText::readFontFile(fontName.c_str());
 chipsText-setFont(font);
 chipsText-setText(blabla);
 geode-addDrawable(chipsText);
 grp-addChild(geode);
 
 myviewer.realize();
 myviewer.run();
 myviewer.setSceneData(0);
 return 0;
  }
 
 
 
  --
  +33 659 598 614  Cedric Pinson mailto:cedric.pin...@plopbyte.net
  http://www.plopbyte.net
 
 
  On Thu, 2009-10-08 at 15:22 +0200, Cedric Pinson wrote:
  Hi Robert,
 
  I updated to the svn trunk today, and i can notice a crash when quitting
  my application. To be sure it was with the new texture manager i defined
  USE_NEW_TEXTURE_POOL to 0 and then to 1.
 
  I dont have yet found the problem, but i guess it's linked with my
  texture manager, i own some static that reference texture.
 
  The segfault appear when quitting
  Program received signal SIGSEGV, Segmentation fault.
  #0  0xb6ef7ddf in ?? () from /lib/libc.so.6
  #1  0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
  #2  0xb5dddc40 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
  #3  0xb54f2008 in ?? ()
  #4  0xb54f2008 in ?? ()
  #5  0xb6193d60 in ?? () from //usr//lib/opengl/nvidia/lib/libGLcore.so.1
  #6  0xb6fd0bcb in ?? () from /lib/libc.so.6
  #7  0xb6fd26e8 in ?? () from /lib/libc.so.6
  #8  0xb6fcf469 in ?? () from /lib/libc.so.6
  #9  0xb6fcf442 in ?? () from /lib/libc.so.6
  #10 0xbfc68254 in ?? ()
  #11 0xa7200010 in ?? ()
  #12 0x001d in ?? ()
  #13 0x in ?? ()
 
  I guess there is something wrong with my texture management and the new
  texture pool.
 
  I continue to dig
 
  Cheers,
  Cedric
 
  --
  +33 659 598 614  Cedric Pinson mailto:cedric.pin...@plopbyte.net
  http://www.plopbyte.net
 
 
  On Fri, 2009-10-02 at 22:21 +0100, Robert Osfield wrote:
   Hi All,
  
   I've been pretty quiet and the public list/forum through September,
   keeping my head down developing new functionality for the OSG...  and
   the new functionality I'm pleased to announce today is that we now
   have a loverly new back-end implementation for texture objects and
   buffer objects (VertexBufferObject, ElementBufferObjects and
   PixelBufferObjects's) that provides a set of GL objects pools that
   enable recycling of both orphaned GL objects and reuse of GL objects
   that are still attached to the scene graph, but are stale - i.e.
   haven't been rendered in the last frame.
  
   The benefit the GL object pools provide is that we can scale up the
   scene graph in main memory without blowing OpenGL driver and GPU
   memory as we would do without the new pools.  This feature also
   reduces the likely-hood of thrashing of OpenGL driver and GPU memory
   so that where we might have previously seen frame drops due to memory
   management we avoid them completely or reduce there impact.  The
   memory pools will come in there own once we scale down the GPU memory
   size, such as embedded systems, or on desktop/workstation applications
   where GPU memory can be overflowed due to massive databases being kept
   in main memory.  In the later case this issue is more compounded on
   some OS's, such as Vista, that limits the amount of memory that OpenGL
   drivers can allocate, so here 

[osg-users] memory leak in osg 2.8.2 ?

2009-10-09 Thread Sebastien Nerig
Hi,

I take an osg example (I tried with the osgTeapot example project), then I add 
the command

Code:
viewer.run();
_CrtDumpMemoryLeaks();
return 0;

 at the end of the main function. (it dumps all the memory blocks in the debug 
heap when a memory leak has occurred)
I launch it in debug mode, then I stop the application (ESC key) and I have 
many memory leaks in my output debug window.


 Detected memory leaks!
 Dumping objects -
 {21998} normal block at 0x01D633D0, 4 bytes long.
  Data: P   50 3E D4 01 
 {21997} normal block at 0x01D48750, 20 bytes long.
  Data: hs  (   hs   68 73 D2 01 28 DE D2 01 68 73 D2 01 08 FA E3 05 
 {21996} normal block at 0x01D48568, 184 bytes long.
  Data:  q]  B8 71 5D 01 00 00 00 00 01 00 00 00 00 00 00 00 
 {21995} normal block at 0x01D34998, 4 bytes long.
  Data: h68 03 D3 01
 .. 


Where do they come from ? I tried other example and it is the same.
I use VisualC++ 2008, osg 2.8.2, on windows

Thank you!

Cheers,
Sebastien

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





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


[osg-users] Neil Vass is out of the office.

2009-10-09 Thread Neil . Vass

I will be out of the office starting  09/10/2009 and will not return until
12/10/2009.

I will respond to your message when I return. For urgent matters, contact
the Warrington office - 01925 286 800.

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


Re: [osg-users] [3rdparty] osgOcean collision detection

2009-10-09 Thread Jan Ciger
Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote:
  Is there a place where I can
  get your changes? Ideally, just make an experimental branch, commit it
  there and once it is tested, merge into the trunk. That is fairly easy to
  do with SVN.
 
 I'll try to get that done before the end of the day.
 

Just drop me an e-mail off-list and I can send you a simple hack for testing it 
- e.g. a buoy bobbing on the water surface or something similar.

Regard, 

Jan


signature.asc
Description: This is a digitally signed message part.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] [3rdparty] How to run osgOcean

2009-10-09 Thread Jean-Sébastien Guay

Hi Kim,


http://code.google.com/p/osgocean/wiki/HardwareSupport


Heh, did I actually make a typo in the page title? Geez... Sorry, I was 
in a hurry and didn't notice it.


Thanks for your vigilance.

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] How to use ImageSequence?

2009-10-09 Thread Ulrich Hertlein

On 9/10/09 5:01 PM, stefan nortd wrote:

I am trying to use the osg::ImageSequence without much result. Maybe
  somebody can point me in the right direction.


Did you look at osgimagesequence.cpp?


I am creating the ImageSequence object, use addImageFile(...) to
populate at and then try to assign it to a texture for drawing. Then nothing
shows up.


Did you set a length?  Is it playing?


I feel like I am not quite grasping the idea behind ImageSequence. For
one, how does the texture know when to reload the next image from the
sequence. Is this all implicitly done or do I have to I miss something
about this.


ImageSequence is updated perodically which changes the internal image (based on runtime, 
playback speed, play mode).  This change is picked up by Texture (through the ImageStream 
interface).


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


Re: [osg-users] SVN commit bottleneck

2009-10-09 Thread Chris 'Xenon' Hanson
Chris 'Xenon' Hanson wrote:
   I don't think I'm qualified to nominate myself for this right now.
   However, I'm wondering who does have SVN commit access, and if one of these 
 people is
 willing to accept interim changes? I have several finished changes ready to 
 check in, and
 I worry about them getting stale. With concurrent development, other people 
 could
 potentially get conflicted with my changes and make more messy work for down 
 the road than
 inf they had my changes to start from. Likewise, I dislike submitting more 
 than one
 change at a time -- for example, I revised Vec3d for a particular purpose. 
 I would like
 to get that in with the purpose/explanation before I make any new changes to 
 Vec3d for a
 different purpose -- that way the SVN commit chain of evidence is clear that 
 this one
 checking serves on single purpose.
   Is anyone else willing to accept, screen and integrate SVN changes right 
 now?

  It seems like we don't have any capacity in this regard right now. I'll 
shorten the
question -- other than Robert, who does have SVN commit access?

  Historically, one of my roles in the OSG community has been to point out the 
emperor
has no clothes moments when we finally acknowledge we're again putting too much
responsibility onto Robert, and call for new ways to shave some non-critical 
roles off his
shoulders.

  Previously this has been the impetus for the separate submissions list, the 
Wiki, the
Spelling Bee, and some others.

  I'm wondering if Robert's request for outside assistance here is the time for 
some of
the community to step up to the plate and contribute more effort to the 
administration of
the project's source.

  Are there others out here who have successfully been involved in the source 
repository
or other significant FOSS projects? Maybe with experience with code review?

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] is the osg inventor loader broken?

2009-10-09 Thread John Kelso

Hi,

We're running 2.8.2 on a 64-bit Centos system.  OSG was configured to use
Coin-3.1.1.

Not too long ago I ran an old demo using the new releases and noticed that
an Inventor file that used to load properly no longer did.  Checking around,
many others also didn't.

Here's a simple example file that demonstrates the problem:

  #Inventor V2.0 ascii
  Material { diffuseColor 1 0 0 }
  Cone { bottomRadius 1 height 2 }

  Rotation { rotation 1 0 0 3.14159 }
  Material { diffuseColor 0 1 0  }
  Cone { bottomRadius 1 height 2 }

If you look at this with ivview, also linked with Coin-3.1.1, you see two
intersecting cones, red on the bottom and green on the top.

If you load this same file with osgviewer you just see the red cone.

If you use osgconv to create an osg file from the iv file you see both cones
in the osg file with identical vertex data and the green one isn't rotated.
I'm surprised I don't see any z-fighting in osgviewer.

Anyway, can anyone else try loading this Inventor file and see if it works
for them?

Many thanks,

John



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


Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?

2009-10-09 Thread sergey leontyev
Robert,
I tried the 2.9 trunk code with.
osg::DisplaySettings::instance()-setMaxTexturePoolSize(1);
osg::DisplaySettings::instance()-setMaxBufferObjectPoolSize(2);

The problem still exists. As memory usage was growing and growing. I just left 
the computer running and observed the linear memory consumption growth.



Thanks
Sergey

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





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


Re: [osg-users] SVN commit bottleneck

2009-10-09 Thread Jean-Sébastien Guay

Hi Chris,


  It seems like we don't have any capacity in this regard right now. I'll 
shorten the
question -- other than Robert, who does have SVN commit access?


Well, I think you've been with us for a while now, so you must have some 
idea about this. It seems to me that whenever commit rights are given to 
others, it's been for specialist duties. For example:


- Maintenance of update branches (for example maintenance of the 2.6.x 
branch after 2.6.0 was done by Robert)
- Development and maintenance of specific branches and parts of OSG (for 
example, the osgAnimation branch, the XCode projects, etc.)


But no one has had commit access to the SVN repo as a whole except 
Robert. On one hand I can understand a certain desire to keep the core 
under control, but I think a good part of commits (maybe upwards of 80%) 
could be done by other people, since they're either easily verifiable 
bug fixes or changes to non-critical parts of OSG (i.e. anything other 
than the rendering backend).



  I'm wondering if Robert's request for outside assistance here is the time for 
some of
the community to step up to the plate and contribute more effort to the 
administration of
the project's source.


I agree that, on one hand, people could volunteer, but historically 
Robert has been reluctant to give commit rights, preferring to review 
submissions himself. Instead, he told them to focus on other things like 
improving documentation, the wiki, answering more questions on the 
mailing list, etc. So it's understandable that if, in the past, people 
volunteered only to be told that it wouldn't happen, they're reluctant 
to volunteer now.


I don't want to speak for him of course, just replying from what I 
remember since he hasn't done so himself yet.


I would gladly volunteer but I have little time to devote to the task. I 
wouldn't want to say I'll help with submissions only to hold them up 
myself... Perhaps in the future I'll be able to, but right now I can't.


Anyways, I agree with your point that the management of submissions 
needs to be decentralized. The bus factor on OSG (at least on commits 
to SVN) is too low...


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] Restoring a Viewer's MatrixManipulator

2009-10-09 Thread Shiina Ringo
Hi,Phil 

I just have met the same problem , like the  switching of 2 MatrixManipulators 
, that the home position is not the position which is like the default position.

I just look forward to anyone could give some advice.

Thank you very much!

Cheers,
Shiina

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





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


[osg-users] Question about switching between MatrixManipulator

2009-10-09 Thread Shiina Ringo
Hi,

Here just a quetion confused me:

I have a KeySwitchMatrixManipulator , which served as a swithcer between 2 
MatrixManipulator : a default Trackball and a MatrixManipulator that I 
defined(bounding to a object) . 
The problem is : when I hit the button to switch the above 
MatrixManipulator , especially when I switch the MatrixManipulator that I 
defined to the Trackball MatrixManipulator  , the view point cannot come back 
to the default position when the application initiated , and I have to hit the 
spacebar in order to let the view back to the default positon.
In all , Is there a  method that could let the view point came back to its 
default position when using the Trackball MatrixManipulator?

Could anyone give me some advice about this problem?

Thank you very much!

Cheers,
Shiina

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





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