Re: [osg-users] Just getting started

2007-10-19 Thread Robert Osfield
Hi Michael,

As Paul suggests, download and read the QuickStartGuide.  There are
also tutorials on the OSG websites.

I'd also recommending use OSG-2.2 as the book is based on 2.x, and the
build CMake system should be able to handle KDevelop.

Exceptions should be on unless you turn them off with modern C++
compilers.  There is no reason disable exceptions when using the OSG.
If an exception is thrown then its down to a bug that needs fixing.

Robert.

On 10/19/07, Michael W. Hall [EMAIL PROTECTED] wrote:
 I am new to OSG and I have just started playing with OSG.  I have
 checked out the website and have not had much luck figuring things out.
 Is there a good reference on-line someone can point me to?

 Also, I created a KDevelop project and was using the osgBluemarble
 example as a go by.  I added the following lines to my project:

 Producer::ref_ptrProducer::RenderSurface rs;
 rs = new Producer::RenderSurface;

 When I tried to compile the file, the compiler reported an error on line
 58 of /usr/local/include/Producer/Referenced.  Line 58 is as follows:

else if( _refCount0) throw 1;

 The error was exception handling was disabled use -fexceptions to turn
 on.

 Do I need to recompile OSG with this flag?  Any help is appreciated.

 ___
 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] Questions about Geometry implementation details

2007-10-19 Thread Christian Muschick
Robert Osfield wrote:
 Hi Ralf,
 
 Thanks for the clarification, I'm afraid my trip meant not following
 threads too closely.
 
 I've reviewed the code and the if (!array-getVertex..()) line is
 wrong, and Ulrich pointed to the correct implementation.
 
 I've fixed the relevant code and checked it into SVN.

Sorry to bother you again, but did you take a look at the other lines of 
code I pointed out? I think the same problem exists there.

line 1123:
if (!array-getVertexBufferObject()) vbo = array-getVertexBufferObject();

line 1170:
if (!array-getVertexBufferObject()) array-setVertexBufferObject(0);

line 1178:
if (!elements-getElementBufferObject()) 
elements-setElementBufferObject(0);

The ! should be removed in all three cases.

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


Re: [osg-users] Integration of OGL draw() method

2007-10-19 Thread Robert Balfour
And also I found good information that helped me figure this out in the
OSG Quick Start Guide and the OSG Reference Manual that I recently
purchased.  Good job Paul...  Every OSG'er should get themselves a copy
(even seasoned developers like me who have been using OSG for a number
of years).

Bob.




Vican, Justin E. wrote:
 
 Hi Bob,
 I've done this by deriving an osg::Drawable class, and overriding the
 drawImplementation method to call my OGL code.  I then stick this
 drawable in a osg::Geode and insert into the scenegraph.  This approach
 has worked equally well with hand coded legacy OGL code and with code
 generated by 3rd party OGL code generators like GLStudio.
 
 -Justin
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Paul
 Martz
 Sent: Friday, October 19, 2007 11:43 AM
 To: 'OpenSceneGraph Users'
 Subject: Re: [osg-users] Integration of OGL draw() method
 
 2. would work, and a variant on that is to derive your own Drawable and
 override drawImplementation() to issue your OpenGL calls. Again, you'd
 have
 to assign a max render bin number to the Drawable's StateSet.
-Paul
 
 
  I have some 3rd party OGL code that needs to draw (add some 2D/3D
  decorations) directly to the framebuffer after everything
  else is drawn (i.e. right before swapBuffers).
 
  What would be the best way to do this:
 
  1. add a call in Viewbase.cpp to call the 3rd party draw()
  method right before swapBuffers().
 
  2. a draw callback on a scenegraph node assigned to the
  highest number render bin.
 
  3. other ways?
 
  Thanks.
 
 
  Bob.
  --
  Robert E. Balfour, Ph.D.
  Exec. V.P.  CTO,  BALFOUR Technologies LLC 960 South
  Broadway, Suite 108, Hicksville NY 11801
  Phone: (516)513-0030  Fax: (516)513-0027  email: [EMAIL PROTECTED]
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
 negraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
 g
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
Robert E. Balfour, Ph.D.
Exec. V.P.  CTO,  BALFOUR Technologies LLC
960 South Broadway, Suite 108, Hicksville NY 11801
Phone: (516)513-0030  Fax: (516)513-0027  email: [EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Integration of OGL draw() method

2007-10-19 Thread Robert Balfour
That's what I tried, based on what Paul said, and it seems to be working
well.  Thanks...

Is there a #define for the highest number renderbin ?, or a safe
number to use?

Bob.
--


Vican, Justin E. wrote:
 
 Hi Bob,
 I've done this by deriving an osg::Drawable class, and overriding the
 drawImplementation method to call my OGL code.  I then stick this
 drawable in a osg::Geode and insert into the scenegraph.  This approach
 has worked equally well with hand coded legacy OGL code and with code
 generated by 3rd party OGL code generators like GLStudio.
 
 -Justin
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Paul
 Martz
 Sent: Friday, October 19, 2007 11:43 AM
 To: 'OpenSceneGraph Users'
 Subject: Re: [osg-users] Integration of OGL draw() method
 
 2. would work, and a variant on that is to derive your own Drawable and
 override drawImplementation() to issue your OpenGL calls. Again, you'd
 have
 to assign a max render bin number to the Drawable's StateSet.
-Paul
 
 
  I have some 3rd party OGL code that needs to draw (add some 2D/3D
  decorations) directly to the framebuffer after everything
  else is drawn (i.e. right before swapBuffers).
 
  What would be the best way to do this:
 
  1. add a call in Viewbase.cpp to call the 3rd party draw()
  method right before swapBuffers().
 
  2. a draw callback on a scenegraph node assigned to the
  highest number render bin.
 
  3. other ways?
 
  Thanks.
 
 
  Bob.
  --
  Robert E. Balfour, Ph.D.
  Exec. V.P.  CTO,  BALFOUR Technologies LLC 960 South
  Broadway, Suite 108, Hicksville NY 11801
  Phone: (516)513-0030  Fax: (516)513-0027  email: [EMAIL PROTECTED]
  ___
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Problem with new OpenScenGraph version 2.2.0

2007-10-19 Thread nguyen
Hi all,I just downloaded  the new Version 2.2.0 of OpenScenGraph. All libraries and examples (after fixing a syntax error in file examples/osgtext/osgtext.cpp) let successfully build on my x86 GNU/Linux machine. But almost examples only show a blank screen now.Env. OSG_FILE_PATH and LD_LIBRARY_PATH are correctly set. For example calling osgviewer cow.osg  or osggeometry, both examples show a blank screen with clear color.Unlike that it seams to be alrights with osgviewerQT cow.osg.I didnt have this problem with previous OpenScenGraph version 2.0. Many thanks for any ideas, whats the reason ?Son
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Texture subloading

2007-10-19 Thread Sewell, Kenneth R Civ USAF AFRL/RYZW
Gerrick,

If you can tolerate a few more questions...

 

Your UpdateTextureCallback class derives from
osg::Texture*D::SubloadCallback, is that correct?

What does your call to setSubloadCallback() look like?  Thanks.

 

Ken.

 

Right. I'm not sure when the subload callback is actually triggered but
you need a valid context so my first guess would be during the cull
traversal (anyone can correct me on this as I am just guessing). We
derive our own subloadCallback class that has a pointer to the texture 
data (that's the _tm-dataField reference below). Not sure how others
are doing it. To subload we have algorithms that trigger updating 
the pointer to the texture data.
biv



On 10/19/07, Sewell, Kenneth R Civ USAF AFRL/RYZW 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 
wrote:

Thanks for the response.  If you don't mind could you answer a couple
more questions?

What triggers the callbacks?  How/where is the new data to be subloaded
associated with the callback function?

 

Thanks.

 

Hi Ken, 
Basically you just need to setup a TextureSubloadCallback for your
specific type of texture(1D,2D,3D).
This allows you to override the load and subload methods that you would
encounter in gl. Then set the
subloadcallback to your texture using:

Texture*D::setSubloadCallback(SubloadCallback* sb);


Overrides are something like the following:
load:

 
void UpdateTextureCallback::load(const osg::Texture3D
texture,osg::State state )const
{
 
texture.getExtensions(state.getContextID(),false)-glTexImage3D(GL_TEXTU
RE_3D, 0,
  GL_RGBA, 
  _textureWidth,
  _textureHeight,
  _textureDepth,
  0, GL_RGBA, 
  GL_UNSIGNED_BYTE,
  (unsigned
char*)_tm-dataField);

}
and subload :

// 
void UpdateTextureCallback::subload(const osg::Texture3D
texture,osg::State state) const
{
 
texture.getExtensions(state.getContextID(),false)-glTexSubImage3D(GL_TE
XTURE_3D,
 0, 
 0,0,0,
 _textureWidth,
 _textureHeight,
 _textureDepth,
 GL_RGBA,
 GL_UNSIGNED_BYTE, 
 (unsigned char*)_tm-dataField);

}

You'll have to adjust this for your texture type (this is ours for 3D
textures) but this should give you a general idea.
biv

On 10/19/07, Sewell, Kenneth R Civ USAF AFRL/RYZW
[EMAIL PROTECTED] wrote:


Is there a good example of texture subloading in OSG?  I have a large
image and just want to replace small tiles of the texture.  Can anyone
give me a few starting pointers?


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

 


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

 

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


[osg-users] Performance Problems

2007-10-19 Thread Shawn Cook

Hi, Trying to do something simple and getting a poor framerate.  I'm sure it's 
just something I don't know about OSG and need to learn, perhaps you folks can 
help.  Basically, imagine a camera positioned above a grid with anywhere from 
100 to 5000 quads of similar size shuffling around on the 2D plane with the 
grid.  The position of each of these quads is controlled in real time by a 
seperate Java app via multicast.
 
My coworker is working on an identical project in parallel to mine on an 
identical laptop but is using Cocoa(Mac OS X 10.5) and straight OpenGL.  He is 
getting a framerate of 100+ frames per second with 500 quads while I cannot get 
more than 30fps with 500.  That framerate is acceptable, but eventually I would 
like to do more than just draw quads.  Instead, each quad will be a little 
tail of quads following a head around - like tracers or a little snake.  
Again, my coworker has done this already and is acheiving a similarly 
phenominal framerate - If I add just a couple quads my framerate drops.  What's 
the deal?  At first I was using a single geode, geometry object and vec3array 
for each quad and was getting an unusable framerate.  When I restructured with 
a single geode, geometry for the application and one large vec3array for all 
the quads my framerate got up to where it is now (acceptable, but slow when I 
add the tracers).
 
How can I acheive 100+ fps like my friend?
 
System info:
MacBook Pro 1,1
Windows XP (using Bootcamp)
1MB RAM
2GHz Dual Core
OpenSceneGraph 2.0.0
VRJuggler 2.0.3-1
 
Also, this is a VRJuggler/OpenSceneGraph application - perhaps if you guys 
can't help I'll hit up the VRJuggler mailing lists for some help.
 
Thanks folks,
S
_
Help yourself to FREE treats served up daily at the Messenger Café. Stop by 
today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] seamless perspectives with multiple (rotated/translated) osgViewer slaves

