Re: [osg-users] Linking error : OpenThread

2008-09-05 Thread Mathias Fröhlich

Hi,

On Thursday 04 September 2008 23:23, Rahul Jain wrote:
 While compiling my application with OSG2.6 I am getting following
 linking error  *undefined reference to
 `OpenThreads::Atomic::operator--()*. The same application is linked
 properly with OSG2.4.  Since i am not using Atomic operation in my
 application, i  am not able to find the reason for failure.Any guesses ?

May be you need to link your application to libOpenThreads also?
You use the Atomic stuff when you have any ref_ptr inline in your code ...

Greetings

Mathias

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


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


Re: [osg-users] osgmultiplerendertargets

2008-09-05 Thread J.P. Delport

Hi,

no, you don't need cmline args. With just the command you should see a 
yellow square.


I have not compiled 2.6. I have 2.5.3 here and it works (Debian Sid, 
NVidia 7400 Go).


You could also try:
osgmultiplerendertargets --image
and
osgmultiplerendertargets --hdr

but they prob won't work if the simple one does not.

I know there have been some changes wrt multisample FBO's, not sure if 
that could cause trouble.


I'm also not sure if there are proper checking for MRT capabilities in 
the example. The example assumes it can use 4 render targets.


jp

[EMAIL PROTECTED] wrote:

I'm getting a segmentation fault when running the osgmultiplerendertargets 
example using OSG 2.6 under Linux.The call stack says its in 
RenderStage::runCameraSetUp. My OSG isn't currently compiled debug. Am I doing 
something wrong? Do I need command line arguments?

Paul P


  
___

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] adaptation of chunkLOD to OSG

2008-09-05 Thread Alberto Luaces
Just a little remark: isn't the cockpit supposed to read FUEL FLOW instead 
of FLUEL FLOW? :)


 originally someone did a test with photo realistic terrain.
 video (40s):
 High resolution (26 Mo)
 http://documents.cigognes.net/csp/csp-terrain-photo.avi Low resolution
 (YouTube) http://fr.youtube.com/watch?v=1NlZoylXrlo




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


Re: [osg-users] Using Kd-tree for spatial data

2008-09-05 Thread Alberto Luaces
Hi,

it's already done for you. Just use the osg::KdTreeBuilder visitor on the 
subgraph you want to be split with kd-trees.

Alberto

El Jueves 04 Septiembre 2008ES 19:15:21 maruti borker escribió:
 Thanks for pointing out , i looked into the discussion and i think the
 current setupd with kd-trees wont help me with my idea. Can anyone point me
 to some tool/project which creates just the kd-tree ( near to optimal )
 given a 3d scene . Any help would be appreciated.

 Thanks

 Maruti Borker
 IIIT Hyderabad
 Website:- http://students.iiit.ac.in/~maruti
 Blog:- http://marutiborker.wordpress.com

 On Thu, Sep 4, 2008 at 3:00 PM, Robert Osfield 
[EMAIL PROTECTED]wrote:
  HI Maruti,
 
  Lots was discussed on osg-users about the KdTree implementation in the
  OSG when I intergrated the functionality, so have a look through the
  osg-users archives in June and July.   The quick answer is that
  KdTree's hang off Drawables, and when do intersection testing first
  coarsed grained culling is done by the scene graphs hierachy of
  bounding spheres/boxes, then finally fine grained testing is done
  against the KdTree hanging of the drawables.
 
  Robert.
 
  On Thu, Sep 4, 2008 at 7:27 AM, maruti borker [EMAIL PROTECTED]
 
  wrote:
   Hello,
  I was amazed to see the development  OSG has made,
   the last version i used it was 2.3.4. Coming to the topic,  i wanted to
   know
 
  how
 
   a scenegraph was being linked to a kd-tree for finding out
   intersections.
 
  I
 
   am thinking of an application which needs querying of spatial data, for
   which i thought of using kd-trees , but i also thought of having a
   scenegraph for rendering purposes. I looked at a work Razor:
   Multi-resolution ray tracing for dynamic environments by William mark
 
   and
 
   Warren hunt. They also lazily linked a scene-graoh and a kd-tree. I
 
  wanted
 
   to know how the kd-tree is being linked to a scenegraph in OSG and also
   whether i could actually access the kd-tree for performing algorithms
   on
 
  top
 
   of it. And also an advice whether using this linkage in OSG is useful
   for storing spatial data. Do mail back incase of any doubts or
   clarifications
 
  .
 
   Maruti Borker
   IIIT Hyderabad
   Website:-
   http://students.iiit.ac.in/~marutihttp://students.iiit.ac.in/%7Emaruti
   Blog:- http://marutiborker.wordpress.com
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
 
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] adaptation of chunkLOD to OSG

2008-09-05 Thread [EMAIL PROTECTED]

LOL, yes you are right, i never saw that.

thank you for finding the failure. :)

Alberto Luaces wrote:
Just a little remark: isn't the cockpit supposed to read FUEL FLOW instead 
of FLUEL FLOW? :)




originally someone did a test with photo realistic terrain.
video (40s):
High resolution (26 Mo)
http://documents.cigognes.net/csp/csp-terrain-photo.avi Low resolution
(YouTube) http://fr.youtube.com/watch?v=1NlZoylXrlo





___
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] osgFX::BumpMapping

2008-09-05 Thread Robert Osfield
Hi Alex,

I'm afraid you'll need to move to the dev release 2.7.2 or svn/trunk
to get .ive support for osgFX::BumpMapping.

Robert.

On Thu, Sep 4, 2008 at 10:48 PM, Pecoraro, Alexander N
[EMAIL PROTECTED] wrote:
 Is it possible to write osgFX::BumpMapping nodes to an ive file? I noticed
 in OSG 2.4 and 2.5 there seems to be some code for writing it to .osg, but
 not .ive. I also noticed that in the OSG trunk on SVN there appears to be
 some code for writing it to ive, but I was hoping to be able to use a
 released version. I figured since it appears the osgFX::BumpMapping just
 uses built in OSG nodes that it would be able to write out the OSG nodes
 that are created by osgFX::BumpMapping. Is that the case?



 Thanks.



 Alex

 ___
 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] Using Kd-tree for spatial data

2008-09-05 Thread maruti borker
But when i went through the discussion, i found out that only geomety in the
leaves have seperate kd-tree and not a single kd-tree for the whole scene.
Correct me if i am wrong.


Maruti Borker
IIIT Hyderabad
Website:- http://students.iiit.ac.in/~maruti
Blog:- http://marutiborker.wordpress.com


On Fri, Sep 5, 2008 at 1:10 PM, Alberto Luaces [EMAIL PROTECTED] wrote:

 Hi,

 it's already done for you. Just use the osg::KdTreeBuilder visitor on the
 subgraph you want to be split with kd-trees.

 Alberto

 El Jueves 04 Septiembre 2008ES 19:15:21 maruti borker escribió:
  Thanks for pointing out , i looked into the discussion and i think the
  current setupd with kd-trees wont help me with my idea. Can anyone point
 me
  to some tool/project which creates just the kd-tree ( near to optimal )
  given a 3d scene . Any help would be appreciated.
 
  Thanks
 
  Maruti Borker
  IIIT Hyderabad
  Website:- 
  http://students.iiit.ac.in/~marutihttp://students.iiit.ac.in/%7Emaruti
  Blog:- http://marutiborker.wordpress.com
 
  On Thu, Sep 4, 2008 at 3:00 PM, Robert Osfield
 [EMAIL PROTECTED]wrote:
   HI Maruti,
  
   Lots was discussed on osg-users about the KdTree implementation in the
   OSG when I intergrated the functionality, so have a look through the
   osg-users archives in June and July.   The quick answer is that
   KdTree's hang off Drawables, and when do intersection testing first
   coarsed grained culling is done by the scene graphs hierachy of
   bounding spheres/boxes, then finally fine grained testing is done
   against the KdTree hanging of the drawables.
  
   Robert.
  
   On Thu, Sep 4, 2008 at 7:27 AM, maruti borker 
 [EMAIL PROTECTED]
  
   wrote:
Hello,
   I was amazed to see the development  OSG has made,
the last version i used it was 2.3.4. Coming to the topic,  i wanted
 to
know
  
   how
  
a scenegraph was being linked to a kd-tree for finding out
intersections.
  
   I
  
am thinking of an application which needs querying of spatial data,
 for
which i thought of using kd-trees , but i also thought of having a
scenegraph for rendering purposes. I looked at a work Razor:
Multi-resolution ray tracing for dynamic environments by William
 mark
  
and
  
Warren hunt. They also lazily linked a scene-graoh and a kd-tree. I
  
   wanted
  
to know how the kd-tree is being linked to a scenegraph in OSG and
 also
whether i could actually access the kd-tree for performing algorithms
on
  
   top
  
of it. And also an advice whether using this linkage in OSG is useful
for storing spatial data. Do mail back incase of any doubts or
clarifications
  
   .
  
Maruti Borker
IIIT Hyderabad
Website:-
http://students.iiit.ac.in/~marutihttp://students.iiit.ac.in/%7Emaruti
 http://students.iiit.ac.in/%7Emaruti
Blog:- http://marutiborker.wordpress.com
   
___
osg-users mailing list
osg-users@lists.openscenegraph.org
  
  
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

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


Re: [osg-users] Movie texture on poly

2008-09-05 Thread Robert Osfield
Hi Patrick,

I presume you have quicktime installed and compiled the OSG's qt
plugin on on your system, you make may no mention if you've done this
or if what system you are working on.  Quicktime is requied for Mpeg4
files, but only available under OSX and Windows.  Under Linux you'll
need to to you the xine-lib plugin, but xine-lib doesn't yet support
mpeg4 as far as I'm aware.

Robert.

On Fri, Sep 5, 2008 at 1:26 AM, Patrick A. Webb [EMAIL PROTECTED] wrote:
 Hello, I'm trying to use osgviewer to display some models created in
 Blender, and use animated textures (MPEG4 movies or even animated GIFs) on
 those models.

 I've read through the archives and found mention of replacing the texture
 file name in the .osg file with the name of the movie that's going to be the
 animated texture, but I've had no luck getting the texture to actually
 animate.

 Does anyone have an example .osg file and an associated movie that
 worktogether to play an animated texture on a polygon?

 Thanks in advance for any help.

 -Patrick Webb
 ___
 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 using shoreline / borders vector data to determine alpha

2008-09-05 Thread Robert Osfield
Hi Ralf,

Doing this is feasible, but it's quite a bit of work, and certainly
not something that will be in the VPB-1.0 release.

Longer term I'd like to see osgTerrain supporting boundary polygons,
and runtime tessellation against these, then VPB would then just need
to cut the boundaries up into tiles and then export them with the
tiles and leave the tessllation up to osgTerrain.

Robert.

On Fri, Sep 5, 2008 at 6:33 AM, Ralf Stokholm [EMAIL PROTECTED] wrote:
 Hi Robert /List

 Would an option to use a shapefile containing ie. water bodies or borders to
 set the transparency of a terrain layer be feaseble?

 For my application it would be nice to use border vector data to eleminate
 data from one dataset and blend into another.

 It should also be relatively easy to extend a terrain with some nice looking
 ocean effects if the terrain would simply alphablen into the warter surface
 as determined by a shoreline shapefile?

 What are your thourghts on this?

 Brgs.

 Ralf Stokholm
 ___
 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] osgmultiplerendertargets

2008-09-05 Thread Robert Osfield
Hi Paul,

I have just tried osgmultiplerendertargets on my quad core system and
it runs fine (svn/trunk) but there has been no fixes since 2.6 that
would effects things.

What hardware/OS setup do you have?

Robert.

On Thu, Sep 4, 2008 at 6:35 PM,  [EMAIL PROTECTED] wrote:
 I'm getting a segmentation fault when running the osgmultiplerendertargets 
 example using OSG 2.6 under Linux.The call stack says its in 
 RenderStage::runCameraSetUp. My OSG isn't currently compiled debug. Am I 
 doing something wrong? Do I need command line arguments?

 Paul P



 ___
 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] Using Kd-tree for spatial data

2008-09-05 Thread Robert Osfield
HI Maruti,

On Fri, Sep 5, 2008 at 9:11 AM, maruti borker [EMAIL PROTECTED] wrote:
 But when i went through the discussion, i found out that only geomety in the
 leaves have seperate kd-tree and not a single kd-tree for the whole scene.
 Correct me if i am wrong.

The use of KdTree on drawable leaves only is done to provide a good
balance between efficiency of intersection test and flexibility.  For
instance the system we have now handles whole scene with moving parts,
if you had a single KdTree you'd need to recompute it all the time.
Also a well balanced scene graph will be spatially distributed so will
the hierarchical bounding volumes that help intersection tests.

Jumping to KdTree for the whole scene graph is technically possible,
but you'll need to build the KdTree yourself, and in terms of
performance vs flexibility tradeoff's is not good, it's a lot of
effort for little gain in performance.

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


Re: [osg-users] adaptation of chunkLOD to OSG

2008-09-05 Thread Robert Osfield
Hi Hannes,

On Thu, Sep 4, 2008 at 8:36 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 with VirtualPlanetBuilder you mean
 http://www.openscenegraph.org/projects/VirtualPlanetBuilder
 with VTP you mean http://www.vterrain.org/
 i did not find anything about VTB, is it a mistyped VTP?

It's a typo - VTB should be VPB i.e. VirtualPlanetBuilder.

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


Re: [osg-users] Using Kd-tree for spatial data

2008-09-05 Thread maruti borker
Hi ,
  I understood your point. That is why i said that the kd-tree
implemented in OSG wont be useful for my purpose. I just wanted to know if
there are any tools/code which creates a single kd-tree of the whole scene.

Regards,

Maruti Borker
IIIT Hyderabad
Website:- http://students.iiit.ac.in/~maruti
Blog:- http://marutiborker.wordpress.com


On Fri, Sep 5, 2008 at 1:52 PM, Robert Osfield [EMAIL PROTECTED]wrote:

 HI Maruti,

 On Fri, Sep 5, 2008 at 9:11 AM, maruti borker [EMAIL PROTECTED]
 wrote:
  But when i went through the discussion, i found out that only geomety in
 the
  leaves have seperate kd-tree and not a single kd-tree for the whole
 scene.
  Correct me if i am wrong.

 The use of KdTree on drawable leaves only is done to provide a good
 balance between efficiency of intersection test and flexibility.  For
 instance the system we have now handles whole scene with moving parts,
 if you had a single KdTree you'd need to recompute it all the time.
 Also a well balanced scene graph will be spatially distributed so will
 the hierarchical bounding volumes that help intersection tests.

 Jumping to KdTree for the whole scene graph is technically possible,
 but you'll need to build the KdTree yourself, and in terms of
 performance vs flexibility tradeoff's is not good, it's a lot of
 effort for little gain in performance.

 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] scene graph access in multithreaded mode

2008-09-05 Thread Tugkan Calapoglu

Hi Robert,


Hi Tugkan,

On Wed, Sep 3, 2008 at 9:56 AM, Tugkan Calapoglu [EMAIL PROTECTED] wrote:


I am porting an application from OSG0.99 to latest SVN version.



Wow, climb aboard the time machine :-)


I know :). We never had the time slot for the upgrade until now.

I have implemented the changes you suggested and it seems to work, no 
random crashed anymore in CullThreadPerCameraDrawThreadPerContext mode.


Thanks for the help,
tugkan







I have two
questions (both for CullThreadPerCameraDrawThreadPerContext mode):

1- Is it safe to make changes in the scene graph outside the frame call
(without using update etc. callbacks )? Or is the only place where we have
safe scene graph acess is inside a callback? Mailing list and source code
reading made me think that outside the frame() should be safe but I am
getting some crashes. Before delving into my own code I'd like that someone
confirms this.



Modifying the scene graph outside of the frame call is safe in
SingleThreader, and CullDrawThreadPerCamera threading models as they
don't leave any threads active after the end of the
renderingTraversals() method (called from frame()).

With DrawThreadPerContext and CullThreadPerCamewraDrawThreadPerContext
the draw threads will still be active on completion of the
renderingTraversals(), so if you modifying drawables and state that
the thread is still reading from in the draw traversal you will end up
with problems - and potential crashes.  There is a standard mechanism
to deal with this issue - and that is the renderingTraversals() method
to block till all dynamic objects in the draw traversals have been
dispatched.  The way you tell the draw traversal that an drawable or
stateset will be modified dynamically is to set its data variance to
DYNAMIC.

   drawable-setDataVariance(osg::Object::DYNAMIC);
   stateset-setDataVariance(osg::Object::DYNAMIC);

This is mentioned in the Quick Start Guide book, as well as many
times on the osg-users mailing list so have a look through the
archives if you want more background reading.




2- Is it ok to change the global state set during rendering outside frame
call? I have following code runing before frame() is called :

osg::Camera* cam = getViewer()-getView(i)-getCamera();
cam-getOrCreateStateSet()-clear();
cam-getOrCreateStateSet()-setGlobalDefaults();
... And some other changes ...



Same requirement - if you are modifying the stateset then you'll need
to set its data variance to DYNAMIC.  For a StateSet that decorates
the whole scene graph you'll end you holding back the frame till the
whole scene graph is completed, so it won't have any performance
advantage over CullDrawThreadPerContext.  You can double buffer
objects to allow you to retain the STATIC data variance and keep the
threads overlapping, to do this you do:

osg::Camera* cam = getViewer()-getView(i)-getCamera();
cam-setStateSet() = new StateSet;  // this is where we just use a new
StateSet rather than modify the previous one
cam-getOrCreateStateSet()-setGlobalDefaults();
... And some other changes ...

The draw traversal takes a reference to the StateSet and Drawables so
it's safe to go an remove them from the scene graph outside the
frame() call, this isn't something makes then dynamic so you won't
need to set their data variance to DYNAMIC.

Robert.


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




--
Tugkan Calapoglu

-
VIRES Simulationstechnologie GmbH
Oberaustrasse 34
83026 Rosenheim
Germany
phone+49.8031.463641
fax  +49.8031.463645
email[EMAIL PROTECTED]
internet www.vires.com
-
Sitz der Gesellschaft: Rosenheim
Handelsregister Traunstein  HRB 10410
Geschaeftsfuehrer: Marius Dupuis
   Wunibald Karl
-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Using Kd-tree for spatial data

2008-09-05 Thread Alberto Luaces
Hi Maruti,

you could also try to use osgUtil::Optimizer with the SPATIALIZE_GROUPS flag 
set. This way, the scenegraph will be laid like an octree, so it would 
roughly act as the kd-tree between the root and the leaves.

I don't know of any program to do what you want, but maybe you could collapse 
all the geometry into one big geode and then run the kdtree builder visitor 
on it. To do so, you would use the optimizer with the MERGE_GEODES flag.

Alberto

El Viernes 05 Septiembre 2008ES 10:33:39 maruti borker escribió:
 Hi ,
   I understood your point. That is why i said that the kd-tree
 implemented in OSG wont be useful for my purpose. I just wanted to know if
 there are any tools/code which creates a single kd-tree of the whole scene.

 Regards,

 Maruti Borker
 IIIT Hyderabad
 Website:- http://students.iiit.ac.in/~maruti
 Blog:- http://marutiborker.wordpress.com

 On Fri, Sep 5, 2008 at 1:52 PM, Robert Osfield 
[EMAIL PROTECTED]wrote:
  HI Maruti,
 
  On Fri, Sep 5, 2008 at 9:11 AM, maruti borker [EMAIL PROTECTED]
 
  wrote:
   But when i went through the discussion, i found out that only geomety
   in
 
  the
 
   leaves have seperate kd-tree and not a single kd-tree for the whole
 
  scene.
 
   Correct me if i am wrong.
 
  The use of KdTree on drawable leaves only is done to provide a good
  balance between efficiency of intersection test and flexibility.  For
  instance the system we have now handles whole scene with moving parts,
  if you had a single KdTree you'd need to recompute it all the time.
  Also a well balanced scene graph will be spatially distributed so will
  the hierarchical bounding volumes that help intersection tests.
 
  Jumping to KdTree for the whole scene graph is technically possible,
  but you'll need to build the KdTree yourself, and in terms of
  performance vs flexibility tradeoff's is not good, it's a lot of
  effort for little gain in performance.
 
  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] Caustics for UnderWater Effect

2008-09-05 Thread Ümit Uzun
Hi Robert,

Thanks for reply. I am looking for osgTexture3D for create caustics on
terrain surface with alpha value between 0.0-0.5 When I texture I want to
see terrain surface with caustics but I can only see textures with different
state like transparance and opaque version in sliding. What can I do? I mean
I want to see like multitexture viewing form surface which is combination of
terrain and textures.

And another simple question which makes me feel shame while asking :( When I
texture the created 3D model how can I specify TexCoord? Because when I
texture the model without specification of TexCoord the result like
*THAT*http://img84.imageshack.us/my.php?image=cowbh3.png.


Thanks so much.
Best Regards.

Umit Uzun

2008/9/4 Robert Osfield [EMAIL PROTECTED]

 Hi Umit,

 I'd use a Texture3D to animate through the images (see osgtexture3D
 for an example), or if you don't need blending ImageSequence would
 work on a Texture2D (see osgimagesequence for an example).
 Texture2DArray is also possible, but it's only supported on latest
 hardwares/drivers.

 Robert.

 On Thu, Sep 4, 2008 at 2:50 PM, Ümit Uzun [EMAIL PROTECTED] wrote:
  Hi All,
 
  I have 30 textures for caustics. I want to make a underwater effect so
 have
  to alpha blend texture to terrain surface which was created with
  VirtualPlanetBuilder.
 
  My question is, how should I animate these textures on the terrain?
  Should I read all texture images to the Texture2DArray and then change
 the
  texture images by the time with using NodeCallback?
  Is there any sample like that or which osg example would help me much?
 
  Best Regards.
 
  Umit UZUN
 
  ___
  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] Texturing issues second window

2008-09-05 Thread amalric alexandre
Hi Scott,

I'm currently having the same problem as you, i'm using last developper
release OSG 2.7.1.
When I open an .osg file in the second view everything is ok, but when I
load an .ive file, the texture is missing in the second view.
Please let us hear if you've found the trick.
2008/8/3 Robert Osfield [EMAIL PROTECTED]

 Hi Scott,

 The most likely cause of this type of problem is contextID's for each
 graphics context are not being managed appropriately or contextID's
 are being reused inappropriately.  I can't say for sure though as I
 don't have your code in front of me.

 Since 2.4 we have done some work on this area, so the problem might
 already be fixed for you so could you please move to the 2.6.0-rc1 or
 2.6 branch in SVN and then let us know if the problem still occurs.

 Robert.

 On Mon, Jul 28, 2008 at 3:12 PM, Scott Angster [EMAIL PROTECTED]
 wrote:
   Hello-
 
  We are seeing an interesting problem that we can not track down.
  Several previous postings have been similar but not quite what we are
  seeing.  We are hoping someone can point us in a possible direction to
  find a solution.
 
  We have an OSG/QT application using multiple windows with views into the
  same scene graph.  We use multiple instances of the Viewer to do this.
  We are seeing issues in the second/third/etc window for models loaded in
  containing textures.  The textures do not load and we get Warning:
  detected OpenGL error 'invalid enumerant' after applying attribute
  Texture2D when the second window is opened.
 
  However if we create an object at runtime, say a sphere, and apply a
  texture to it, the second/third/etc window do not have problems with it.
  If we save out the node we created to an IVE file and reload it, the
  problem is there.
 
  I have tried to duplicate this problem using the osgviewer QT example
  such that I have a simpler code base to work with, and I can't.  I have
  made this example more complex, adding features to it to replicate our
  code (HUD, textured background, our update loop for updating dynamic
  transform nodes and camera positioning, our state settings, thread
  settings, etc).
 
  We seem to have an issue with PagedLOD too in our application for the
  second/third windows.  I hope this issue is related so if we focus on
  the texture problem, maybe the other will be solved.
 
  We are using OSG 2.4 and currently QT 3.3 (hope to be moving to 4.X
  soon).  We are seeing this on both our Linux and Windows machines.
 
  Thanks for any suggestions or insight into this.
 
  Scott
 
 
 
 
 
  ___
  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




-- 
Alexandre AMALRIC Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Texturing issues second window

2008-09-05 Thread Robert Osfield
HI Amalric,

If you open the second graphics window after the first second graphics
has been rendered and they share the same view, and the texture's are
set up to unref images after apply, then only the second graphics
window there will be no image to apply.  If you have this particular
combination of viewer usage then you will have to ensure you don't use
the unref images after apply optimization in Textures - by default
this is off, but the osgUtil::Optimizer can enable it, so perhaps this
has been done from your .ive files, but not your .osg files.

Robert.


On Fri, Sep 5, 2008 at 11:28 AM, amalric alexandre
[EMAIL PROTECTED] wrote:
 Hi Scott,

 I'm currently having the same problem as you, i'm using last developper
 release OSG 2.7.1.
 When I open an .osg file in the second view everything is ok, but when I
 load an .ive file, the texture is missing in the second view.
 Please let us hear if you've found the trick.
 2008/8/3 Robert Osfield [EMAIL PROTECTED]

 Hi Scott,

 The most likely cause of this type of problem is contextID's for each
 graphics context are not being managed appropriately or contextID's
 are being reused inappropriately.  I can't say for sure though as I
 don't have your code in front of me.

 Since 2.4 we have done some work on this area, so the problem might
 already be fixed for you so could you please move to the 2.6.0-rc1 or
 2.6 branch in SVN and then let us know if the problem still occurs.

 Robert.

 On Mon, Jul 28, 2008 at 3:12 PM, Scott Angster [EMAIL PROTECTED]
 wrote:
  Hello-
 
  We are seeing an interesting problem that we can not track down.
  Several previous postings have been similar but not quite what we are
  seeing.  We are hoping someone can point us in a possible direction to
  find a solution.
 
  We have an OSG/QT application using multiple windows with views into the
  same scene graph.  We use multiple instances of the Viewer to do this.
  We are seeing issues in the second/third/etc window for models loaded in
  containing textures.  The textures do not load and we get Warning:
  detected OpenGL error 'invalid enumerant' after applying attribute
  Texture2D when the second window is opened.
 
  However if we create an object at runtime, say a sphere, and apply a
  texture to it, the second/third/etc window do not have problems with it.
  If we save out the node we created to an IVE file and reload it, the
  problem is there.
 
  I have tried to duplicate this problem using the osgviewer QT example
  such that I have a simpler code base to work with, and I can't.  I have
  made this example more complex, adding features to it to replicate our
  code (HUD, textured background, our update loop for updating dynamic
  transform nodes and camera positioning, our state settings, thread
  settings, etc).
 
  We seem to have an issue with PagedLOD too in our application for the
  second/third windows.  I hope this issue is related so if we focus on
  the texture problem, maybe the other will be solved.
 
  We are using OSG 2.4 and currently QT 3.3 (hope to be moving to 4.X
  soon).  We are seeing this on both our Linux and Windows machines.
 
  Thanks for any suggestions or insight into this.
 
  Scott
 
 
 
 
 
  ___
  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



 --
 Alexandre AMALRIC Ingénieur RD
 ===
 PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
 http://www.pixxim.fr

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


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


[osg-users] performance issues with RTT

2008-09-05 Thread Steffen Kim
Hi everybody.

I have some performance problems with rendering to texture. 
I am doing some interlacing for an autostereoscopic display. Therefor I need 5 
different views on the scene, which I render into textures I later use as input 
for the interlacing API.
But doing the RTT slows down my application significantly (even in 
Release-mode).

I first thought it would be the interlacer that takes that much time but when I 
disabled all interlacing and everything that updates the cameras after the 
master camera was moved it didn't really change.
Even now, when everything I do is displaying the picture of the master camera 
and additionally rendering to five textures, it runs very halting.

I define 5 target textures and 5 rtt-cameras via

// Configure source textures for the interlacer
_interlacer-resetIterator();
for(int i = 0; i  _interlacer-getNumberOfTextures(); i++){
osg::ref_ptrosg::Texture2D renderTexture = 
_interlacer-getIteratorTexture();

renderTexture-setTextureSize(_interlacer-getResultTexture()-getTextureWidth(),
 _interlacer-getResultTexture()-getTextureHeight());
renderTexture-setInternalFormat(GL_RGBA);
renderTexture-setFilter(osg::Texture2D::MIN_FILTER, 
osg::Texture2D::LINEAR);
renderTexture-setFilter(osg::Texture2D::MAG_FILTER, 
osg::Texture2D::LINEAR);
_interlacer-incIterator();
}

// Configure cameras of the camera model
_cameras-resetIterator();
_interlacer-resetIterator();
for(int i = 0; i  _cameras-getNumberOfCameras(); i++){
osg::ref_ptrosg::Camera textureCamera = 
_cameras-getIteratorCamera();
textureCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
textureCamera-setClearMask(GL_COLOR_BUFFER_BIT | 
GL_DEPTH_BUFFER_BIT);
textureCamera-setViewport(0,0, winWidth, winHeight);

textureCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
textureCamera-setRenderOrder(osg::Camera::PRE_RENDER);

textureCamera-setGraphicsContext(_billInterface-getGraphicsContext());
textureCamera-setAllowEventFocus(false);
textureCamera-addChild(_billInterface-getScene());
textureCamera-attach(osg::Camera::COLOR_BUFFER, 
_interlacer-getIteratorTexture().get());
_cameras-incIterator();
_interlacer-incIterator();
}

The five RTT-cameras are children of a group node, which I add to the root node 
of my scene graph.

Is there a way to speed up the rendering somehow? I could make the resolution 
of the textures smaller (currently it's 1280x1024) but this would decrease the 
quality of the final image and I would have to scale the textures before 
interlacing what probably also takes some time.

Thanks for any hints,
Steffen


Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html

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


Re: [osg-users] performance issues with RTT

2008-09-05 Thread Robert Osfield
Hi Steffen,

You need to work out what the bottleneck is in your setup.  Try
adjusting the resolution of your textures to see if it's a memory or
fillrate issue.  Also try a range of models - ones that are simple
through to ones that are complex to see how things scale - compare
this with a standard osgviewer working on the same models.

In the end rendering your scene 5 times is going to be slower than
mono rendering - you have 5 times are much work to do, and that's even
before the final combining step.

Robert.

On Fri, Sep 5, 2008 at 2:12 PM, Steffen Kim [EMAIL PROTECTED] wrote:
 Hi everybody.

 I have some performance problems with rendering to texture.
 I am doing some interlacing for an autostereoscopic display. Therefor I need 
 5 different views on the scene, which I render into textures I later use as 
 input for the interlacing API.
 But doing the RTT slows down my application significantly (even in 
 Release-mode).

 I first thought it would be the interlacer that takes that much time but when 
 I disabled all interlacing and everything that updates the cameras after the 
 master camera was moved it didn't really change.
 Even now, when everything I do is displaying the picture of the master camera 
 and additionally rendering to five textures, it runs very halting.

 I define 5 target textures and 5 rtt-cameras via

// Configure source textures for the interlacer
_interlacer-resetIterator();
for(int i = 0; i  _interlacer-getNumberOfTextures(); i++){
osg::ref_ptrosg::Texture2D renderTexture = 
 _interlacer-getIteratorTexture();

 renderTexture-setTextureSize(_interlacer-getResultTexture()-getTextureWidth(),
  _interlacer-getResultTexture()-getTextureHeight());
renderTexture-setInternalFormat(GL_RGBA);
renderTexture-setFilter(osg::Texture2D::MIN_FILTER, 
 osg::Texture2D::LINEAR);
renderTexture-setFilter(osg::Texture2D::MAG_FILTER, 
 osg::Texture2D::LINEAR);
_interlacer-incIterator();
}

// Configure cameras of the camera model
_cameras-resetIterator();
_interlacer-resetIterator();
for(int i = 0; i  _cameras-getNumberOfCameras(); i++){
osg::ref_ptrosg::Camera textureCamera = 
 _cameras-getIteratorCamera();
textureCamera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
textureCamera-setClearMask(GL_COLOR_BUFFER_BIT | 
 GL_DEPTH_BUFFER_BIT);
textureCamera-setViewport(0,0, winWidth, winHeight);

 textureCamera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
textureCamera-setRenderOrder(osg::Camera::PRE_RENDER);

 textureCamera-setGraphicsContext(_billInterface-getGraphicsContext());
textureCamera-setAllowEventFocus(false);
textureCamera-addChild(_billInterface-getScene());
textureCamera-attach(osg::Camera::COLOR_BUFFER, 
 _interlacer-getIteratorTexture().get());
_cameras-incIterator();
_interlacer-incIterator();
}

 The five RTT-cameras are children of a group node, which I add to the root 
 node of my scene graph.

 Is there a way to speed up the rendering somehow? I could make the resolution 
 of the textures smaller (currently it's 1280x1024) but this would decrease 
 the quality of the final image and I would have to scale the textures before 
 interlacing what probably also takes some time.

 Thanks for any hints,
 Steffen

 
 Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
 http://games.entertainment.web.de/de/entertainment/games/free/index.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


Re: [osg-users] performance issues with RTT

2008-09-05 Thread Jean-Sébastien Guay

Hello Steffen,

... (currently it's 1280x1024) 


I haven't really done what you're saying myself, but this strikes me as 
a possible choking point... Are you disabling the resizeNonPowerOfTwo 
hint on your RTT textures? It could be that your textures are being 
resized each time you render to them (each time they're dirtied).


You might want to try rendering to 1024x1024 textures. I *think* NPOT 
textures are as fast as power-of-two textures now on current hardware, 
but trying it out can't hurt.


Also, what hardware and what version of OSG are you running this on? 
That will help others give you better answers.


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Exporting from Maya

2008-09-05 Thread Todd J. Furlong
I'm interested in getting the community's input on the best way to 
export from Maya to an OSG-readable format.  I'm looking for something 
that will support scene structure, textures, and potentially shaders. 
We tried FLT export from Maya, but the textures didn't come into OSG. 
Has anyone come up with a reliable way to bring in Maya data?


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


[osg-users] Cannot get apps to find plugins

2008-09-05 Thread Filip Wänström
Hi again,

I have problems to get my apps to find the plugins. Or rather, there seems
to be some issue with the executable. I'm loosing my mind over this today so
if someone have some insights I would be more than happy!

So I'm on a Mac  with Leopard(10.5.4)
I tested to build using CMake to generate a Xcode project. I built for 10.5
deployment from Xcode and ran the install scripts using sudo in the
terminal. Then I set my OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0 so
those would be found. I also set the OSG_FILE_PATH to where I put those
files.

The examples that installed in /usr/local/share/OpenSceneGraph/bin worked
fine from the command line.

So far, so fine.

Then I proceeded to create a xcode project for a simple OSG app that reads a
png file from the resource bundle. But it can't seem to find the plugins...
I can't find the source to this issue so I would be glad if someone could
tell me in the right direction.

- Is it really so that the plugin can't be found? How is that possible? The
examples had no problems?
- Can there be some binary incompability? Should I turn on some switch in
xcode?

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


Re: [osg-users] Cannot get apps to find plugins

2008-09-05 Thread Robert Osfield
Hi Filip,

If you have installed the OSG then there should be no need to set the
path to the plugins, as the OSG should search the standard lib paths
for the presence of the osgPlugins-2.x.x directory.

A good way to check where the the OSG is searching for files and
plugins is to enable verbose debug messages, on the command line do:

  setenv OSG_NOTIFY_LEVEL DEBUG
  osgviewer cow.osg

Then look back up through the output till you can see it search for
the osgdb_osg plugin.

If your system doesn't have the /usr/local/lib on its library path
then you could add this, for instance via DYLD_LIBRARY_PATH. I'm no
OSX expert though so just recalling stuff from when I've tinkered with
Mac's.

Robert.

On Fri, Sep 5, 2008 at 4:11 PM, Filip Wänström [EMAIL PROTECTED] wrote:
 Hi again,

 I have problems to get my apps to find the plugins. Or rather, there seems
 to be some issue with the executable. I'm loosing my mind over this today so
 if someone have some insights I would be more than happy!

 So I'm on a Mac  with Leopard(10.5.4)
 I tested to build using CMake to generate a Xcode project. I built for 10.5
 deployment from Xcode and ran the install scripts using sudo in the
 terminal. Then I set my OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0 so
 those would be found. I also set the OSG_FILE_PATH to where I put those
 files.

 The examples that installed in /usr/local/share/OpenSceneGraph/bin worked
 fine from the command line.

 So far, so fine.

 Then I proceeded to create a xcode project for a simple OSG app that reads a
 png file from the resource bundle. But it can't seem to find the plugins...
 I can't find the source to this issue so I would be glad if someone could
 tell me in the right direction.

 - Is it really so that the plugin can't be found? How is that possible? The
 examples had no problems?
 - Can there be some binary incompability? Should I turn on some switch in
 xcode?

 /Filip








 ___
 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] Displaying a scene in the background of a QGraphicsView

2008-09-05 Thread Robert Osfield
Hi Max,

My guess is that Qt is changing OpenGL state which is not being
protected, and then you are mixing this with the OSG which assumes
that it has complete control over OpenGL state so gets messed up by
the QT changes to state, and also Qt OpenGL code is likely to be
messed up by the OSG changing state.

I don't know enough about the Qt's implementation here to really
provide my insight.  Personally I'd rather keep Qt doing Windowing and
the OSG doing OpenGL.  If you want to mix things then you'll need to
start playing games with push and popping OpenGL state when entering
the Qt OpenGl code path, and also resetting OpenGL state after leaving
the OSG section.

Robert.

On Fri, Sep 5, 2008 at 4:16 PM, Max Pfingsthorn
[EMAIL PROTECTED] wrote:
 Dear users,

 this problem has been with me for a while. I've even tried it with other
 graphics engines (Ogre) to no avail.

 As shown in this toy project at Trolltech Labs

 http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/

 I would like to show a scene in the background of a QGraphicsView and I
 was very happy that the ViewerQT class already was a QGLWidget. However,
 there seems to be something scaled wrong after I call viewer-frame().

 Attached are a few screenshots and the code I have so far. I'm currently
 running Ubuntu 8.04.1 and I'm using the OSG 2.2 binaries that came with
 it. Beware that you need at least Qt 4.4 to compile this code.

 qt-osg-1.png and -2.png show how far I am at the moment. Number 2 shows
 the problem with scaling the window. OSG shows the scene fine in the
 background, but the widget I'd like to overlay is stretched. I believe
 the OpenGL version of QPainter draws in some normalized coordinates and
 the bounding box isn't properly updated. qt-osg-ok-1.png and -2.png show
 the same window sizes without calling viewer-frame(), and the scaling
 of the widget is ok. Just no scene in the background of course.

 I've traced the problem to osgViewer::Renderer::cull_draw(). I believe,
 when the geometry of the view is set, something makes Qt stop drawing
 correctly.

 In the function which calls viewer-frame() (in
 osgGraphicsView::drawBackground), I thought I save any sort of relevant
 OpenGL state, the projection matrix, model/view matrix, and even the
 texture matrix. After the call the viewer-frame(), I restore them
 again. Is there any other state that I might have overlooked which is
 set in the renderer? Also, do you have any idea why the Qt widget is not
 drawn entirely sometimes? Could it have something do to with buffer swaps?

 Thank you all for your help in advance!

 Best regards,
 Max Pfingsthorn

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


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


Re: [osg-users] performance issues with RTT

2008-09-05 Thread Steffen Kim
Thanks for the hints so far...

I gave you wrong information since I forgot that I take care of the NPOT-stuff 
myself.
The API I use later on needs POT-textures so I make sure that only POT-textures 
are rendered. So in fact my textures are normally 2048x1024.

I know that the performance issues are most certain a problem of the texture 
rendering since we have parts of the application where even huger amounts of 
(normal render-to-view) cameras are involved without slowing down everything as 
much. The scene is pretty simple too and runs smoothly without the RTT-cameras.
Back on Monday I will try to get some FPS-values for exactly the same 
camera-setup with and without RTT for different scene complexities (here in 
Germany the weekend begins now ;)).

What I just found out is that the texture sizes make a huge difference in 
rendering performance. With 256x256-textures my cameras hardly slow down the 
viewer at all. That's also an evidence that the problem has to be somewhere in 
the texture-creation-part. 
If this cannot be enhanced then I probably have to find a good balance between 
quality and speed.
But I still have hopes that there are better ways to improve my performance 
without having to sacrifice too much resolution-wise.

BTW: I'm running my stuff on a Xeon 5160 at 3GHz and 2GB RAM with a Radeon 
X1900 card.

Have a nice weekend,
Steffen



___
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00

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


Re: [osg-users] Cannot get apps to find plugins

2008-09-05 Thread Filip Wänström
Thank you Robert,

but the wierd thing is that this is in the output:

FindFileInPath() : trying /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so ...
FindFileInPath() : USING /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so
Opened DynamicLibrary osgPlugins-2.6.0/osgdb_qt.so
Warning: Could not find plugin to read objects from file wood.png.
wood.png'.

I'll have to dig more on this and report back. I've tried so many different
ways now that It might be a better route to uninstall and install anew...
/Filip


On Fri, Sep 5, 2008 at 5:28 PM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi Filip,

 If you have installed the OSG then there should be no need to set the
 path to the plugins, as the OSG should search the standard lib paths
 for the presence of the osgPlugins-2.x.x directory.

 A good way to check where the the OSG is searching for files and
 plugins is to enable verbose debug messages, on the command line do:

  setenv OSG_NOTIFY_LEVEL DEBUG
  osgviewer cow.osg

 Then look back up through the output till you can see it search for
 the osgdb_osg plugin.

 If your system doesn't have the /usr/local/lib on its library path
 then you could add this, for instance via DYLD_LIBRARY_PATH. I'm no
 OSX expert though so just recalling stuff from when I've tinkered with
 Mac's.

 Robert.

 On Fri, Sep 5, 2008 at 4:11 PM, Filip Wänström [EMAIL PROTECTED]
 wrote:
  Hi again,
 
  I have problems to get my apps to find the plugins. Or rather, there
 seems
  to be some issue with the executable. I'm loosing my mind over this today
 so
  if someone have some insights I would be more than happy!
 
  So I'm on a Mac  with Leopard(10.5.4)
  I tested to build using CMake to generate a Xcode project. I built for
 10.5
  deployment from Xcode and ran the install scripts using sudo in the
  terminal. Then I set my OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0
 so
  those would be found. I also set the OSG_FILE_PATH to where I put those
  files.
 
  The examples that installed in /usr/local/share/OpenSceneGraph/bin worked
  fine from the command line.
 
  So far, so fine.
 
  Then I proceeded to create a xcode project for a simple OSG app that
 reads a
  png file from the resource bundle. But it can't seem to find the
 plugins...
  I can't find the source to this issue so I would be glad if someone could
  tell me in the right direction.
 
  - Is it really so that the plugin can't be found? How is that possible?
 The
  examples had no problems?
  - Can there be some binary incompability? Should I turn on some switch in
  xcode?
 
  /Filip
 
 
 
 
 
 
 
 
  ___
  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] Displaying a scene in the background of a QGraphicsView

2008-09-05 Thread Max Pfingsthorn

Hello Robert,

Thank you very much for your reply.

My thoughts exactly. But how do I save and restore the opengl state in  
its entirety? I tried pushing/popping the modelview, projection and  
even the texture matrices around calling viewer-frame(). I also  
explicitly glGet'ed them and loaded them again after OSG was done in  
case push/pops were not matched properly inside OSG.


What else is there to save in the opengl state?

Best regards,
Max Pfingsthorn

On 5 Sep 2008, at 17:40, Robert Osfield [EMAIL PROTECTED]  
wrote:



Hi Max,

My guess is that Qt is changing OpenGL state which is not being
protected, and then you are mixing this with the OSG which assumes
that it has complete control over OpenGL state so gets messed up by
the QT changes to state, and also Qt OpenGL code is likely to be
messed up by the OSG changing state.

I don't know enough about the Qt's implementation here to really
provide my insight.  Personally I'd rather keep Qt doing Windowing and
the OSG doing OpenGL.  If you want to mix things then you'll need to
start playing games with push and popping OpenGL state when entering
the Qt OpenGl code path, and also resetting OpenGL state after leaving
the OSG section.

Robert.

On Fri, Sep 5, 2008 at 4:16 PM, Max Pfingsthorn
[EMAIL PROTECTED] wrote:

Dear users,

this problem has been with me for a while. I've even tried it with  
other

graphics engines (Ogre) to no avail.

As shown in this toy project at Trolltech Labs

http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/

I would like to show a scene in the background of a QGraphicsView  
and I
was very happy that the ViewerQT class already was a QGLWidget.  
However,
there seems to be something scaled wrong after I call viewer-frame 
().


Attached are a few screenshots and the code I have so far. I'm  
currently
running Ubuntu 8.04.1 and I'm using the OSG 2.2 binaries that came  
with

it. Beware that you need at least Qt 4.4 to compile this code.

qt-osg-1.png and -2.png show how far I am at the moment. Number 2  
shows

the problem with scaling the window. OSG shows the scene fine in the
background, but the widget I'd like to overlay is stretched. I  
believe
the OpenGL version of QPainter draws in some normalized coordinates  
and
the bounding box isn't properly updated. qt-osg-ok-1.png and -2.png  
show
the same window sizes without calling viewer-frame(), and the  
scaling

of the widget is ok. Just no scene in the background of course.

I've traced the problem to osgViewer::Renderer::cull_draw(). I  
believe,

when the geometry of the view is set, something makes Qt stop drawing
correctly.

In the function which calls viewer-frame() (in
osgGraphicsView::drawBackground), I thought I save any sort of  
relevant

OpenGL state, the projection matrix, model/view matrix, and even the
texture matrix. After the call the viewer-frame(), I restore them
again. Is there any other state that I might have overlooked which is
set in the renderer? Also, do you have any idea why the Qt widget  
is not
drawn entirely sometimes? Could it have something do to with buffer  
swaps?


Thank you all for your help in advance!

Best regards,
Max Pfingsthorn

___
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] Exporting from Maya

2008-09-05 Thread Bob Huebert

Hi Todd,

  We regularly use maya's ascii obj format. This works rather well for our 
needs. I believe there exists an osg exporter for maya as well.


-bob


I'm interested in getting the community's input on the best way to export 
from Maya to an OSG-readable format.  I'm looking for something that will 
support scene structure, textures, and potentially shaders. We tried FLT 
export from Maya, but the textures didn't come into OSG. Has anyone come up 
with a reliable way to bring in Maya data?


-Todd
___
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] Exporting from Maya

2008-09-05 Thread Bob Huebert


On Fri, 5 Sep 2008, Todd J. Furlong wrote:

I couldn't find a valid link to the OSG Maya exporter.  That would be helpful 
if someone could post it.


Not sure of the platform you're on, but found win32 binary and source for 
the osg maya exporter here:


http://web.archive.org/web/20070203172951/http://www.diosoft.com/soft/osgmaya/

I love the wayback machine :)

I didn't think OBJ supported texture maps, but it looks like I was wrong 
about that.


They do. Just make sure you have them properly UV mapped.

hth
-bob



-Todd

Bob Huebert wrote:

Hi Todd,

  We regularly use maya's ascii obj format. This works rather well for our 
needs. I believe there exists an osg exporter for maya as well.


-bob


I'm interested in getting the community's input on the best way to export 
from Maya to an OSG-readable format.  I'm looking for something that will 
support scene structure, textures, and potentially shaders. We tried FLT 
export from Maya, but the textures didn't come into OSG. Has anyone come 
up with a reliable way to bring in Maya data?


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


--
Todd J. Furlong
Inv3rsion, LLC
888-588-0573 x81 office
603-759-9035 mobile
603-584-0454 fax
___
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] Fullscreen

2008-09-05 Thread Tim Jaffe
Greetings,

I'm upgrading some old OSG 1.2 code to OSG 2.4 and need to implement the option 
to run in fullscreen mode.  Sans Producer, how is this done?  Also, is this 
true fullscreen (i.e., exclusive) mode or just a borderless topmost window 
sized to fit the screen?

Many thanks in advanced,
/* blahpers */


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


Re: [osg-users] VPB error

2008-09-05 Thread Michael W. Hall
Robert,

I looked at the front page and nothing is mentioned about OSG 2.6.  I
have tried VPB 0.9.7 and make fails with several errors.  The SVN
version compiles, but gives the the error when I try to run it.  Can you
tell me which version of VPB I need?

Michael

On Thu, 2008-09-04 at 10:27 +0100, Robert Osfield wrote:
 HI Michael,
 
 There are notes on the virtualplanetbuidler.osgforge.osg front page
 that describes with versions of the VPB work with which versions of
 OSG.   As always the VPB svn trunk works against the OSG svn trunk,
 not OSG 2.6.
 
 Robert.
 
 On Thu, Sep 4, 2008 at 4:00 AM, Michael W. Hall [EMAIL PROTECTED] wrote:
  Has there been a new release of VPB?  I built it, but when I try to run
  it I get the following:
 
  osgdem:  error while loading shared libraries:  libvpb.so.8: cannot open
  shared object file:  No such file or directory
 
  Looks as thought something did not install.  Just wondering if someone
  may have some idea.  I got the version of VPB from SVN and it appears to
  build with the OSG that I have, 2.6 RC1.
 
  Thanks,
  Michael
 
 
  ___
  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] Cannot get apps to find plugins

2008-09-05 Thread Robert Osfield
Hi Filip,

Could you try other and model image formats, such as

 osgviewer cow.osg

And see what happens.

Robert.

On Fri, Sep 5, 2008 at 6:33 PM, Filip Wänström [EMAIL PROTECTED] wrote:
 Thank you Robert,

 but the wierd thing is that this is in the output:

 FindFileInPath() : trying /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so ...
 FindFileInPath() : USING /usr/local/lib/osgPlugins-2.6.0/osgdb_qt.so
 Opened DynamicLibrary osgPlugins-2.6.0/osgdb_qt.so
 Warning: Could not find plugin to read objects from file wood.png.
 wood.png'.

 I'll have to dig more on this and report back. I've tried so many different
 ways now that It might be a better route to uninstall and install anew...
 /Filip


 On Fri, Sep 5, 2008 at 5:28 PM, Robert Osfield [EMAIL PROTECTED]
 wrote:

 Hi Filip,

 If you have installed the OSG then there should be no need to set the
 path to the plugins, as the OSG should search the standard lib paths
 for the presence of the osgPlugins-2.x.x directory.

 A good way to check where the the OSG is searching for files and
 plugins is to enable verbose debug messages, on the command line do:

  setenv OSG_NOTIFY_LEVEL DEBUG
  osgviewer cow.osg

 Then look back up through the output till you can see it search for
 the osgdb_osg plugin.

 If your system doesn't have the /usr/local/lib on its library path
 then you could add this, for instance via DYLD_LIBRARY_PATH. I'm no
 OSX expert though so just recalling stuff from when I've tinkered with
 Mac's.

 Robert.

 On Fri, Sep 5, 2008 at 4:11 PM, Filip Wänström [EMAIL PROTECTED]
 wrote:
  Hi again,
 
  I have problems to get my apps to find the plugins. Or rather, there
  seems
  to be some issue with the executable. I'm loosing my mind over this
  today so
  if someone have some insights I would be more than happy!
 
  So I'm on a Mac  with Leopard(10.5.4)
  I tested to build using CMake to generate a Xcode project. I built for
  10.5
  deployment from Xcode and ran the install scripts using sudo in the
  terminal. Then I set my OSG_LIBRARY_PATH=/usr/local/lib/osgPlugins-2.6.0
  so
  those would be found. I also set the OSG_FILE_PATH to where I put those
  files.
 
  The examples that installed in /usr/local/share/OpenSceneGraph/bin
  worked
  fine from the command line.
 
  So far, so fine.
 
  Then I proceeded to create a xcode project for a simple OSG app that
  reads a
  png file from the resource bundle. But it can't seem to find the
  plugins...
  I can't find the source to this issue so I would be glad if someone
  could
  tell me in the right direction.
 
  - Is it really so that the plugin can't be found? How is that possible?
  The
  examples had no problems?
  - Can there be some binary incompability? Should I turn on some switch
  in
  xcode?
 
  /Filip
 
 
 
 
 
 
 
 
  ___
  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] performance issues with RTT

2008-09-05 Thread Robert Osfield
HI Guys,

What are you all doing with your RTT Camera's?  Are you just doing
render to texture, or are you doing a copy to Image/glReadPixels as
well?   The later will throw a big slow down as it requires a round
trip to the graphics card and an associated finish of the all OpenGL
prior to the glReadPixels.

Robert.

On Fri, Sep 5, 2008 at 6:38 PM, Harash Sharma [EMAIL PROTECTED] wrote:
 Hi Steffen, Guay and Robert,

In the same regard I would like to mention something. We have also
 developed an application that uses multiple RTT cameras. However only one
 camera is active at a time ( the rest are masked using node mask). All
 cameras differ only in the resolution of the texture, they are viewing
 exactly the same scene and have identical fields of view. We too have found
 that the frame rate has a lot of dependence on the texture size. 256 x256
 texture gives a fairly high frame rate(30+ frames/second), 512x512 slows it
 down considerably (to around 8 frames / second) and 1024x1024 slows it even
 further (~ 1 fps). All these figures are in release mode build.

 My machine specifications
 Processor: Xeon 5160
 RAM:4 GB Fully Buffered DDR2
 Graphics:nVidia Quadro FX4500 (512MB)

 I would be highly obliged if a way out can be suggested.

 Regards

 Harash
 - Original Message 
 From: Steffen Kim [EMAIL PROTECTED]
 To: osg-users@lists.openscenegraph.org
 Sent: Friday, September 5, 2008 10:04:25 PM
 Subject: Re: [osg-users] performance issues with RTT

 Thanks for the hints so far...

 I gave you wrong information since I forgot that I take care of the
 NPOT-stuff myself.
 The API I use later on needs POT-textures so I make sure that only
 POT-textures are rendered. So in fact my textures are normally 2048x1024.

 I know that the performance issues are most certain a problem of the texture
 rendering since we have parts of the application where even huger amounts of
 (normal render-to-view) cameras are involved without slowing down everything
 as much. The scene is pretty simple too and runs smoothly without the
 RTT-cameras.
 Back on Monday I will try to get some FPS-values for exactly the same
 camera-setup with and without RTT for different scene complexities (here in
 Germany the weekend begins now ;)).

 What I just found out is that the texture sizes make a huge difference in
 rendering performance. With 256x256-textures my cameras hardly slow down the
 viewer at all. That's also an evidence that the problem has to be somewhere
 in the texture-creation-part.
 If this cannot be enhanced then I probably have to find a good balance
 between quality and speed.
 But I still have hopes that there are better ways to improve my performance
 without having to sacrifice too much resolution-wise.

 BTW: I'm running my stuff on a Xeon 5160 at 3GHz and 2GB RAM with a Radeon
 X1900 card.

 Have a nice weekend,
 Steffen



 ___
 Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
 kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00

 ___
 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] Displaying a scene in the background of a QGraphicsView

2008-09-05 Thread Robert Osfield
Hi Max,

The topic of mixing OpenGL code with the OSG has been discussed many
times on osg-users so have a look through the archives on this topic.
glPushAttrib would also be a good keyword to search on.

Robert.

On Fri, Sep 5, 2008 at 6:42 PM, Max Pfingsthorn
[EMAIL PROTECTED] wrote:
 Hello Robert,

 Thank you very much for your reply.

 My thoughts exactly. But how do I save and restore the opengl state in its
 entirety? I tried pushing/popping the modelview, projection and even the
 texture matrices around calling viewer-frame(). I also explicitly glGet'ed
 them and loaded them again after OSG was done in case push/pops were not
 matched properly inside OSG.

 What else is there to save in the opengl state?

 Best regards,
 Max Pfingsthorn

 On 5 Sep 2008, at 17:40, Robert Osfield [EMAIL PROTECTED] wrote:

 Hi Max,

 My guess is that Qt is changing OpenGL state which is not being
 protected, and then you are mixing this with the OSG which assumes
 that it has complete control over OpenGL state so gets messed up by
 the QT changes to state, and also Qt OpenGL code is likely to be
 messed up by the OSG changing state.

 I don't know enough about the Qt's implementation here to really
 provide my insight.  Personally I'd rather keep Qt doing Windowing and
 the OSG doing OpenGL.  If you want to mix things then you'll need to
 start playing games with push and popping OpenGL state when entering
 the Qt OpenGl code path, and also resetting OpenGL state after leaving
 the OSG section.

 Robert.

 On Fri, Sep 5, 2008 at 4:16 PM, Max Pfingsthorn
 [EMAIL PROTECTED] wrote:

 Dear users,

 this problem has been with me for a while. I've even tried it with other
 graphics engines (Ogre) to no avail.

 As shown in this toy project at Trolltech Labs


 http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/

 I would like to show a scene in the background of a QGraphicsView and I
 was very happy that the ViewerQT class already was a QGLWidget. However,
 there seems to be something scaled wrong after I call viewer-frame().

 Attached are a few screenshots and the code I have so far. I'm currently
 running Ubuntu 8.04.1 and I'm using the OSG 2.2 binaries that came with
 it. Beware that you need at least Qt 4.4 to compile this code.

 qt-osg-1.png and -2.png show how far I am at the moment. Number 2 shows
 the problem with scaling the window. OSG shows the scene fine in the
 background, but the widget I'd like to overlay is stretched. I believe
 the OpenGL version of QPainter draws in some normalized coordinates and
 the bounding box isn't properly updated. qt-osg-ok-1.png and -2.png show
 the same window sizes without calling viewer-frame(), and the scaling
 of the widget is ok. Just no scene in the background of course.

 I've traced the problem to osgViewer::Renderer::cull_draw(). I believe,
 when the geometry of the view is set, something makes Qt stop drawing
 correctly.

 In the function which calls viewer-frame() (in
 osgGraphicsView::drawBackground), I thought I save any sort of relevant
 OpenGL state, the projection matrix, model/view matrix, and even the
 texture matrix. After the call the viewer-frame(), I restore them
 again. Is there any other state that I might have overlooked which is
 set in the renderer? Also, do you have any idea why the Qt widget is not
 drawn entirely sometimes? Could it have something do to with buffer
 swaps?

 Thank you all for your help in advance!

 Best regards,
 Max Pfingsthorn

 ___
 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] Fullscreen

2008-09-05 Thread Robert Osfield
Hi Tim,

By default the osgViewer library will open up windows fullscreen, i.e.
try runing osgviewer or almost all of the osg examples.  For examples
of explictly setting up windows have a look at the osgcamera example
and also the View::setUpView*() methods in src/osgViewer/View.cpp.

The fullscreen window It is done using a borderless window, in the
same way the Producer did it.

Robert.

On Fri, Sep 5, 2008 at 7:47 PM, Tim Jaffe [EMAIL PROTECTED] wrote:
 Greetings,

 I'm upgrading some old OSG 1.2 code to OSG 2.4 and need to implement the
 option to run in fullscreen mode.  Sans Producer, how is this done?  Also,
 is this true fullscreen (i.e., exclusive) mode or just a borderless topmost
 window sized to fit the screen?

 Many thanks in advanced,
 /* blahpers */

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

2008-09-05 Thread Robert Osfield
On Fri, Sep 5, 2008 at 8:26 PM, Michael W. Hall [EMAIL PROTECTED] wrote:
 I looked at the front page and nothing is mentioned about OSG 2.6.

And yet you still wanted to make the assumption that implictly
SVN/trunk meant OSG 2.6...  the VPB wiki front page tells you
everything that is to know.

 I
 have tried VPB 0.9.7 and make fails with several errors.  The SVN
 version compiles, but gives the the error when I try to run it.  Can you
 tell me which version of VPB I need?

There is no VPB dev release that maps to OSG-2.6.

VPB is in development, and isn't far away from its 1.0.  To pick up on
the latest VPB you'll need VPB svn/trunk and OSG svn/trunk as some of
the recent additions to VPB required mods to osgTerrain in OSG, since
2.6.

Once VPB is ready for its next dev release I'll match a VPB dev
release with a corresponding OSG dev release.  I'm not ready for this
yet.

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


[osg-users] Speeding Up osgText?

2008-09-05 Thread Kawicki, Ryan H
This is in reference to a previous question that has been posed.  Sorry
if this has already been addressed.

http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
008-April/009652.html

Our application seems to be hitting this same issue.  We are trying to
render quite a bit of text on the screen, and we seem to be getting
burned by both the setText( ... ) and the drawImplementation.

We are currently using an older version of OSG, but we are planning on
moving to 2.6.0 relatively soon.  I have looked at our current version
of osgText and the 2.6.0 version and can conclude that this will still
be an issue.

Our application is building the text shapes with SCREEN_COORDS for the
character size mode and SCREEN for axis alignment.

What I have noticed is that for each text shape update, the function
computeGlyphRepresentation is called to recompute the glyph information.
This function then calls the function computePositions.  Here is what
compute positions looks like.

void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());

// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)

for(unsigned int i=0;isize;++i)
{
 computePositions(i);
}
}

As can be seen by the first line, the maximum size is being obtained
from the maximum number of graphics contexts or the size of
_autoTransformCache.  For me this is set to 32, since the default was
never being changed.  The computePositions function is a very expensive
operation, and a minor flaw in our design was causing a huge impact in
performance.  It might be a good idea to either assert on or to check
the traversalNumber from the _autoTransformCache to make sure the
context is a valid one.

Performance is still down for our application.  I think some of the
problem is related to this computePositions function still.  Our
application is frequently setting text, so we incur a CPU hit to
recalculate all the glyph vertices.  When the text is visible, we incur
the same CPU hit to recalculate all the glyph vertices since the
_autoTransformCache model view matrix are always different between the
update of the text and the current state of the draw phase.  Here's the
draw implementation for text.

void Text::drawImplementation(osg::State state) const
{
unsigned int contextID = state.getContextID();

 CODE REMOVED 

if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
 CODE REMOVED 

AutoTransformCache atc = _autoTransformCache[contextID];
const osg::Matrix modelview = state.getModelViewMatrix();
const osg::Matrix projection = state.getProjectionMatrix();

 CODE REMOVED 

bool doUpdate = atc._traversalNumber==-1;
if (atc._traversalNumber=0)
{
if (atc._modelview!=modelview)
{
doUpdate = true;
}
else if (width!=atc._width || height!=atc._height)
{
doUpdate = true;
}
else if (atc._projection!=projection)
{
doUpdate = true;
}
}

atc._traversalNumber = frameNumber;
atc._width = width;
atc._height = height;

if (doUpdate)
{
atc._transformedPosition = newTransformedPosition;
atc._projection = projection;
atc._modelview = modelview;

computePositions(contextID);
}

}

 CODE REMOVED 
}

With the draw implementation above and the setText all being called
within a render frame, we are computing the glyph vertices twice.  I
think we can speed things up a bit, but I need some information.

Is there a reason as to why we need to call computePositions from within
computeGlyphRepresentation if the drawImplementation will already take
care of that?  As far as I can see, computeGlyphRepresentation is
already doing the calculations for the bounding box.  Makes sense that
we only have that information.  We can then just allow the
drawImplementation do the nasty work of recalculating the vertices by
calling computePositions.

Does anyone have any suggestions that might help in improving
performance?  I am wondering if some of this work could be moved from
the CPU and pushed to the GPU.

Sorry for the long post and thanks for any suggestions.

Ryan H. Kawicki
The Boeing Company
Training Systems  Services
Software Engineer
___
osg-users mailing list

Re: [osg-users] Speeding Up osgText?

2008-09-05 Thread Nick Bryan

Hi Ryan,
can't answer your question immediately but i am embarking on a lot of 
work around osgText so thanks for the heads up and the detailed post.  
I'll consider your points as i work through what i need to do.  Will 
obviously post feedback to the group.


rgds
Nick

Kawicki, Ryan H wrote:

This is in reference to a previous question that has been posed.  Sorry
if this has already been addressed.

http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
008-April/009652.html

Our application seems to be hitting this same issue.  We are trying to
render quite a bit of text on the screen, and we seem to be getting
burned by both the setText( ... ) and the drawImplementation.

We are currently using an older version of OSG, but we are planning on
moving to 2.6.0 relatively soon.  I have looked at our current version
of osgText and the 2.6.0 version and can conclude that this will still
be an issue.

Our application is building the text shapes with SCREEN_COORDS for the
character size mode and SCREEN for axis alignment.

What I have noticed is that for each text shape update, the function
computeGlyphRepresentation is called to recompute the glyph information.
This function then calls the function computePositions.  Here is what
compute positions looks like.

void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());

// FIXME: OPTIMIZE: This would be one of the ideal locations to

// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)

for(unsigned int i=0;isize;++i)
{
 computePositions(i);
}
}

As can be seen by the first line, the maximum size is being obtained
from the maximum number of graphics contexts or the size of
_autoTransformCache.  For me this is set to 32, since the default was
never being changed.  The computePositions function is a very expensive
operation, and a minor flaw in our design was causing a huge impact in
performance.  It might be a good idea to either assert on or to check
the traversalNumber from the _autoTransformCache to make sure the
context is a valid one.

Performance is still down for our application.  I think some of the
problem is related to this computePositions function still.  Our
application is frequently setting text, so we incur a CPU hit to
recalculate all the glyph vertices.  When the text is visible, we incur
the same CPU hit to recalculate all the glyph vertices since the
_autoTransformCache model view matrix are always different between the
update of the text and the current state of the draw phase.  Here's the
draw implementation for text.

void Text::drawImplementation(osg::State state) const
{
unsigned int contextID = state.getContextID();

 CODE REMOVED 

if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
 CODE REMOVED 

AutoTransformCache atc = _autoTransformCache[contextID];
const osg::Matrix modelview = state.getModelViewMatrix();
const osg::Matrix projection = state.getProjectionMatrix();

 CODE REMOVED 

bool doUpdate = atc._traversalNumber==-1;
if (atc._traversalNumber=0)
{
if (atc._modelview!=modelview)
{
doUpdate = true;
}
else if (width!=atc._width || height!=atc._height)
{
doUpdate = true;
}
else if (atc._projection!=projection)
{
doUpdate = true;
}
}

atc._traversalNumber = frameNumber;

atc._width = width;
atc._height = height;

if (doUpdate)
{
atc._transformedPosition = newTransformedPosition;

atc._projection = projection;
atc._modelview = modelview;

computePositions(contextID);
}

}


 CODE REMOVED 
}

With the draw implementation above and the setText all being called
within a render frame, we are computing the glyph vertices twice.  I
think we can speed things up a bit, but I need some information.

Is there a reason as to why we need to call computePositions from within
computeGlyphRepresentation if the drawImplementation will already take
care of that?  As far as I can see, computeGlyphRepresentation is
already doing the calculations for the bounding box.  Makes sense that
we only have that information.  We can then just allow the
drawImplementation do the nasty work of recalculating the vertices by
calling computePositions.

Does anyone have any suggestions that might help in improving
performance?  I am wondering if 

Re: [osg-users] Speeding Up osgText?

2008-09-05 Thread Jeremy Moles
On Fri, 2008-09-05 at 22:53 +0100, Nick Bryan wrote:
 Hi Ryan,
 can't answer your question immediately but i am embarking on a lot of 
 work around osgText so thanks for the heads up and the detailed post.  
 I'll consider your points as i work through what i need to do.  Will 
 obviously post feedback to the group.

I'd be very interested in know what and how and why you're doing
this. :)

I've been asking about some osgText for months to improve osgWidget, but
haven't really made any impressions I don't think (we're all pretty
busy, as it were).

As such, I have begun (and am almost finished!) writing an OSG NodeKit
called osgPango, which uses the Pango library to layout text, create
high-quality subpixel fonts renderings, etc. Whether or not anyone else
will be interested in it is hard to say, but I intend on using it for my
own purpose because I get superb font quality (even shadows and
outlines!) and a simplified API.

I had originally intended to just hack osgText, but the code is far too
complicated for me to grok. :) So I just ended up writing a different
NodeKit for it, which will be compaitble with osgWidget for sure (in the
form of osgPango::Label and osgPango::Input).

I have posted many times about osgText in the past, and if you would
like I can recall those links here for you to check out (particularly
with regards to quality--see osgfont--and the inability to insure that
all quads are pixel-aligned and that I can access the extents of each
text glyph individually for input...)

 rgds
 Nick
 
 Kawicki, Ryan H wrote:
  This is in reference to a previous question that has been posed.  Sorry
  if this has already been addressed.
 
  http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
  008-April/009652.html
 
  Our application seems to be hitting this same issue.  We are trying to
  render quite a bit of text on the screen, and we seem to be getting
  burned by both the setText( ... ) and the drawImplementation.
 
  We are currently using an older version of OSG, but we are planning on
  moving to 2.6.0 relatively soon.  I have looked at our current version
  of osgText and the 2.6.0 version and can conclude that this will still
  be an issue.
 
  Our application is building the text shapes with SCREEN_COORDS for the
  character size mode and SCREEN for axis alignment.
 
  What I have noticed is that for each text shape update, the function
  computeGlyphRepresentation is called to recompute the glyph information.
  This function then calls the function computePositions.  Here is what
  compute positions looks like.
 
  void Text::computePositions()
  {
  unsigned int size =
  osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
  texts(),_autoTransformCache.size());
  
  // FIXME: OPTIMIZE: This would be one of the ideal locations to
  // call computeAverageGlypthWidthAndHeight(). It is out of the
  contextID loop
  // so the value would be computed fewer times. But the code will
  need changes
  // to get the value down to the locations it is needed. (Either pass
  through parameters
  // or member variables, but we would need a system to know if the
  values are stale.)
 
  for(unsigned int i=0;isize;++i)
  {
   computePositions(i);
  }
  }
 
  As can be seen by the first line, the maximum size is being obtained
  from the maximum number of graphics contexts or the size of
  _autoTransformCache.  For me this is set to 32, since the default was
  never being changed.  The computePositions function is a very expensive
  operation, and a minor flaw in our design was causing a huge impact in
  performance.  It might be a good idea to either assert on or to check
  the traversalNumber from the _autoTransformCache to make sure the
  context is a valid one.
 
  Performance is still down for our application.  I think some of the
  problem is related to this computePositions function still.  Our
  application is frequently setting text, so we incur a CPU hit to
  recalculate all the glyph vertices.  When the text is visible, we incur
  the same CPU hit to recalculate all the glyph vertices since the
  _autoTransformCache model view matrix are always different between the
  update of the text and the current state of the draw phase.  Here's the
  draw implementation for text.
 
  void Text::drawImplementation(osg::State state) const
  {
  unsigned int contextID = state.getContextID();
 
   CODE REMOVED 
 
  if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
  {
   CODE REMOVED 
 
  AutoTransformCache atc = _autoTransformCache[contextID];
  const osg::Matrix modelview = state.getModelViewMatrix();
  const osg::Matrix projection = state.getProjectionMatrix();
 
   CODE REMOVED 
 
  bool doUpdate = atc._traversalNumber==-1;
  if (atc._traversalNumber=0)
  {
  if (atc._modelview!=modelview)
  {
   

Re: [osg-users] Speeding Up osgText?

2008-09-05 Thread Nick Bryan
Jeremy I didn't pick up on OSG until July this year so I'm very much a 
newbie.  I've spent time playing around and reading the newsgroup but 
have yet to do anything serious.  Having read up on Pango I'm pretty 
interested in your work and maybe i don't need to do anything - if only ;-)


Nick

Jeremy Moles wrote:

On Fri, 2008-09-05 at 22:53 +0100, Nick Bryan wrote:
  

Hi Ryan,
can't answer your question immediately but i am embarking on a lot of 
work around osgText so thanks for the heads up and the detailed post.  
I'll consider your points as i work through what i need to do.  Will 
obviously post feedback to the group.



I'd be very interested in know what and how and why you're doing
this. :)

I've been asking about some osgText for months to improve osgWidget, but
haven't really made any impressions I don't think (we're all pretty
busy, as it were).

As such, I have begun (and am almost finished!) writing an OSG NodeKit
called osgPango, which uses the Pango library to layout text, create
high-quality subpixel fonts renderings, etc. Whether or not anyone else
will be interested in it is hard to say, but I intend on using it for my
own purpose because I get superb font quality (even shadows and
outlines!) and a simplified API.

I had originally intended to just hack osgText, but the code is far too
complicated for me to grok. :) So I just ended up writing a different
NodeKit for it, which will be compaitble with osgWidget for sure (in the
form of osgPango::Label and osgPango::Input).

I have posted many times about osgText in the past, and if you would
like I can recall those links here for you to check out (particularly
with regards to quality--see osgfont--and the inability to insure that
all quads are pixel-aligned and that I can access the extents of each
text glyph individually for input...)

  

rgds
Nick

Kawicki, Ryan H wrote:


This is in reference to a previous question that has been posed.  Sorry
if this has already been addressed.

http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
008-April/009652.html

Our application seems to be hitting this same issue.  We are trying to
render quite a bit of text on the screen, and we seem to be getting
burned by both the setText( ... ) and the drawImplementation.

We are currently using an older version of OSG, but we are planning on
moving to 2.6.0 relatively soon.  I have looked at our current version
of osgText and the 2.6.0 version and can conclude that this will still
be an issue.

Our application is building the text shapes with SCREEN_COORDS for the
character size mode and SCREEN for axis alignment.

What I have noticed is that for each text shape update, the function
computeGlyphRepresentation is called to recompute the glyph information.
This function then calls the function computePositions.  Here is what
compute positions looks like.

void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());

// FIXME: OPTIMIZE: This would be one of the ideal locations to

// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)

for(unsigned int i=0;isize;++i)
{
 computePositions(i);
}
}

As can be seen by the first line, the maximum size is being obtained
from the maximum number of graphics contexts or the size of
_autoTransformCache.  For me this is set to 32, since the default was
never being changed.  The computePositions function is a very expensive
operation, and a minor flaw in our design was causing a huge impact in
performance.  It might be a good idea to either assert on or to check
the traversalNumber from the _autoTransformCache to make sure the
context is a valid one.

Performance is still down for our application.  I think some of the
problem is related to this computePositions function still.  Our
application is frequently setting text, so we incur a CPU hit to
recalculate all the glyph vertices.  When the text is visible, we incur
the same CPU hit to recalculate all the glyph vertices since the
_autoTransformCache model view matrix are always different between the
update of the text and the current state of the draw phase.  Here's the
draw implementation for text.

void Text::drawImplementation(osg::State state) const
{
unsigned int contextID = state.getContextID();

 CODE REMOVED 

if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
 CODE REMOVED 

AutoTransformCache atc = _autoTransformCache[contextID];
const osg::Matrix modelview = state.getModelViewMatrix();
const osg::Matrix projection = state.getProjectionMatrix();

 

[osg-users] Bug in osg text in certain circonstance

2008-09-05 Thread Cedric Pinson

Hi guys,
Strange bug with osgText, with the current configuration:

   std::string fontName = ../data/Vera.ttf;
   VarsEditor::instance()-get(fontPlayerName, fontName);
   osgText::Font* font = osgText::readFontFile(fontName.c_str());
   _seatNumber-setFont(font);
   _seatNumber-setCharacterSize(25);
   _seatNumber-setCharacterSizeMode(osgText::Text::SCREEN_COORDS);
   _seatNumber-setAlignment(osgText::Text::CENTER_CENTER);
   _seatNumber-setFontResolution(30,30);
   _seatNumber-setAxisAlignment(osgText::Text::SCREEN);
   std::stringstream ss;
   ss  Seat   data._seatNumber;
   _seatNumber-setText(ss.str());

I added a video because i don't how to explain it. A text should be 
display and it is not, it's a bit random, sometimes it works
sometime it does not. I dump the osg tree and the osgText was in the 
file, then if i re read the file with osgviewer it works.
I found a trick to make it display again in my application, moving the 
camera very near, then it appears. I don't have any idea appart accusing 
osgText.

I tried in SingleThreaded and the problem and it does not change.
I guess it's related to the camera position when i create the text. 
Because i susupect that, i tried a configuration


  std::string fontName = ../data/Vera.ttf;
   VarsEditor::instance()-get(fontPlayerName, fontName);
   osgText::Font* font = osgText::readFontFile(fontName.c_str());
   _seatNumber-setFont(font);
   _seatNumber-setCharacterSize(0.25);
//_seatNumber-setCharacterSizeMode(osgText::Text::SCREEN_COORDS);
   _seatNumber-setAlignment(osgText::Text::CENTER_CENTER);
   _seatNumber-setFontResolution(30,30);
   _seatNumber-setAxisAlignment(osgText::Text::SCREEN);
   std::stringstream ss;
   ss  Seat   data._seatNumber;
   _seatNumber-setText(ss.str());

So the character size mode is now the default, and with that i cant 
reproduce the bug. So last information i have is when i create the text 
the text is behind the camera
so maybe it does not help for the 
_seatNumber-setCharacterSizeMode(osgText::Text::SCREEN_COORDS) mode.


here the video http://www.plopbyte.net/tmp/osgText.ogg

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


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


[osg-users] ply or off model format

2008-09-05 Thread YangXiao
Hi 
 Can osg plugin  read .ply or off model format?
   
  Thanks.
   
  YangXiao. 

   
-
 雅虎邮箱,您的终生邮箱!___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org