2007-10-19 Thread Robert Osfield
Hi Mike,

I'd recommend setting the master camera's projection matrix so it
fills one side of the cube, then have the slave cameras just rotate
from this.

Have a look at how the View::setUpViewFor3DSphericalDisplay method is
set up.  You won't need use render to texture of course or the final
slave camera that does the distortion correction.

Robert.

On 10/19/07, Mike Wozniewski [EMAIL PROTECTED] wrote:
 Hi All,

 I'm struggling to understand how to properly offset a slave in
 osgViewer, and still have the perspectives line up for tiled and
 CAVE-like displays.

 For example, I have one OSG window to render the left corner of a
 CAVE. The window has 2 cameras: The left camera has a viewport that
 covers the left half of the window and is rotated -90 degrees. The
 center camera has a viewport that covers the right half of the window
 and is not rotated.

 left camera:
 viewer.addSlave(camera.get(), pMatrix,
 osg::Matrix::rotate(osg::inDegrees(-90), 0,1,0));

 center camera:
 viewer.addSlave(camera.get(), pMatrix, osg::Matrix::());

 How do I compute the correct pMatrix to ensure that the frustums line up
 in a seamless fashion (ie, objects do not disappear or become duplicated)?

 Note that through trial and error, I have found a pMatrix that works:
 pMatrix = osg::Matrixd::scale( viewportWidthRatio * traits-width /
 3150, 1, 1 );

 But I don't understand why I have to scale by 3150? It seems that it's
 related to the size of the viewport... so in my case my full window
 width is 2048, so I have: 0.5 * 2048 / 3150 = 0.325. Why this value?

 Also, in case it's important, the master camera is attached to a
 NodeTrackerManipulator that I define like this:
 nodeTracker = new osgGA::NodeTrackerManipulator();
 nodeTracker-setTrackerMode(
 osgGA::NodeTrackerManipulator::NODE_CENTER_AND_ROTATION );
 nodeTracker-setRotationMode(
 osgGA::NodeTrackerManipulator::ELEVATION_AZIM );
 nodeTracker-setHomePosition(osg::Vec3d(0,0,0), osg::Vec3d(0,1,0),
 osg::Vec3d(0,0,1));

 The other question I have: what if the left view is not rotated, but
 planar to the center? ie, the eye looks directly forward through the
 center camera, and the left camera shows a translated and thus distorted
 view? What is the proper way to set my pMatrix for that? Obviously it's
 not just a scaling operation and requires skewing.

 Any insight would be greatly appreciated!

 Thanks in advance,
 -Mike Wozniewski
 ___
 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] Integration of OGL draw() method

2007-10-19 Thread Vican, Justin E.
Hi Bob,
I've done this by deriving an osg::Drawable class, and overriding the
drawImplementation method to call my OGL code.  I then stick this
drawable in a osg::Geode and insert into the scenegraph.  This approach
has worked equally well with hand coded legacy OGL code and with code
generated by 3rd party OGL code generators like GLStudio.

-Justin

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: Friday, October 19, 2007 11:43 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] Integration of OGL draw() method

2. would work, and a variant on that is to derive your own Drawable and
override drawImplementation() to issue your OpenGL calls. Again, you'd
have
to assign a max render bin number to the Drawable's StateSet.
   -Paul


 
 I have some 3rd party OGL code that needs to draw (add some 2D/3D
 decorations) directly to the framebuffer after everything 
 else is drawn (i.e. right before swapBuffers).
 
 What would be the best way to do this:
 
 1. add a call in Viewbase.cpp to call the 3rd party draw() 
 method right before swapBuffers().
 
 2. a draw callback on a scenegraph node assigned to the 
 highest number render bin.
 
 3. other ways?
 
 Thanks.
 
 
 Bob.
 --
 Robert E. Balfour, Ph.D.
 Exec. V.P.  CTO,  BALFOUR Technologies LLC 960 South 
 Broadway, Suite 108, Hicksville NY 11801
 Phone: (516)513-0030  Fax: (516)513-0027  email: [EMAIL PROTECTED] 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org

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


Re: [osg-users] Just getting started

2007-10-19 Thread Michael W. Hall
Thanks for the info.  I downloaded the guide and I was running version
1.2.  I just downloaded OSG 2.2 and I am in the process of installing
it.  

Again thanks and I am pretty sure I will have more questions as time
goes on.  Are the books mentioned on the site Paul gave me available in
books stores or are they only available on the site?

Michael

On Fri, 2007-10-19 at 07:41 +0100, Robert Osfield wrote:
 Hi Michael,
 
 As Paul suggests, download and read the QuickStartGuide.  There are
 also tutorials on the OSG websites.
 
 I'd also recommending use OSG-2.2 as the book is based on 2.x, and the
 build CMake system should be able to handle KDevelop.
 
 Exceptions should be on unless you turn them off with modern C++
 compilers.  There is no reason disable exceptions when using the OSG.
 If an exception is thrown then its down to a bug that needs fixing.
 
 Robert.
 
 On 10/19/07, Michael W. Hall [EMAIL PROTECTED] wrote:
  I am new to OSG and I have just started playing with OSG.  I have
  checked out the website and have not had much luck figuring things out.
  Is there a good reference on-line someone can point me to?
 
  Also, I created a KDevelop project and was using the osgBluemarble
  example as a go by.  I added the following lines to my project:
 
  Producer::ref_ptrProducer::RenderSurface rs;
  rs = new Producer::RenderSurface;
 
  When I tried to compile the file, the compiler reported an error on line
  58 of /usr/local/include/Producer/Referenced.  Line 58 is as follows:
 
 else if( _refCount0) throw 1;
 
  The error was exception handling was disabled use -fexceptions to turn
  on.
 
  Do I need to recompile OSG with this flag?  Any help is appreciated.
 
  ___
  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] Questions about Geometry implementation details

2007-10-19 Thread Christian Muschick
Robert Osfield wrote:
 Hi Christian,
 
 On 10/19/07, Christian Muschick [EMAIL PROTECTED] wrote:
 Sorry to bother you again, but did you take a look at the other lines of
 code I pointed out? I think the same problem exists there.

 line 1123:
 if (!array-getVertexBufferObject()) vbo = array-getVertexBufferObject();

 line 1170:
 if (!array-getVertexBufferObject()) array-setVertexBufferObject(0);

 line 1178:
 if (!elements-getElementBufferObject())
 elements-setElementBufferObject(0);
 
 No I didn't, I assumed it was just the line illustrated.  With
 problems like this its best to be explict, or ideally fix the code to
 what you think it shoudl be and then post a complete file for review,
 I then can do an graphical diff and spot exactly whats changed, what
 problems they address and any pattern involved.

I'll remember that for the next time. Your latest changes seem to fix 
the problems that I spotted, thanks.

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


[osg-users] Texture subloading

2007-10-19 Thread Sewell, Kenneth R Civ USAF AFRL/RYZW

Is there a good example of texture subloading in OSG?  I have a large
image and just want to replace small tiles of the texture.  Can anyone
give me a few starting pointers?


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


Re: [osg-users] Outputting Movies in OpenSceneGraph

2007-10-19 Thread David Callu
Hi Garrett

  A xine/Quicktime plugin is provide to read movie in OSG scene
 Take a look to osgmovie examples.

 But don't know any plugin to make a movie from an OSG Scene


David

2007/10/19, Garrett Potts [EMAIL PROTECTED]:

 Hello All:

 I have been perusing the source and examples and I was wondering if
 there was a way to output movies in an OSG Scene.  I know there are
 pbuffers and you can probably latch on to pbuffer generation after
 each framing and then couple to a movie generation library but I see
 that the osgDB has a nice plugin architecture for reading and writing
 and was wondering with the Movie based plugins if there was a way to
 feed a plugin (if one exists for movie writing) to output frames at
 given rate.  So basically init the plugin with some setup parameters
 and then start writing.  Has anyone ever researched this through a
 raw OSG implementation and not coupled to like a GUI or anything like
 that?

 Thank you all in advance for any help and time.

 Take care

 Garrett

 ___
 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] Making the composite window disappear

2007-10-19 Thread Robert Osfield
Hi Shadhidar,

On 10/19/07, Sashidhar Guntury [EMAIL PROTECTED] wrote:
   Oops, I forgot to mention that I'm not removing (i.e deleting)
 view variable. I actually tried that but since the destructor is protected,
 it would not work.

To delete just set all the ref_ptrView to 0 and it'll delete.

I suspect the reason why the removed View's cameras are still visiable
is that the view hasn't been deleted, and the cameras still have the
graphics window attached so are still being renderer by the graphics
window on each frame.

If you didn't hold a global to the View then it'd delete automatically
when you removed the View from the CompositeViewer and its associated
Camera would be deleted along with it, removing itself completely from
being associated with the GraphicsWindow.

If you want to keep the view around for future use then perhaps the
easiest way to do it would be to disable the View's camera by setting
its NodeMask to 0x0 i.e.

  view-getCamera()-setNodeMask(0x0);

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


Re: [osg-users] Making the composite window disappear

2007-10-19 Thread Sashidhar Guntury
Hi!

 I'm using the latest version of OSG (2.2) and yeah, the view is
defined as a global variable.

 These are the global variables I have defined.

osg::BoundingBox* bb;
osgViewer::CompositeViewer viewer;
osgViewer::View* topView;
osg::ref_ptrosg::GraphicsContext gc;
osg::ref_ptrosg::GraphicsContext::Traits traits;

 topView is the view I want to remove. It is added to viewer.

   thanks!

Bye
Sashidhar

On 10/19/07, Robert Osfield [EMAIL PROTECTED] wrote:

 Hi Sashidhar,

 Which version of the OSG are you using?  I did some work in the 2.1.x
 series to help make adding/removing views a bit more robust.

 You call of viewer.frame() is something that you should drop as the
 event handler you've written will be called from within frame, so you
 are in effect creating a loop that if one is not really careful will
 result in problems such as an infinite loop.  The call itself should
 be required as you are already within a frame.

 Do you have any global references to the View that you are removing?

 Robert.

 On 10/19/07, Sashidhar Guntury [EMAIL PROTECTED] wrote:
  Hi!
 
I'm using the composite viewer, to make a program wherein
 there
  are two views of the entire scene. The main view is spread across the
 screen
  while the other view lies in a corner. I want the the smaller view to
  disappear when I click on it (left click.)  My handle function is --
 
   bool handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapter
 aa)
  {
  osgViewer::View* view =
  dynamic_castosgViewer::View*(aa);
  if (!view) return false;
 
  if (ea.getEventType() ==
  osgGA::GUIEventAdapter::RELEASE){
  viewer.removeView(topView);
  viewer.frame();
  cout  Killed the map!!  endl;
  }
  return false;
  }
 
 But when I click on
  the smaller view, it prints Killed the map, but the view still remains
  there. Why does it happen that way? Isn't viewer.frame() supposed to
 display
  a completely new, updated frame?
 
  thanks
 
  Bye
  Sashidhar
 
  ___
  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] download osgProducer

2007-10-19 Thread Panagiotis Papadakos
Hi. You can download it from subversion repository with the following 
command:

svn checkout http://www.openscenegraph.org/svn/Producer/osgProducer/trunk 
osgProducer



Panagiotis Papadakos

On Fri, 19 Oct 2007, aurora restivo wrote:

 Hi!

 I need last release (source code) of osgProducer, because I can't find
 the link for download.

 Please help me!

 Aurora
 ___
 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] Making the composite window disappear

2007-10-19 Thread Robert Osfield
Hi Sashidhar,

Which version of the OSG are you using?  I did some work in the 2.1.x
series to help make adding/removing views a bit more robust.

You call of viewer.frame() is something that you should drop as the
event handler you've written will be called from within frame, so you
are in effect creating a loop that if one is not really careful will
result in problems such as an infinite loop.  The call itself should
be required as you are already within a frame.

Do you have any global references to the View that you are removing?

Robert.

On 10/19/07, Sashidhar Guntury [EMAIL PROTECTED] wrote:
 Hi!

   I'm using the composite viewer, to make a program wherein there
 are two views of the entire scene. The main view is spread across the screen
 while the other view lies in a corner. I want the the smaller view to
 disappear when I click on it (left click.)  My handle function is --

  bool handle(const osgGA::GUIEventAdapter ea,osgGA::GUIActionAdapter aa)
 {
 osgViewer::View* view =
 dynamic_castosgViewer::View*(aa);
 if (!view) return false;

 if (ea.getEventType() ==
 osgGA::GUIEventAdapter::RELEASE){
 viewer.removeView(topView);
 viewer.frame();
 cout  Killed the map!!  endl;
 }
 return false;
 }

But when I click on
 the smaller view, it prints Killed the map, but the view still remains
 there. Why does it happen that way? Isn't viewer.frame() supposed to display
 a completely new, updated frame?

 thanks

 Bye
 Sashidhar

 ___
 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] glew and graphics contexts

2007-10-19 Thread Wills Alan
It has thread-safe support for multiple contexts as of v1.2.0. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: 19 October 2007 09:11
To: OpenSceneGraph Users
Subject: Re: [osg-users] glew and graphics contexts

Hi Wills,

On 10/19/07, Wills Alan [EMAIL PROTECTED] wrote:
 Thanks for the reply. To answer your question, glew is being used by a 
 3rd-party library which I can't modify and which I'm integrating with my OSG 
 stuff so I have to accommmodate it.

Does GLEW support multiple graphics contexts?  Under Windows the API
entry points can be different for each graphics context so function
pointers need to be done per graphics context.

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

The information contained in this E-Mail and any subsequent 
correspondence is private and is intended solely for the intended 
recipient(s).  The information in this communication may be 
confidential and/or legally privileged.  Nothing in this e-mail is 
intended to conclude a contract on behalf of QinetiQ or make QinetiQ 
subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase 
Order.

For those other than the recipient any disclosure, copying, 
distribution, or any action taken or omitted to be taken in reliance 
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be 
monitored and recorded for business purposes including security, audit 
and archival purposes.  Any response to this email indicates consent 
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality 
control, security and other business purposes.

QinetiQ Limited
Registered in England  Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, 
Hampshire, GU14 0LX, United Kingdom 
http://www.QinetiQ.com/home/legal.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] glew and graphics contexts

2007-10-19 Thread Robert Osfield
Hi Wills,

On 10/19/07, Wills Alan [EMAIL PROTECTED] wrote:
 Thanks for the reply. To answer your question, glew is being used by a 
 3rd-party library which I can't modify and which I'm integrating with my OSG 
 stuff so I have to accommmodate it.

Does GLEW support multiple graphics contexts?  Under Windows the API
entry points can be different for each graphics context so function
pointers need to be done per graphics context.

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


Re: [osg-users] glew and graphics contexts

2007-10-19 Thread Wills Alan
Hi Robert,

Thanks for the reply. To answer your question, glew is being used by a 
3rd-party library which I can't modify and which I'm integrating with my OSG 
stuff so I have to accommmodate it.

Thanks,
Alan.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: 18 October 2007 19:14
To: OpenSceneGraph Users
Subject: Re: [osg-users] glew and graphics contexts

Hi Wills,

Since osgViewer by default will multi-thread the main thread calling
the realize() won't be the graphics thread so your glew call will
fail.

If you want to init glew then do it in a realize operation - see
osgshaderterrain for an example of this.

I have to ask way are you trying to use glew?  The OSG manages
extensions checking all itself and in a way that is thread safe and
robust w.r.t multiple graphics contexts.

Robert.

On 10/18/07, Wills Alan [EMAIL PROTECTED] wrote:


 If I have the following ...

 // ..create traits ...
 osg::GraphicsContext* gc =
 osg::GraphicsContext::createGraphicsContext(traits);
 gc-realize();
 gc-makeCurrent();

 GLenum err = glewInit();

 if (err != GL_OK)
 // error msg.
 else
 // ok

 ... then all is well.  But if I do ...

 osgViewer::Viewer viewer.
 viewer.setUpViewOnSingleScreen(0);
 viewer.realize();


 GLenum err = glewInit();

 if (err != GL_OK)
 // error msg.
 else
 // ok

 I get an error:  Missing GL version

 I'm checking the viewer's graphics context by doing

 std::vectorosg::GraphicsContext* contexts;
 viewer-getContexts(contexts);

 with results:
 contexts.size() = 1;
 contexts[0]-isRealized() = 1;
 contexts[0]-isCurrent() = 1;

 but glewInit() returns an error.  What have I missed?

 Thanks,
 Alan.


 The information contained in this E-Mail and any subsequent
 correspondence is private and is intended solely for the intended
 recipient(s).  The information in this communication may be
 confidential and/or legally privileged.  Nothing in this e-mail is
 intended to conclude a contract on behalf of QinetiQ or make QinetiQ
 subject to any other legally binding commitments, unless the e-mail
 contains an express statement to the contrary or incorporates a formal
 Purchase Order.

 For those other than the recipient any disclosure, copying,
 distribution, or any action taken or omitted to be taken in reliance
 on such information is prohibited and may be unlawful.

 Emails and other electronic communication with QinetiQ may be
 monitored and recorded for business purposes including security, audit
 and archival purposes.  Any response to this email indicates consent
 to this.

 Telephone calls to QinetiQ may be monitored or recorded for quality
 control, security and other business purposes.

 QinetiQ Limited
 Registered in England  Wales: Company Number:3796233
 Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
 Trading address: Cody Technology Park, Cody Building, Ively Road,
 Farnborough, Hampshire, GU14 0LX, United Kingdom
 http://www.QinetiQ.com/home/legal.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

The information contained in this E-Mail and any subsequent 
correspondence is private and is intended solely for the intended 
recipient(s).  The information in this communication may be 
confidential and/or legally privileged.  Nothing in this e-mail is 
intended to conclude a contract on behalf of QinetiQ or make QinetiQ 
subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase 
Order.

For those other than the recipient any disclosure, copying, 
distribution, or any action taken or omitted to be taken in reliance 
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be 
monitored and recorded for business purposes including security, audit 
and archival purposes.  Any response to this email indicates consent 
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality 
control, security and other business purposes.

QinetiQ Limited
Registered in England  Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, 
Hampshire, GU14 0LX, United Kingdom 
http://www.QinetiQ.com/home/legal.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Questions about Geometry implementation details

2007-10-19 Thread Ralph Kern
Robert Osfield schrieb:
 On 10/19/07, Ulrich Hertlein [EMAIL PROTECTED] wrote:
 Hello Christian,

 Quoting Christian Muschick [EMAIL PROTECTED]:
 My last request concerning this question didn't get any reply, so let me
 try this reformulated version:
 ...
  osg::Array* array = *vitr;
  if (!array-getVertexBufferObject()) vbo =
 array-getVertexBufferObject(); /// This will only set vbo to NULL!?
  }

  if (!vbo) vbo = new osg::VertexBufferObject;
 }

 In the loop, vbo will never get a value different from the null-pointer.
 Is this on purpose? Did I miss something entirely?
 This certainly looks like a type to me too (copy-and-paste anti-pattern).
 I assume it should read 'if(array-getVertexBufferObject())...' so that if 
 the
 array has a VBO associated it's used.

 But I guess in the end Robert has to check that.
 
 I'm rather lost on this topic as I've just spotted this single email
 on its own, which bit of OSG code are we talking about?
 
 Robert.

from the original post:

In Geometry.cpp, there are several lines of code that don't make sense
to me. More precisely, the conditions in a few if-statements seem to be
incorrect.
As an example, in Geometry::getOrCreateVertexBuffer, it says
{
 ArrayList arrayList;
 getArrayList(arrayList);

 osg::VertexBufferObject* vbo = 0;

 ArrayList::iterator vitr;
 for(vitr = arrayList.begin();
 vitr != arrayList.end()  !vbo;
 ++vitr)
 {
 osg::Array* array = *vitr;
 if (!array-getVertexBufferObject()) vbo =
array-getVertexBufferObject(); /// This will only set vbo to NULL!?
 }

 if (!vbo) vbo = new osg::VertexBufferObject;
}

regards Ralph

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


Re: [osg-users] Integration of OGL draw() method

2007-10-19 Thread Paul Martz
Thanks for the positive feedback on the books. A Ref Man for v2.2 is in the
works.

I'd say MAXINT is your best bet for the last RenderBin.

Another thing to keep in mind is that multiple cameras could render to the
same window. If there's a second camera, even setting MAXINT on a bin in the
first camera won't help.

So, how things like HUDs are typically done is with a second camera drawing
to the same window, with the draw order specified so that it always goes
last. Something for you to consider.
   -Paul


 
 That's what I tried, based on what Paul said, and it seems to 
 be working well.  Thanks...
 
 Is there a #define for the highest number renderbin ?, or a 
 safe number to use?
 
 Bob.
 --
 
 
 Vican, Justin E. wrote:
  
  Hi Bob,
  I've done this by deriving an osg::Drawable class, and 
 overriding the 
  drawImplementation method to call my OGL code.  I then stick this 
  drawable in a osg::Geode and insert into the scenegraph.  This 
  approach has worked equally well with hand coded legacy OGL 
 code and 
  with code generated by 3rd party OGL code generators like GLStudio.
  
  -Justin
  
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] On 
 Behalf Of Paul 
  Martz
  Sent: Friday, October 19, 2007 11:43 AM
  To: 'OpenSceneGraph Users'
  Subject: Re: [osg-users] Integration of OGL draw() method
  
  2. would work, and a variant on that is to derive your own Drawable 
  and override drawImplementation() to issue your OpenGL 
 calls. Again, 
  you'd have to assign a max render bin number to the Drawable's 
  StateSet.
 -Paul
  
  
   I have some 3rd party OGL code that needs to draw (add some 2D/3D
   decorations) directly to the framebuffer after everything else is 
   drawn (i.e. right before swapBuffers).
  
   What would be the best way to do this:
  
   1. add a call in Viewbase.cpp to call the 3rd party draw() method 
   right before swapBuffers().
  
   2. a draw callback on a scenegraph node assigned to the highest 
   number render bin.
  
   3. other ways?
  
   Thanks.
  
  
   Bob.
   --
   Robert E. Balfour, Ph.D.
   Exec. V.P.  CTO,  BALFOUR Technologies LLC 960 South Broadway, 
   Suite 108, Hicksville NY 11801
   Phone: (516)513-0030  Fax: (516)513-0027  email: [EMAIL PROTECTED] 
   ___
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org

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


Re: [osg-users] Texture subloading

2007-10-19 Thread Sewell, Kenneth R Civ USAF AFRL/RYZW
Thanks for the response.  If you don't mind could you answer a couple
more questions?

What triggers the callbacks?  How/where is the new data to be subloaded
associated with the callback function?

 

Thanks.

 

Hi Ken, 
Basically you just need to setup a TextureSubloadCallback for your
specific type of texture(1D,2D,3D).
This allows you to override the load and subload methods that you would
encounter in gl. Then set the
subloadcallback to your texture using:

Texture*D::setSubloadCallback(SubloadCallback* sb);


Overrides are something like the following:
load:

 
void UpdateTextureCallback::load(const osg::Texture3D
texture,osg::State state )const
{
 
texture.getExtensions(state.getContextID(),false)-glTexImage3D(GL_TEXTU
RE_3D, 0,
  GL_RGBA, 
  _textureWidth,
  _textureHeight,
  _textureDepth,
  0, GL_RGBA, 
  GL_UNSIGNED_BYTE,
  (unsigned
char*)_tm-dataField);

}
and subload :

// 
void UpdateTextureCallback::subload(const osg::Texture3D
texture,osg::State state) const
{
 
texture.getExtensions(state.getContextID(),false)-glTexSubImage3D(GL_TE
XTURE_3D,
 0, 
 0,0,0,
 _textureWidth,
 _textureHeight,
 _textureDepth,
 GL_RGBA,
 GL_UNSIGNED_BYTE, 
 (unsigned char*)_tm-dataField);

}

You'll have to adjust this for your texture type (this is ours for 3D
textures) but this should give you a general idea.
biv

On 10/19/07, Sewell, Kenneth R Civ USAF AFRL/RYZW
[EMAIL PROTECTED] wrote:


Is there a good example of texture subloading in OSG?  I have a large
image and just want to replace small tiles of the texture.  Can anyone
give me a few starting pointers?


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

 

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


Re: [osg-users] shadows and LOD scale

2007-10-19 Thread Terry Welsh
Hi Robert,
My own PSSM code and osgshadow both exhibit this problem.  The code
you wrote that makes shadow cameras measure LOD distances from the
main camera's position works fine... until you introduce a LOD scale
on the main camera.  The shadow cameras keep using a LOD scale of 1.0
instead of using the LOD scale that you set on the main camera.

I am able to work around the problem by explicitly setting the LOD
scale on all of my shadow cameras, but this won't work for people
using osgshadow unless they are given access to all of its shadow
cameras.
- Terry

 Message: 10
 Date: Fri, 19 Oct 2007 07:16:08 +0100
 From: Robert Osfield [EMAIL PROTECTED]
 Subject: Re: [osg-users] shadows and LOD scale
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Message-ID:
 [EMAIL PROTECTED]
 Content-Type: text/plain; charset=ISO-8859-1

 Hi Terry,

 I have played with LODScale at the present osgShadow techniques, but
 the concept of EyePoint and ViewPoint methods in NodeVistor are
 intended to help with this issue - it was written in response to your
 original request for such a feature when you did your original PSSM
 code.  I can't recall the details off the top of my head, so could you
 check you old PSSM code and compare to the osgShadow techniques?

 Robert.

 On 10/18/07, Terry Welsh [EMAIL PROTECTED] wrote:
  Hi Robert,
  Remember the View class and the code you wrote so that Cameras for
  shadows could inherit the same LOD information as the user's eyepoint?
   I believe this is a related issue.  LODScale set for the main
  eyepoint does not appear to be used by the shadow cameras, causing
  shadows to not match the objects that cast them if the objects have
  multiple levels of detail.
 
  So far I have looked over the code for View, Camera, and CullSettings
  with no luck.  _inheritanceMask in CullSettings defaults to
  ALL_VARIABLES, so I would expect LODScale to be inherited properly.
  Not sure where else to look for this problem.  Any ideas?
 
  This problem is easy to demonstrate by adding this line to osgshadow.cpp
 
  viewer.getCamera()-setLODScale(10.0f);
 
  and then running with a model that has some LOD nodes in it.
  - Terry
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Texture subloading

2007-10-19 Thread Gerrick Bivins
Hi Ken,
Basically you just need to setup a TextureSubloadCallback for your specific
type of texture(1D,2D,3D).
This allows you to override the load and subload methods that you would
encounter in gl. Then set the
subloadcallback to your texture using:

Texture*D::setSubloadCallback(SubloadCallback* sb);


Overrides are something like the following:
load:

void UpdateTextureCallback::load(const osg::Texture3D texture,osg::State
state )const
{
  
texture.getExtensions(state.getContextID(),false)-glTexImage3D(GL_TEXTURE_3D,
0,
  GL_RGBA,
  _textureWidth,
  _textureHeight,
  _textureDepth,
  0, GL_RGBA,
  GL_UNSIGNED_BYTE,
  (unsigned char*)_tm-dataField);

}
and subload :
//
void UpdateTextureCallback::subload(const osg::Texture3D
texture,osg::State state) const
{
 texture.getExtensions(state.getContextID
(),false)-glTexSubImage3D(GL_TEXTURE_3D,
 0,
 0,0,0,
 _textureWidth,
 _textureHeight,
 _textureDepth,
 GL_RGBA,
 GL_UNSIGNED_BYTE,
 (unsigned char*)_tm-dataField);

}

You'll have to adjust this for your texture type (this is ours for 3D
textures) but this should give you a general idea.
biv
On 10/19/07, Sewell, Kenneth R Civ USAF AFRL/RYZW 
[EMAIL PROTECTED] wrote:


 Is there a good example of texture subloading in OSG?  I have a large
 image and just want to replace small tiles of the texture.  Can anyone
 give me a few starting pointers?


 Ken.
 ___
 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] Outputting Movies in OpenSceneGraph

2007-10-19 Thread Vican, Justin E.
Hi Garret, Hi David,

I ran into the same issue a few months ago.  The solution I ended up
with was frame grabbing during each cycle.  Afterwards, I strung the
frames back together into MOV/AVI/MPG movies with FFMPEG.  It works, but
it will probably drop your frame rate significantly.  I was able to slow
down the data stream feeding my OSG application to ensure that I grabbed
enough frames to generate a decent quality video.

 

I believe that FFMPEG is open source, so a movie maker plugin could be
built on top of it.  Just a thought.

 

Justin

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Callu
Sent: Friday, October 19, 2007 9:48 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Outputting Movies in OpenSceneGraph

 

Hi Garrett

  A xine/Quicktime plugin is provide to read movie in OSG scene
 Take a look to osgmovie examples.

 But don't know any plugin to make a movie from an OSG Scene


David

2007/10/19, Garrett Potts [EMAIL PROTECTED]:

Hello All:

I have been perusing the source and examples and I was wondering if
there was a way to output movies in an OSG Scene.  I know there are
pbuffers and you can probably latch on to pbuffer generation after 
each framing and then couple to a movie generation library but I see
that the osgDB has a nice plugin architecture for reading and writing
and was wondering with the Movie based plugins if there was a way to
feed a plugin (if one exists for movie writing) to output frames at
given rate.  So basically init the plugin with some setup parameters
and then start writing.  Has anyone ever researched this through a
raw OSG implementation and not coupled to like a GUI or anything like 
that?

Thank you all in advance for any help and time.

Take care

Garrett

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

 

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


Re: [osg-users] Questions about Geometry implementation details

2007-10-19 Thread Robert Osfield
Hi Christian,

I've done a check through the code and changed where I think there are
issues - 4 more beyond the one I fixed earlier.  I've checked these
changes in.

The changes I've made can be seen on the Tracs revision log:

http://www.openscenegraph.org/projects/osg/log/OpenSceneGraph/trunk/src/osg/Geometry.cpp

Could you check the code over and see if I've finally licked this copy
and paste bugs.

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


Re: [osg-users] Questions about Geometry implementation details

2007-10-19 Thread Robert Osfield
Hi Christian,

On 10/19/07, Christian Muschick [EMAIL PROTECTED] wrote:
 Sorry to bother you again, but did you take a look at the other lines of
 code I pointed out? I think the same problem exists there.

 line 1123:
 if (!array-getVertexBufferObject()) vbo = array-getVertexBufferObject();

 line 1170:
 if (!array-getVertexBufferObject()) array-setVertexBufferObject(0);

 line 1178:
 if (!elements-getElementBufferObject())
 elements-setElementBufferObject(0);

No I didn't, I assumed it was just the line illustrated.  With
problems like this its best to be explict, or ideally fix the code to
what you think it shoudl be and then post a complete file for review,
I then can do an graphical diff and spot exactly whats changed, what
problems they address and any pattern involved.

Cheers,
Robert.

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


Re: [osg-users] Questions about Geometry implementation details

2007-10-19 Thread Robert Osfield
Hi Ralf,

Thanks for the clarification, I'm afraid my trip meant not following
threads too closely.

I've reviewed the code and the if (!array-getVertex..()) line is
wrong, and Ulrich pointed to the correct implementation.

I've fixed the relevant code and checked it into SVN.

Robert.

On 10/19/07, Ralph Kern [EMAIL PROTECTED] wrote:
 Robert Osfield schrieb:
  On 10/19/07, Ulrich Hertlein [EMAIL PROTECTED] wrote:
  Hello Christian,
 
  Quoting Christian Muschick [EMAIL PROTECTED]:
  My last request concerning this question didn't get any reply, so let me
  try this reformulated version:
  ...
   osg::Array* array = *vitr;
   if (!array-getVertexBufferObject()) vbo =
  array-getVertexBufferObject(); /// This will only set vbo to NULL!?
   }
 
   if (!vbo) vbo = new osg::VertexBufferObject;
  }
 
  In the loop, vbo will never get a value different from the null-pointer.
  Is this on purpose? Did I miss something entirely?
  This certainly looks like a type to me too (copy-and-paste anti-pattern).
  I assume it should read 'if(array-getVertexBufferObject())...' so that if 
  the
  array has a VBO associated it's used.
 
  But I guess in the end Robert has to check that.
 
  I'm rather lost on this topic as I've just spotted this single email
  on its own, which bit of OSG code are we talking about?
 
  Robert.

 from the original post:

 In Geometry.cpp, there are several lines of code that don't make sense
 to me. More precisely, the conditions in a few if-statements seem to be
 incorrect.
 As an example, in Geometry::getOrCreateVertexBuffer, it says
 {
  ArrayList arrayList;
  getArrayList(arrayList);

  osg::VertexBufferObject* vbo = 0;

  ArrayList::iterator vitr;
  for(vitr = arrayList.begin();
  vitr != arrayList.end()  !vbo;
  ++vitr)
  {
  osg::Array* array = *vitr;
  if (!array-getVertexBufferObject()) vbo =
 array-getVertexBufferObject(); /// This will only set vbo to NULL!?
  }

  if (!vbo) vbo = new osg::VertexBufferObject;
 }

 regards Ralph

 ___
 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] ConvertToInventor.cpp compilation error

2007-10-19 Thread J.P. Delport
Hi,

maybe try

#include assert.h
in the ConvertToInventor.cpp file

jp

rck jobs wrote:
 Hello,
 
 I'm installing  OpenSceneGraph-2.2 under my Debian Sarge (Pentium III - 
 i386) server and I'm having a compilation error on file 
 ConvertToInventor.cpp .
 
 I was reading the mailing list and i don't understood what to do exactly 
 about the ConvertToInventor.cpp or CMakeLists.txt files.
 
 My erros are:
 
 /usr/local/OpenSceneGraph/src
 /osgPlugins/Inventor/ConvertToInventor.cpp: In
destructor `virtual ConvertToInventor::~ConvertToInventor()':
 /usr/local/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:189: 
 error: `
assert' undeclared (first use this function)
 /usr/local/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:189: 
 error: (Each
undeclared identifier is reported only once for each function it appears
in.)
 /usr/local/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp: In
function `void processIndices(const osg::Array*, const osg::Array*,
SoMFInt32, int, int, int)':
 /usr/local/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:513: 
 error: `
assert' undeclared (first use this function)
 /usr/local/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp: In
function `void postProcessField(const SbIntList, 
 osg::PrimitiveSet::Mode,
SoMFInt32*, osg::Geometry::AttributeBinding)':
 /usr/local/OpenSceneGraph/src/osgPlugins/Inventor/ConvertToInventor.cpp:588: 
 error: `
assert' undeclared (first use this function)
 
 and some other like those. I'm completely with no ideias to how solve 
 this problem. I'd be grateful with any suggestion.
 
 Thanks!
 
 Roberto
 
 
 
 
 ___
 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] Statistics meaning clarification

2007-10-19 Thread Robert Osfield
Hi Paul,

You understanding of stats is spot on.  GPU is simple the Graphics
Process Units time to complete the frame.

The writing out to file when pressing 'o' is no longer supported as
osgViewer doesn't hardwire this in like osgProducer did.
osgProducer::Viewer was an everything and the kitchen sink viewer,
whereas osgViewer::View(er) takes the opposite approach - no extra
event handlers unless you add them.   If you want to write out to file
then simply just add an custom EventHandler to do this.

On 10/19/07, Paul Pocock [EMAIL PROTECTED] wrote:
 In regards to osg stats I understand the following to mean:
-
Frame Rate  - in /Hz
-
Event - Event traversal
-
Update =96 The update thread updates a node of the scenegraph,update
traversal performed once each frame.
-
Cull -time taken in milliseconds for the cull traversal thread to
complete
-
Draw - ime taken in milliseconds for the draw traversal thread to
complete
-


GPU -  ?

   Could someone confirm this for me ?

 Another Question:  Where has the functionality gone to dump any loaded
 scenes to .osg . you used to be able to hit the
 'o' key to perform that function - not any more.

 Best Regards
 Paul

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


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


Re: [osg-users] OSG in non-continuous rendering

2007-10-19 Thread Robert Osfield
Hi Faraz,

W.r.t continous (frame driven) vs events driven, the OSG can do both,
as its up to your app to call Viewer::frame() (unless you use the high
level Viewer::run to run the frame loop).   The main problem with
going event driven is that animations won't update continously and any
database paging would become rather slow - if you don't use either of
these it should be fine for an interactive app.

W.r.t coordinate system just place a MatrixTransform above you models
to place them in large coord system.  The models should have a local
origin to keep floats nice a small.

Robert.

On 10/19/07, Faraz Ravi [EMAIL PROTECTED] wrote:




 Hi All



 I'm taking a look at OSG and I really like what it offers. I am looking to
 possibly use it in a CAD like environment where it is windowed and there is
 no continuous rendering loop. Rendering is performed as and when it is
 required, for example if the viewpoint is changed. This is important since
 the scene may take 0.5s or more to render and is degraded for higher fps
 during movement.



 I've adapted the fltk example to test this and it seems to work fine. So
 what I wanted to know is:



 1.   Does OSG have any internal dependencies on a continuous rendering
 loop?

 2.   Are there any known uses of OSG like this, or in a similar
 environment?

 3.   Is there anything else I need to be aware of if I am doing this?



 Note that when there is a continuous rendering loop in the fltk example the
 UI performance is hit badly, ie menus slow down and so on – it would also
 hit any CPU processes so this is not really a realistic model for my
 application.



 I noticed osgDirector uses a continuous loop with wxWidgets, seems to work
 quite well. I guess its rendering in another thread.



 On a different note does anyone know what method OSG uses to manage
 coordinate truncation / scaling issues when dealing with the teapot in the
 desert like scenario? Does it performance multiple passes or is there a
 different coordinate frame for each scale? Lets say I wanted to show a
 building in a large landscape without losing coordinate precision in the
 building for example.





 Thanks for any help



 Faraz
















 ___
 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] Outputting Movies in OpenSceneGraph

2007-10-19 Thread Garrett Potts

Hello y'all:

Thank you for the feedback.  I will look into the FFMPEG source and  
see what we can do.



Thank you again

Take care

Garrett

On Oct 19, 2007, at 11:19 AM, Vican, Justin E. wrote:


Hi Garret, Hi David,

I ran into the same issue a few months ago.  The solution I ended  
up with was frame grabbing during each cycle.  Afterwards, I strung  
the frames back together into MOV/AVI/MPG movies with FFMPEG.  It  
works, but it will probably drop your frame rate significantly.  I  
was able to slow down the data stream feeding my OSG application to  
ensure that I grabbed enough frames to generate a decent quality  
video.




I believe that FFMPEG is open source, so a movie maker plugin could  
be built on top of it.  Just a thought.




Justin



From: [EMAIL PROTECTED] [mailto:osg-users- 
[EMAIL PROTECTED] On Behalf Of David Callu

Sent: Friday, October 19, 2007 9:48 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Outputting Movies in OpenSceneGraph



Hi Garrett

  A xine/Quicktime plugin is provide to read movie in OSG scene
 Take a look to osgmovie examples.

 But don't know any plugin to make a movie from an OSG Scene


David

2007/10/19, Garrett Potts [EMAIL PROTECTED]:

Hello All:

I have been perusing the source and examples and I was wondering if
there was a way to output movies in an OSG Scene.  I know there are
pbuffers and you can probably latch on to pbuffer generation after
each framing and then couple to a movie generation library but I see
that the osgDB has a nice plugin architecture for reading and writing
and was wondering with the Movie based plugins if there was a way to
feed a plugin (if one exists for movie writing) to output frames at
given rate.  So basically init the plugin with some setup parameters
and then start writing.  Has anyone ever researched this through a
raw OSG implementation and not coupled to like a GUI or anything like
that?

Thank you all in advance for any help and time.

Take care

Garrett

___
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] seamless perspectives with multiple (rotated/translated) osgViewer slaves

2007-10-19 Thread Mike Wozniewski
Hi All,

I'm struggling to understand how to properly offset a slave in 
osgViewer, and still have the perspectives line up for tiled and 
CAVE-like displays.

For example, I have one OSG window to render the left corner of a 
CAVE. The window has 2 cameras: The left camera has a viewport that 
covers the left half of the window and is rotated -90 degrees. The 
center camera has a viewport that covers the right half of the window 
and is not rotated.

left camera:
viewer.addSlave(camera.get(), pMatrix, 
osg::Matrix::rotate(osg::inDegrees(-90), 0,1,0));

center camera:
viewer.addSlave(camera.get(), pMatrix, osg::Matrix::());

How do I compute the correct pMatrix to ensure that the frustums line up 
in a seamless fashion (ie, objects do not disappear or become duplicated)?

Note that through trial and error, I have found a pMatrix that works:
pMatrix = osg::Matrixd::scale( viewportWidthRatio * traits-width / 
3150, 1, 1 );

But I don't understand why I have to scale by 3150? It seems that it's 
related to the size of the viewport... so in my case my full window 
width is 2048, so I have: 0.5 * 2048 / 3150 = 0.325. Why this value?

Also, in case it's important, the master camera is attached to a 
NodeTrackerManipulator that I define like this:
nodeTracker = new osgGA::NodeTrackerManipulator();
nodeTracker-setTrackerMode( 
osgGA::NodeTrackerManipulator::NODE_CENTER_AND_ROTATION );
nodeTracker-setRotationMode( 
osgGA::NodeTrackerManipulator::ELEVATION_AZIM );
nodeTracker-setHomePosition(osg::Vec3d(0,0,0), osg::Vec3d(0,1,0), 
osg::Vec3d(0,0,1));

The other question I have: what if the left view is not rotated, but 
planar to the center? ie, the eye looks directly forward through the 
center camera, and the left camera shows a translated and thus distorted 
view? What is the proper way to set my pMatrix for that? Obviously it's 
not just a scaling operation and requires skewing.

Any insight would be greatly appreciated!

Thanks in advance,
-Mike Wozniewski
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Transparency problem

2007-10-19 Thread André Rocha
So the solution to the transparency sorting problem is simply to separate
the objects with transparency and those without? In example, I have a
opaque  building with transparent windows in one single object, so I need to
make the windows a separate object before exporting?

[ ]´s

2007/10/18, Christophe Medard [EMAIL PROTECTED]:

 For your information my problem of transparency was dut to a point
 graphists
 must be careful of in 3DSMax :
 the OSGEXp exporter places a drawable or a geode in the TRANSPARENT_BIN as
 soon as at least one face has transparency.
 It's a perfeclty reasonable behaviour.

 In my case, trees (transparent) and some terrain (opaque) parts were in
 the
 same object : that give rise to sorting problems between the trees and the
 very parts of terrain. Having the graphist look over and rectify it, the
 order of rendering is perfect now.

 Thanks to Robert for pointing out that direction of verification !  ;)

 --
 Christophe Médard
 Société OKTAL (http://www.oktal.fr)
 2 impasse Boudeville
 31100 Toulouse (France)
 Tél. : (+33) 5 62 11 50 10
 Fax : (+33) 5 62 11 50 29



 - Original Message -
 From: Robert Osfield [EMAIL PROTECTED]
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Sent: Friday, September 28, 2007 9:34 AM
 Subject: Re: [osg-users] Transparency problem


 Hi Christophe,

 I have seem problems like in your screenshot when items like roads and
 grass are placed incorrectly into the transparent bin, or the items
 like the trees are placed in the opaque bin.

 Robert.


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




-- 
André Rocha Tomasi
GRV - Virtual Reality Group
PUCRS - Projeto Aeromóvel
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] OSG in non-continuous rendering

2007-10-19 Thread Ralph Kern
Faraz Ravi schrieb:
 1.   Does OSG have any internal dependencies on a continuous
 rendering loop?
 

For a static scene in a CAD environment, the answer is 'no'. Continuous
rendering is needed for the immersion effect for VR systems, so for a
smooth animation or smooth camera movements. For animation, OSG has an
internal notion of frame time.

 2.   Are there any known uses of OSG like this, or in a similar
 environment?
 
 3.   Is there anything else I need to be aware of if I am doing this?

Look out for window repaint events. You need to rerender your scene
then, or you have to buffer your rendering output using FBO's or pbuffers.

 
 On a different note does anyone know what method OSG uses to manage
 coordinate truncation / scaling issues when dealing with the teapot in
 the desert like scenario? Does it performance multiple passes or is
 there a different coordinate frame for each scale? Lets say I wanted to
 show a building in a large landscape without losing coordinate precision
 in the building for example.
 

Geometry is internally processed in float precision by most OpenGL
implementations, but transformations are double precision. So put your
geometry in local coordinate systems with an origin nearby your geometry
and transform them to the correct places.

This is also valuable for your database design, as anyways floats or
doubles loose precision when they have large values.

regards Ralph

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


Re: [osg-users] Frustum specialists look here.

2007-10-19 Thread Johan Johnsson
i did like this at OSG version 1x (this gets a correct frustum)


Producer::Camera* camera = new Producer::Camera();

// Set frustum
camera-setLensFrustum(left, right, bottom, top, ch.frustum.nearClipping,  
ch.frustum.farClipping);


// Set projection rectangle
camera-setProjectionRectangle(
 static_castfloat(ch.projectionRect.left),
 static_castfloat(ch.projectionRect.right),
 static_castfloat(ch.projectionRect.bottom),
 static_castfloat(ch.projectionRect.top));

camera-setBlockOnVsync(true); // Try to use vertical sync.
camera-setShareLens(false); // Use unique lenses.
camera-setShareView(true); // All cameras share the same camera view.
camera-setLensAutoAspect(false); // Can't be used bacause of mirror  
channels.



This hos its done in OSG 2.x

// Set frustum
camera-setProjectionMatrixAsFrustum(left, right, bottom, top,  
ch.frustum.nearClipping, ch.frustum.farClipping);

// Set Viewports - if first cam set as master cam
camera-setViewport(new osg::Viewport(
 (pr.left * width),
 (pr.bottom * height),
 (pr.right - pr.left) * width,
 (pr.top - pr.bottom) * height));



On Thu, 18 Oct 2007 11:09:40 +0200, Robert Osfield  
[EMAIL PROTECTED] wrote:

 Hi Johan,

 It's really hard to know what is up for the little snippets of info
 provided.  In theory osgViewer's Camera setup should be just a pass
 through - it'll set what you provided.  The only time that osgViewer
 will change the projection matrix is when the window is resized.

 Could you modify one of the OSG examples to reproduce this problem and
 then post this so others can have a look at it.

 Robert.

 On 10/18/07, Johan Johnsson [EMAIL PROTECTED] wrote:
 osgviewer

 On Thu, 18 Oct 2007 09:47:38 +0200, Adrian Egli [EMAIL PROTECTED]  
 wrote:

  is the appliction based on the osgViewer? or producer ?
 
  sorry i still not understand what are the differents, same code used  
 for
  both version (i guess)
 
  2007/10/18, Johan Johnsson [EMAIL PROTECTED]:
 
   double left   = ((ch.frustum.left)   *  
 ch.frustum.nearClipping
  /
  abs( ch.frustum.distance));
   double right  = ((ch.frustum.right)  *  
 ch.frustum.nearClipping
  /
  abs( ch.frustum.distance));
   double top= ((ch.frustum.top)*  
 ch.frustum.nearClipping
  /
  abs( ch.frustum.distance));
   double bottom = ((ch.frustum.bottom) *  
 ch.frustum.nearClipping
  /
  abs( ch.frustum.distance));
 
   camera-setGraphicsContext(gc.get());
   camera-setProjectionMatrixAsFrustum(left, right, bottom,  
 top,
  ch.frustum.nearClipping, 
 ch.frustum.farClipping);
 
  // offset comes further down.
 
 
 
  On Thu, 18 Oct 2007 09:39:53 +0200, Adrian Egli [EMAIL PROTECTED]
  wrote:
 
   Hi Johan,
  
   quite hard to estimate what's going wrong, how do calc the  
 projection
   matrix, near far clipp, viewmatrix, and so on.
  
   /adegli
  
   2007/10/18, Johan Johnsson [EMAIL PROTECTED]:
  
   Hei !
  
   I dont know if its actually possible to tell exactly where the
   difference
   is when comparing two viewfrustums.
   We did get another frustum after the migration from osg1x to  
 osg2x.
   I attach 2 pictures showing them. (they get exactly the same  
 values,
   from
   a config file)
  
   --
   Mr. Johan Johnsson
   AutoSim AS, Strandveien 106, 9006 Tromsø
   Visit us at http://www.autosim.no
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
   
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  
  
  
 
 
 
  --
  Mr. Johan Johnsson
  AutoSim AS, Strandveien 106, 9006 Tromsø
  Visit us at http://www.autosim.no
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
   
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 
 



 --
 Mr. Johan Johnsson
 AutoSim AS, Strandveien 106, 9006 Tromsø
 Visit us at http://www.autosim.no
 ___
 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



-- 
Mr. Johan Johnsson
AutoSim AS, Strandveien 106, 9006 Tromsø
Visit us at http://www.autosim.no
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Frustum specialists look here.

2007-10-19 Thread Robert Osfield
HI Johan,

What is the high level viewer set up?  Is this the master camera you
are setting? Do you have slaves?

Could the resize of the window be a factor here, I note that you are
turning off the LensAutoAspect in Producer, not doing the equivilant
on the OSG side i.e.

 camera-setProjectionResizePolicy(osg::Camera::FIXED);

Robert.


On 10/19/07, Johan Johnsson [EMAIL PROTECTED] wrote:
 i did like this at OSG version 1x (this gets a correct frustum)


 Producer::Camera* camera = new Producer::Camera();

 // Set frustum
 camera-setLensFrustum(left, right, bottom, top, ch.frustum.nearClipping,
 ch.frustum.farClipping);


 // Set projection rectangle
 camera-setProjectionRectangle(
  static_castfloat(ch.projectionRect.left),
  static_castfloat(ch.projectionRect.right),
  static_castfloat(ch.projectionRect.bottom),
  static_castfloat(ch.projectionRect.top));

 camera-setBlockOnVsync(true); // Try to use vertical sync.
 camera-setShareLens(false); // Use unique lenses.
 camera-setShareView(true); // All cameras share the same camera view.
 camera-setLensAutoAspect(false); // Can't be used bacause of mirror
 channels.



 This hos its done in OSG 2.x

 // Set frustum
 camera-setProjectionMatrixAsFrustum(left, right, bottom, top,
 ch.frustum.nearClipping, ch.frustum.farClipping);

 // Set Viewports - if first cam set as master cam
 camera-setViewport(new osg::Viewport(
  (pr.left * width),
  (pr.bottom * height),
  (pr.right - pr.left) * width,
  (pr.top - pr.bottom) * height));



 On Thu, 18 Oct 2007 11:09:40 +0200, Robert Osfield
 [EMAIL PROTECTED] wrote:

  Hi Johan,
 
  It's really hard to know what is up for the little snippets of info
  provided.  In theory osgViewer's Camera setup should be just a pass
  through - it'll set what you provided.  The only time that osgViewer
  will change the projection matrix is when the window is resized.
 
  Could you modify one of the OSG examples to reproduce this problem and
  then post this so others can have a look at it.
 
  Robert.
 
  On 10/18/07, Johan Johnsson [EMAIL PROTECTED] wrote:
  osgviewer
 
  On Thu, 18 Oct 2007 09:47:38 +0200, Adrian Egli [EMAIL PROTECTED]
  wrote:
 
   is the appliction based on the osgViewer? or producer ?
  
   sorry i still not understand what are the differents, same code used
  for
   both version (i guess)
  
   2007/10/18, Johan Johnsson [EMAIL PROTECTED]:
  
double left   = ((ch.frustum.left)   *
  ch.frustum.nearClipping
   /
   abs( ch.frustum.distance));
double right  = ((ch.frustum.right)  *
  ch.frustum.nearClipping
   /
   abs( ch.frustum.distance));
double top= ((ch.frustum.top)*
  ch.frustum.nearClipping
   /
   abs( ch.frustum.distance));
double bottom = ((ch.frustum.bottom) *
  ch.frustum.nearClipping
   /
   abs( ch.frustum.distance));
  
camera-setGraphicsContext(gc.get());
camera-setProjectionMatrixAsFrustum(left, right, bottom,
  top,
   ch.frustum.nearClipping,
  ch.frustum.farClipping);
  
   // offset comes further down.
  
  
  
   On Thu, 18 Oct 2007 09:39:53 +0200, Adrian Egli [EMAIL PROTECTED]
   wrote:
  
Hi Johan,
   
quite hard to estimate what's going wrong, how do calc the
  projection
matrix, near far clipp, viewmatrix, and so on.
   
/adegli
   
2007/10/18, Johan Johnsson [EMAIL PROTECTED]:
   
Hei !
   
I dont know if its actually possible to tell exactly where the
difference
is when comparing two viewfrustums.
We did get another frustum after the migration from osg1x to
  osg2x.
I attach 2 pictures showing them. (they get exactly the same
  values,
from
a config file)
   
--
Mr. Johan Johnsson
AutoSim AS, Strandveien 106, 9006 Tromsø
Visit us at http://www.autosim.no
___
osg-users mailing list
osg-users@lists.openscenegraph.org
   
  
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
   
   
   
   
   
  
  
  
   --
   Mr. Johan Johnsson
   AutoSim AS, Strandveien 106, 9006 Tromsø
   Visit us at http://www.autosim.no
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  
  
 
 
 
  --
  Mr. Johan Johnsson
  AutoSim AS, Strandveien 106, 9006 Tromsø
  Visit us at http://www.autosim.no
  ___
  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



 --
 Mr. Johan Johnsson
 AutoSim AS, 

Re: [osg-users] Transparency problem

2007-10-19 Thread Christophe Medard
Yes. 
At least those kind of problems appearing on a dababase exported using OSGExp 
is solved by a clear segregation of transparent(semi-transparent) faces from 
opaque ones.

-- 
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29



  - Original Message - 
  From: André Rocha 
  To: OpenSceneGraph Users 
  Sent: Friday, October 19, 2007 2:20 PM
  Subject: Re: [osg-users] Transparency problem


  So the solution to the transparency sorting problem is simply to separate the 
objects with transparency and those without? In example, I have a opaque  
building with transparent windows in one single object, so I need to make the 
windows a separate object before exporting? 

  [ ]´s

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


Re: [osg-users] shadows and LOD scale

2007-10-19 Thread Robert Osfield
On 10/19/07, Terry Welsh [EMAIL PROTECTED] wrote:
 Hi Robert,
 My own PSSM code and osgshadow both exhibit this problem.  The code
 you wrote that makes shadow cameras measure LOD distances from the
 main camera's position works fine... until you introduce a LOD scale
 on the main camera.  The shadow cameras keep using a LOD scale of 1.0
 instead of using the LOD scale that you set on the main camera.

 I am able to work around the problem by explicitly setting the LOD
 scale on all of my shadow cameras, but this won't work for people
 using osgshadow unless they are given access to all of its shadow
 cameras.

OK I understand better where you are coming from now.  I don't have a
solution though :-)

Perhaps the osgShadow::ShadowTechniques could check the LOD scale and
adjust things accordingly.

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