Re: [osg-users] problem when using multi-sceneview in 2.3

[wangmiao]

HI Robert,
Thanks again:). Now I noticed the problem may caused by TexEnvCombine.The 
following code works well in 1.2 and draw a pure white model. But in 2.33 it 
draws a gray one . no codes changed. And I am also sure that vertex color and 
materials has been set to white. 
and the result of using 
te->setCombine_RGB(osg::TexEnvCombine::ADD);is brighter than 
te->setCombine_RGB(osg::TexEnvCombine::MODULATE); but also far to be pure white

 ref_ptr img=new osg::Image;
 img->allocateImage(texmap.width,texmap.height ,1,GL_RGBA,GL_UNSIGNED_BYTE);
//set to pure white
 memset(img->data(),255,img->getImageSizeInBytes());
 Texture2D  *tex=new Texture2D;
 tex->setImage(0,img.get());

 
m_param_osg.m_lightmaped_model_node->getOrCreateStateSet()->setTextureAttributeAndModes(m_param_osg.m_lightmap_texcoord_level,tex,StateAttribute::ON|StateAttribute::OVERRIDE);

 osg::TexEnvCombine *te = new osg::TexEnvCombine;
 te->setCombine_RGB(osg::TexEnvCombine::ADD);

 te->setSource1_RGB(osg::TexEnvCombine::TEXTURE);
 te->setOperand1_RGB(osg::TexEnvCombine::SRC_COLOR);

 te->setSource0_RGB(osg::TexEnvCombine::PREVIOUS);
 te->setOperand0_RGB(osg::TexEnvCombine::SRC_COLOR);
Thanks ! 
  - Original Message - 
  From: Robert Osfield 
  To: OpenSceneGraph Users 
  Sent: Monday, April 14, 2008 4:01 PM
  Subject: Re: [osg-users] problem when using multi-sceneview in 2.3


  Hi Wangmiao,

  Using multiple SceneViews does work in 2.x, osgViewer uses SceneViews under 
the hood to implement rendering, and it supports multiple views across one or 
more graphics context without any problems.

  As to why things are working your app I can't really even have a guess at as 
I don't know the code.

  Robert.


  On Mon, Apr 14, 2008 at 6:56 AM, wangmiao <[EMAIL PROTECTED]> wrote:

Hello every one,
I meet a problem when switching to osg 2.33 , multi-sceneviews doesn't work 
for 2 or more contextes.
I do it like these:
1. build opengl contex by opengl call
2.sceneview.Init()
looploop
3.destory sceneview AND  releaseAllGLObjects
4.destory context  wglDeleteContext
every context has an individual contextid set by 
m_sceneview->getState()->setContextID
this works perfect with osg 1.2.
Is there any change may cause this problem? Thanks!

   wangmiao
___
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] Deploying Application

[CG]

Hi all,
 
When I copied my application (OpenSceneGraph libraries, DLLs and application) 
to another folder, the application will not load any flt or ive files. A 
warning message "Warning: Could not find plugin to read objects from file 
"F:/OpenSceneGraph-2.0/Tutorials/JoeDirt/JoeDirt.flt" will be displayed in the 
console window. I've set the path to OpenSceneGraph plugins and bin directory 
in the environment setting (Windows Vista) but it still can't find the plugin.
 
Regards,
CG
_
Publish your photos to your Space easily with Photo Gallery.
http://www.get.live.com/wl/all___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osg-conv collada

[Eduard Trulls]

[EMAIL PROTECTED] wrote:
>  >  Also, what are the plans for the plugin now that 2.0's out?
>
> I plan on submitting a patch to bring OSG up to using DOM 2.0. That 
> should be sometime this month.
>
> Steve
>
>   
I think I'll wait for that then. Thanks for your reply.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Projective Texturing in GLSL shader

[Paul Pocock]

Managed to achieve Projective Texturing in shader - just changed the 

gl_TexCoord[0].q = 1.0   to   dot( ecPosition,gl_EyePlaneQ[0];

so:

gl_TexCoord[0].s = dot(ecPosition, gl_EyePlaneS[0])  ;
gl_TexCoord[0].t = dot(ecPosition, gl_EyePlaneT[0]) ;
gl_TexCoord[0].p = dot(ecPosition, gl_EyePlaneR[0]);
gl_TexCoord[0].q = dot( ecPosition,gl_EyePlaneQ[0];


Thanks agian for your help


On Mon, 2008-04-14 at 08:37 +0200, Sebastian Messerschmidt wrote:
> Hi Paul,
> 
> In the vertex shader try this
> vec4 ecPosition = gl_Vertex * gl_ModelViewMatrix;
>
> gl_TexCoord[0].s = dot(ecPosition, gl_EyePlaneS[0])  ;
> gl_TexCoord[0].t = dot(ecPosition, gl_EyePlaneT[0]) ;
> gl_TexCoord[0].p = dot(ecPosition, gl_EyePlaneR[0]);
> gl_TexCoord[0].q = 1.0;
> 
> Then use the the projective sampler in the fragment shader.
> This achieves EYE_LINEAR texturing like in fixed function IIRC (don't 
> forget to setup
> the eye-Planes from the camera-matrix)
> 
> cheers
> Sebastian "psy" Messerschmidt
> 
> Paul Pocock schrieb:
> > Hi, 
> > I need some advice on projective texturing. I can get it going in Fixed
> > Functionality - however not on the GPU.  
> >
> > I've set up a texGenNode and passing the matrix as a uniform to the
> > shader. I'm also passing the ViewMatrix but sufficed to say I'm not
> > getting the desired effect. 
> >
> > Any advice would be appreciated.
> >
> > Regards
> >
> >
> > uniform mat4 TexGenMat;
> > uniform mat4 ViewMat;
> >
> > [Vertex shader]
> >
> > vec4 positionEye =  gl_ModelViewMatrix * gl_vertex
> > vec4 positionWorld = ViewMat * positionEye;
> > index = TexGenMat * positionWorld;
> >
> > [fragment shader]
> >
> > vec4 ProjMapColor = texture2DProj(PROJECTION_TEXTURE, index);
> >
> >
> > IMPORTANT: This email remains the property of the Australian Defence 
> > Organisation and is subject to the jurisdiction of section 70 of the CRIMES 
> > ACT 1914.  If you have received this email in error, you are requested to 
> > contact the sender and delete the email.
> >
> >
> > ___
> > 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] Feedback sought on osgViewer swap ready support for clusters

[Mike Weiblen]

Hi Robert,

we have an opengl32.dll shim lib that intercepts and replicates the
cmd stream to nodes in the cluster.  at wglSwap, the nodes render and
report back at render completion, then block til they can all swap
together.

> What do you mean by "generic OpenGL rather than OSG level"?

I mean we're doing this at the GL level, OSG is just another GL app ATM.

cheers
-- mew

-- 
Mike Weiblen -- Austin Texas USA -- http://mew.cx/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Projective Texturing in GLSL shader

[Paul Pocock]

Thanks for your help Sebastian, I'm using texgen->setPlanesFromMatrix
to set up eye-planes. I assume that's correct (looking at osgspotlight
and other examples..)


Regards

On Mon, 2008-04-14 at 08:37 +0200, Sebastian Messerschmidt wrote:
> Hi Paul,
> 
> In the vertex shader try this
> vec4 ecPosition = gl_Vertex * gl_ModelViewMatrix;
>
> gl_TexCoord[0].s = dot(ecPosition, gl_EyePlaneS[0])  ;
> gl_TexCoord[0].t = dot(ecPosition, gl_EyePlaneT[0]) ;
> gl_TexCoord[0].p = dot(ecPosition, gl_EyePlaneR[0]);
> gl_TexCoord[0].q = 1.0;
> 
> Then use the the projective sampler in the fragment shader.
> This achieves EYE_LINEAR texturing like in fixed function IIRC (don't 
> forget to setup
> the eye-Planes from the camera-matrix)
> 
> cheers
> Sebastian "psy" Messerschmidt
> 
> Paul Pocock schrieb:
> > Hi, 
> > I need some advice on projective texturing. I can get it going in Fixed
> > Functionality - however not on the GPU.  
> >
> > I've set up a texGenNode and passing the matrix as a uniform to the
> > shader. I'm also passing the ViewMatrix but sufficed to say I'm not
> > getting the desired effect. 
> >
> > Any advice would be appreciated.
> >
> > Regards
> >
> >
> > uniform mat4 TexGenMat;
> > uniform mat4 ViewMat;
> >
> > [Vertex shader]
> >
> > vec4 positionEye =  gl_ModelViewMatrix * gl_vertex
> > vec4 positionWorld = ViewMat * positionEye;
> > index = TexGenMat * positionWorld;
> >
> > [fragment shader]
> >
> > vec4 ProjMapColor = texture2DProj(PROJECTION_TEXTURE, index);
> >
> >
> > IMPORTANT: This email remains the property of the Australian Defence 
> > Organisation and is subject to the jurisdiction of section 70 of the CRIMES 
> > ACT 1914.  If you have received this email in error, you are requested to 
> > contact the sender and delete the email.
> >
> >
> > ___
> > 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] Attention: osgTerrain class renaming in progress

[Pecoraro, Alexander N]

What version of the OSG API and the VPB do I need to use in order to
take advantage of the new osgTerrain functionality and optimizations?

Thanks.

Alex

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Wednesday, March 26, 2008 2:13 PM
To: OpenSceneGraph Users
Subject: [osg-users] Attention: osgTerrain class renaming in progress

Hi All,

As part of the work on scaling up VirtualPlanetBuilder to comfortable
handle terrabyte database I am also working on osgTerrain, the two bits
of work are quite closely related as VPB is at its most efficient when
outputting osgTerrain based databases (the --terrain option makes it
about 100-200x faster than it is when build normal polygonal
databases). Not only VPB is faster when generating osgTerrain
based databases but the resulting databases will be more flexible and
compact, with future opportunities for improving visual quality and
performance.  So all good stuff... but before we get to this terrain
nirvana a few things will need to be refactored...

My current work on osgTerrain is related to making better use of
recycling of deleted objects and sharing of things like tex coord arrays
etc where possible.  This is something that now is required to better
cope with users charging around a multi-terrabyte database at high speed
- as it tends to push memory much more than we're previously done.
Recycling and sharing of object requires a shared container for each
paged terrain database, to this end I'll be introducing a new terrain
node that decorates the whole paged terrain
database.   This new terrain node will also help track the hierarchy
and adjancancy of the tiles being loaded via a tile system.

The idea of a terrain node containing all the PagedLOD nodes, and the
terrain tiles that do the actual rendering of the tiles height fields
brings about a new relationship to osgTerrain, and the the naming really
needs to evolve to better suit it, unfortunately with picking more
suitable names of the new usage model we'll end up break strict
backwards compatibility.   osgTerrain is still young, so I'd rather
take the pain of hit in backwards compatibility now rather than suffer
inappropriate names for the rest of the NodeKits life.The new
naming scheme goes:


   osgTerrain::Terrain node is renamed osgTerrain::TerrainTile,

 osgTerrain::TerrainTile API and usage model remain almost
entirely the same as the old osgTerrain::Terrain so most developers
would just
 need to rename osgTerrain::Terrain to
osgTerrain::TerrainTile and then everything will compile once more.

   The new terrain node that decorates the whole terrain scene graph
will be called osgTerrain::Terrain,

The API of the new Terrain node will have some overlap with
TerrainTile, such as provide a default TerrainTechnique that nested
TerrainTile has
clone, but otherwise its a totally different type of Node,
its a decorator node rather than a rendering element.

Reusing an original name might cause initial confusion, and
compile errors might through one off the scent.  But... I feel that once
things
are settled down the new naming will be more sense i.e.
The a Terrain has subgraph that contains one or more TerrainTile.
Each Terrain is
conceptually a single overall block of terrain, for instance
if you have a solar system, then each planet would be its has its own
Terrain
node.

All the Layer and TerrainTechnique classes remained unchanged relative
to recent 2.3.x, although these themselves have evolved since 2.0.

Existing .ive database that contain old osgTerrain::Terrain(Tile)
objects will still load, so backwards compatibility has been maintained,
with the objects just loading as TerrainTile and everything behaving
itself as before.  The .osg format won't be able to be mapped so well
unfortunately, to keep .osg files with Terrain nodes in them working
you'll need to do a search a replace of Terrain to TerrainTile.

In my local copy of the OSG I've already made most of these changes, and
plan to check them in tomorrow.  At this point if you directly use
osgTerrain then you'll need to rename Terrain to TerrainTile to get
things back working again, if you don't use osgTerrain then you'll not
notice any different at all.

Thanks in advance for you patience in tracking these changes, Robert.
___
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] osg-conv collada

[steven_thomas]

Hi Eduard, unfortunately I don't have any tips for the error you're 
getting. A couple months ago I tried getting OSG to use the DOM trunk 
code for its Collada support, and other than a few easily fixable 
compiler errors it worked fine. I didn't get any .so load errors. I was 
testing with Ubuntu.

 >  Also, what are the plans for the plugin now that 2.0's out?

I plan on submitting a patch to bring OSG up to using DOM 2.0. That 
should be sometime this month.

Steve


Eduard Trulls wrote:
> Hi,
>
> I'm trying to get the collada plugin working and running into this 
> problem too. I've tried Johan Nouvel's suggestion (a few messages later) 
> to no avail. I'm using osg 2.3.7 and the last pre-2.0 stable release for 
> collada, 1.4.1 DOM 3.0. Did anyone find a way around it?
>
> Also, what are the plans for the plugin now that 2.0's out?
>
> Thanks,
> Eduard
>
>
> skunkwerk wrote:
>   
>> thanks Jason,
>>here's the output - it seems that it eventually finds the plugin, 
>> but dlopen complains about an undefined symbol in the osgdb_dae.so 
>> file - how can I fix this?
>>
>> RegisterWindowingSystemInterfaceProxy()
>> X11WindowingSystemInterface()
>> GraphicsContext::setWindowingSystemInterface() 0x80635200xb7f44bd0
>> itr='/usr/lib/'
>> FindFileInPath() : trying /usr/lib/osgdb_dae ...
>> itr='/usr/local/lib/'
>> FindFileInPath() : trying /usr/local/lib/osgdb_dae ...
>> DynamicLibrary::getLibraryHandle( osgdb_dae) - dlopen(): ./osgdb_dae: 
>> cannot open shared object file: No such file or directory
>> DynamicLibrary::failed loading "osgdb_dae"
>> itr='/usr/lib/'
>> FindFileInPath() : trying /usr/lib/osgPlugins-2.2.0/osgdb_dae.so ...
>> itr='/usr/local/lib/'
>> FindFileInPath() : trying /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so ...
>> FindFileInPath() : USING /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so
>> DynamicLibrary::getLibraryHandle( 
>> /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so) - dlopen(): 
>> /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so: undefined symbol: 
>> _ZN15daeLIBXMLPluginC1Ev
>> DynamicLibrary::failed loading "osgPlugins-2.2.0/osgdb_dae.so"
>> Warning: Could not find plugin to read objects from file 
>> "/home/imran/3d/3dwarehouse/45/models/45.dae".
>> Error no data loaded.
>> ~RegisterWindowingSystemInterfaceProxy()
>> GraphicsContext::setWindowingSystemInterface() 00xb7f44bd0
>>
>> appreciate it
>>
>> On Mon, Mar 24, 2008 at 8:28 AM, Jason Daly <[EMAIL PROTECTED] 
>> > wrote:
>>
>> skunkwerk wrote:
>> > thanks Jason, once I ran ccmake . I was able to configure the
>> > environment variables correctly.
>> > the plugin seems to have been installed to
>> > /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so
>> > yet I can't get osgconv to find it - i've tried -e dae, -l
>> osgdb_dae,
>> > -l /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so but none of them
>> > work.  how do i get osgconv to load the library?
>>
>> You might need to set your OSGNOTIFY environment variable to DEBUG and
>> see why osgconv isn't finding it.
>>
>> --"J"
>>
>>
>> 
>>
>> ___
>> 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] Using Custom Mouse Cursor

[Jason Beverage]

Hi all,

I'm attempting to use OSG embedded in a C# window like hesicong and Glenn
Waldron have recently discussed on the osg-users mailing list.  One issue
that I'm running into is changing the Cursor property on my mouse form.  a
custom mouse cursor in my form.  GraphicsWindowWin32 manages the current
cursor as one of the ones defined in the GraphicsWindow::MouseCursor
enumeration so I can't use a custom cursor (as far as I can tell).

If I set the cursor manually using ::SetCursor, it gets override by
GraphicsWindowWin32 because it calls  ::SetCursor in response to every
WM_SETCURSOR call and passes in _currentCursor.

I've tried setting useCursor to false in the traits of the graphics context
and calling ::SetCursor on my own, but this causes the cursor to flicker
very badly because GraphicsWindowWin32 calls ::SetCursor(NULL) if use cursor
is set to false.

It seems like there needs to be an option to set a custom cursor by passing
in an HCURSOR or a way to say "don't manage the mouse cursor" in the Traits
class.

Any suggestions?

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

Re: [osg-users] Feedback sought on osgViewer swap ready support for clusters

[Leif Delgass]

On Mon, Apr 14, 2008 at 3:03 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi Leif,
>
> Thanks the info, very useful.  Do you still have access to the various
> hardware?  I'm thinking of what we can do in terms of testing if/when we get
> code integrated into osgViewer.

I'll try to help out as time permits.  The biggest issue is having a
hardware configuration that is known working to test on!  I have had
problems getting even simple demo tests to sync properly across our
cluster with the hardware method.  I might need to try subsets of
nodes to find a stable configuration.

> W.r.t swap groups and barriers, I am wondering about putting the
> group/barrier ID's as parameters of osg::GraphicsContext::Traits, let them
> be ints and have a -1 value signifying inactive.   If they are positive then
> they could be used in graphics context realize code to assign to appropriate
> groups/barriers.  We'd possibly also need an overall hint in
> osg::DisplaySettings to say whether we want swap/groups activated by
> default, or to disable ones being requested in case of flaky driver
> implementations.

An overall hint would be useful.  If you are lucky, you'll just slip
the barrier if the hardware/driver has problems, but a lock up isn't
out of the realm of possibilty, so a global disable is nice. ;)  As
far as the traits go, what you suggest will work for the NVIDIA
implementation (and as I said in my case the ID had to be 1 for both
group and barrier).  If you want to support the SGI extentsion, it's a
bit tricker, since you bind a window to the group by supplying the
drawable of another window which is already bound! (yuck).  The thing
is, even when we still had an Onyx running, I don't recall having to
use the extension, it seemed that frame lock was enabled at the driver
configuration level, but I don't have access to SGI hardware anymore
to test.  Maybe the extesion would be supported on the Prism?

> Would it be possible to list the API setup/entry points to the software sync
> functions, this will help me get an idea of what would be required.
>
> Robert.

I'm not sure if this will help you, since I don't use osgViewer.  In
my case, VR Juggler handles the render loop with each context handled
by a separate thread/SceneView (but in my case, I have a single
context/thread per node).  Synchronization happens after calling
SceneView::draw(), so a callback from OSG isn't necessary (from VRJ's
perspective it's "don't call us, we'll call you").  The sync happens
in VRJ's "kernel" and draw manager classes.  There is a semaphore for
the draw threads, and then the cluster barrier is implemented by a
"cluster plugin" that handles the sync packets.  There is also a start
barrier plugin to ensure that all nodes wait to begin the first frame
until all are ready, again with TCP.  From the application developer's
perspective, you subclass your application class from an OsgApp class
and hand it to the Juggler kernel, so you don't need to deal with the
render loop and sync code, you just fill in methods that are called
before drawing the frame (pre- and post- cluster sync), during frame
draw, post-frame, etc.

-- 
Leif Delgass
[EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Feedback sought on osgViewer swap ready support for clusters

[Robert Osfield]

Hi Leif,

Thanks the info, very useful.  Do you still have access to the various
hardware?  I'm thinking of what we can do in terms of testing if/when we get
code integrated into osgViewer.

W.r.t swap groups and barriers, I am wondering about putting the
group/barrier ID's as parameters of osg::GraphicsContext::Traits, let them
be ints and have a -1 value signifying inactive.   If they are positive then
they could be used in graphics context realize code to assign to appropriate
groups/barriers.  We'd possibly also need an overall hint in
osg::DisplaySettings to say whether we want swap/groups activated by
default, or to disable ones being requested in case of flaky driver
implementations.

Would it be possible to list the API setup/entry points to the software sync
functions, this will help me get an idea of what would be required.

Robert.

On Mon, Apr 14, 2008 at 7:29 PM, Leif Delgass <[EMAIL PROTECTED]> wrote:

> I have experience using both software-based swap ready, and the NVIDIA
> hardware synchronization with OSG.  In both cases this was in
> conjunction with VR Juggler handling the context setup and main loop
> (with an OSG SceneView per window/node).  VR Juggler includes a
> TCP-based software barrier.  For hardware sync, I had hacked support
> into the VR Juggler context/window setup code, but there is now core
> support for that in VR Juggler.  I would recommend having a software
> method available as a fall back, because the NVIDIA hardware
> implementation hasn't always worked for me, especially on large
> clusters (I work with a 27-node tiled wall now), but I've mostly
> worked with Quadro cards with the sync feature integrated vs. the new
> G-Sync cards (we've used those in a 4 node system with success, IIRC).
>  There is finally a spec in the registry for NVIDIA's extension, which
> is based on the old SGIX extensions:
>
> http://www.opengl.org/registry/specs/NV/glx_swap_group.txt
> http://www.opengl.org/registry/specs/NV/wgl_swap_group.txt
> http://www.opengl.org/registry/specs/SGIX/swap_group.txt
> http://www.opengl.org/registry/specs/SGIX/swap_barrier.txt
>
> Note that these also interact with the swap interval in
> GLX_SGI/WGL_swap_control, so you can sync on a multiple of the
> blanking interval.
>
> I think in theory you can use the swap group to get your barrier for
> multiple contexts on a single machine, and then bind the swap group to
> the global swap barrier, but I've only worked with one context and one
> screen per node (single card in each node).  In my case the NVIDIA
> extension supported a single swap group for GLX windows on each
> machine and a single global barrier (you can query the limit with the
> NV extension).  I always have sync to vblank enabled either by
> environment variable or through nvidia-settings, and you need to set
> up all the cards and the sync master in the Frame Lock settings of
> nvidia-settings as well (I usually have a shell script wrapper that
> ensures all that is set up by calling nvidia-settings from the command
> line).
>
> Also, (as with any extensions) remember to check for the extension
> string in the GLX extensions before attempting to use it, since some
> implementations may return non-NULL entry points even if the extension
> isn't supported.
>
> --
> Leif Delgass
> [EMAIL PROTECTED]
> ___
> 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] More help with state changes

[Robert Osfield]

Hi Judia,

What you are trying to do should work, but without the code for setting the
different stateset to the appropriate nodes I can't say what exactly the
problem is.  The fact that you refer to NodeCParent  looks suspect, you
should apply directly to NodeC as NodeCParent is NodeA...

Robert.

On Mon, Apr 14, 2008 at 7:36 PM, Judie Stanley <[EMAIL PROTECTED]>
wrote:

> This is an exisiting project.
> Here is the basic node structure:
>
> Root
>|
> NodeA
>  /   \
>  NodeB NodeC
>
> I want to disable writes to the color buffer before Node A, and then I
> don't want to enable them until Node C. That way, Node A, and Node B are
> drawn but only the depth buffer is updated, but then when Node C is drawn,
> both the color buffer and the depth buffer are updated.
>
> Here is my code:
>
> osg::ColorMask *colormaskOff = new osg::ColorMask(false, false, false,
> false);
> osg::ColorMask *colormaskON = new osg::ColorMask(true, true, true, true);
>
> osg::StateSet* state = NodeAParent->getOrCreateStateSet();
> state->setAttribute(colormaskOff);
>
>  osg::StateSet* state2 = NodeCParent->getOrCreateStateSet();
> state2->setAttribute(colormaskON);
>
> So you can see my dilema.
>
> In the code I see that the glColorMask gets called with the correct data,
> however, because of the graph topology, NodeA and NodeB get drawn to the
> color buffer even though I disabled it in the Root (NodeAParent), it gets
> enabled for NodeA (NodeCParent).
>
> Is it possible to stick come kind of node inbetween NodeA and NodeC? What
> type of node should that be? Can there be a blank node?
>
> Thanks,
>
> Judie
>
>
>
>
> ___
> 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] Feedback sought on osgViewer swap ready support for clusters

[Leif Delgass]

On Mon, Apr 14, 2008 at 2:29 PM, Leif Delgass <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 14, 2008 at 11:26 AM, Robert Osfield
>
> <[EMAIL PROTECTED]> wrote:
>
>
> > Hi Mike,
>  >
>  >
>  > On Mon, Apr 14, 2008 at 4:11 PM, Mike Weiblen <[EMAIL PROTECTED]>
>  > wrote:
>  >
>  > > fyi I also have need for swap sync across a networked cluster, but at
>  > > the the generic OpenGL rather than OSG level.
>  >
>  > What do you mean by "generic OpenGL rather than OSG level"?  I am trying to
>  > get my head around the topic so specifics is very useful right now.
>  >
>  > > We've implemented an
>  > > out of band handshake protocol in our network pipeline, but would be
>  > > glad to adopt a GL standard if possible.  So I'm following this topic
>  > > w/ interest.
>  >
>  > So you've implemented a software swap ready barrier then?
>  >
>  > How do you currently wire this up with the OSG?
>  >
>  > Robert.
>  >
>
>  Hi Robert,
>
>  I have experience using both software-based swap ready, and the NVIDIA
>  hardware synchronization with OSG.  In both cases this was in
>  conjunction with VR Juggler handling the context setup and main loop
>  (with an OSG SceneView per window/node).  VR Juggler includes a
>  TCP-based software barrier.  For hardware sync, I had hacked support
>  into the VR Juggler context/window setup code, but there is now core
>  support for that in VR Juggler.  I would recommend having a software
>  method available as a fall back, because the NVIDIA hardware
>  implementation hasn't always worked for me, especially on large
>  clusters (I work with a 27-node tiled wall now), but I've mostly
>  worked with Quadro cards with the sync feature integrated vs. the new
>  G-Sync cards (we've used those in a 4 node system with success, IIRC).
>   There is finally a spec in the registry for NVIDIA's extension, which
>  is based on the old SGIX extensions:
>
>  http://www.opengl.org/registry/specs/NV/glx_swap_group.txt
>  http://www.opengl.org/registry/specs/NV/wgl_swap_group.txt
>  http://www.opengl.org/registry/specs/SGIX/swap_group.txt
>  http://www.opengl.org/registry/specs/SGIX/swap_barrier.txt
>
>  Note that these also interact with the swap interval in
>  GLX_SGI/WGL_swap_control, so you can sync on a multiple of the
>  blanking interval.
>
>  I think in theory you can use the swap group to get your barrier for
>  multiple contexts on a single machine, and then bind the swap group to
>  the global swap barrier, but I've only worked with one context and one
>  screen per node (single card in each node).  In my case the NVIDIA
>  extension supported a single swap group for GLX windows on each
>  machine and a single global barrier (you can query the limit with the
>  NV extension).  I always have sync to vblank enabled either by
>  environment variable or through nvidia-settings, and you need to set
>  up all the cards and the sync master in the Frame Lock settings of
>  nvidia-settings as well (I usually have a shell script wrapper that
>  ensures all that is set up by calling nvidia-settings from the command
>  line).
>
>  Also, (as with any extensions) remember to check for the extension
>  string in the GLX extensions before attempting to use it, since some
>  implementations may return non-NULL entry points even if the extension
>  isn't supported.
>

I forgot to mention, you are correct that you don't need an explicit
sync, the normal swap buffers call is all you need once you have bound
the swap barrier (and enabled frame lock in the driver settings).

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

[osg-users] More help with state changes

[Judie Stanley]

This is an exisiting project.
Here is the basic node structure:

Root
   |
NodeA
 /   \
 NodeB NodeC

I want to disable writes to the color buffer before Node A, and then I don't
want to enable them until Node C. That way, Node A, and Node B are drawn but
only the depth buffer is updated, but then when Node C is drawn, both the
color buffer and the depth buffer are updated.

Here is my code:

osg::ColorMask *colormaskOff = new osg::ColorMask(false, false, false,
false);
osg::ColorMask *colormaskON = new osg::ColorMask(true, true, true, true);

osg::StateSet* state = NodeAParent->getOrCreateStateSet();
state->setAttribute(colormaskOff);

 osg::StateSet* state2 = NodeCParent->getOrCreateStateSet();
state2->setAttribute(colormaskON);

So you can see my dilema.

In the code I see that the glColorMask gets called with the correct data,
however, because of the graph topology, NodeA and NodeB get drawn to the
color buffer even though I disabled it in the Root (NodeAParent), it gets
enabled for NodeA (NodeCParent).

Is it possible to stick come kind of node inbetween NodeA and NodeC? What
type of node should that be? Can there be a blank node?

Thanks,

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

Re: [osg-users] Feedback sought on osgViewer swap ready support for clusters

[Leif Delgass]

On Mon, Apr 14, 2008 at 11:26 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi Mike,
>
>
> On Mon, Apr 14, 2008 at 4:11 PM, Mike Weiblen <[EMAIL PROTECTED]>
> wrote:
>
> > fyi I also have need for swap sync across a networked cluster, but at
> > the the generic OpenGL rather than OSG level.
>
> What do you mean by "generic OpenGL rather than OSG level"?  I am trying to
> get my head around the topic so specifics is very useful right now.
>
> > We've implemented an
> > out of band handshake protocol in our network pipeline, but would be
> > glad to adopt a GL standard if possible.  So I'm following this topic
> > w/ interest.
>
> So you've implemented a software swap ready barrier then?
>
> How do you currently wire this up with the OSG?
>
> Robert.
>

Hi Robert,

I have experience using both software-based swap ready, and the NVIDIA
hardware synchronization with OSG.  In both cases this was in
conjunction with VR Juggler handling the context setup and main loop
(with an OSG SceneView per window/node).  VR Juggler includes a
TCP-based software barrier.  For hardware sync, I had hacked support
into the VR Juggler context/window setup code, but there is now core
support for that in VR Juggler.  I would recommend having a software
method available as a fall back, because the NVIDIA hardware
implementation hasn't always worked for me, especially on large
clusters (I work with a 27-node tiled wall now), but I've mostly
worked with Quadro cards with the sync feature integrated vs. the new
G-Sync cards (we've used those in a 4 node system with success, IIRC).
 There is finally a spec in the registry for NVIDIA's extension, which
is based on the old SGIX extensions:

http://www.opengl.org/registry/specs/NV/glx_swap_group.txt
http://www.opengl.org/registry/specs/NV/wgl_swap_group.txt
http://www.opengl.org/registry/specs/SGIX/swap_group.txt
http://www.opengl.org/registry/specs/SGIX/swap_barrier.txt

Note that these also interact with the swap interval in
GLX_SGI/WGL_swap_control, so you can sync on a multiple of the
blanking interval.

I think in theory you can use the swap group to get your barrier for
multiple contexts on a single machine, and then bind the swap group to
the global swap barrier, but I've only worked with one context and one
screen per node (single card in each node).  In my case the NVIDIA
extension supported a single swap group for GLX windows on each
machine and a single global barrier (you can query the limit with the
NV extension).  I always have sync to vblank enabled either by
environment variable or through nvidia-settings, and you need to set
up all the cards and the sync master in the Frame Lock settings of
nvidia-settings as well (I usually have a shell script wrapper that
ensures all that is set up by calling nvidia-settings from the command
line).

Also, (as with any extensions) remember to check for the extension
string in the GLX extensions before attempting to use it, since some
implementations may return non-NULL entry points even if the extension
isn't supported.

-- 
Leif Delgass
[EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Delaunay and getTriangles()

[Vincent Bourdier]

Hi All,

Using osgUtil::DelaunayTriangulator, I'm looking for obtaining the triangle
list... but for the moment, I haven't already found it.

The getTriangles() method return a DrawElementsUInt, but no way to find a
triangle list or something approaching...

Is there a (simple) way ?

Thanks,

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

Re: [osg-users] Feedback sought on osgViewer swap ready support for clusters

[Robert Osfield]

Hi Mike,

On Mon, Apr 14, 2008 at 4:11 PM, Mike Weiblen <[EMAIL PROTECTED]>
wrote:

> fyi I also have need for swap sync across a networked cluster, but at
> the the generic OpenGL rather than OSG level.


What do you mean by "generic OpenGL rather than OSG level"?  I am trying to
get my head around the topic so specifics is very useful right now.


> We've implemented an
> out of band handshake protocol in our network pipeline, but would be
> glad to adopt a GL standard if possible.  So I'm following this topic
> w/ interest.


So you've implemented a software swap ready barrier then?

How do you currently wire this up with the OSG?

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

Re: [osg-users] osg-conv collada

[Eduard Trulls]

Hi,

I'm trying to get the collada plugin working and running into this 
problem too. I've tried Johan Nouvel's suggestion (a few messages later) 
to no avail. I'm using osg 2.3.7 and the last pre-2.0 stable release for 
collada, 1.4.1 DOM 3.0. Did anyone find a way around it?

Also, what are the plans for the plugin now that 2.0's out?

Thanks,
Eduard


skunkwerk wrote:
> thanks Jason,
>here's the output - it seems that it eventually finds the plugin, 
> but dlopen complains about an undefined symbol in the osgdb_dae.so 
> file - how can I fix this?
>
> RegisterWindowingSystemInterfaceProxy()
> X11WindowingSystemInterface()
> GraphicsContext::setWindowingSystemInterface() 0x80635200xb7f44bd0
> itr='/usr/lib/'
> FindFileInPath() : trying /usr/lib/osgdb_dae ...
> itr='/usr/local/lib/'
> FindFileInPath() : trying /usr/local/lib/osgdb_dae ...
> DynamicLibrary::getLibraryHandle( osgdb_dae) - dlopen(): ./osgdb_dae: 
> cannot open shared object file: No such file or directory
> DynamicLibrary::failed loading "osgdb_dae"
> itr='/usr/lib/'
> FindFileInPath() : trying /usr/lib/osgPlugins-2.2.0/osgdb_dae.so ...
> itr='/usr/local/lib/'
> FindFileInPath() : trying /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so ...
> FindFileInPath() : USING /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so
> DynamicLibrary::getLibraryHandle( 
> /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so) - dlopen(): 
> /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so: undefined symbol: 
> _ZN15daeLIBXMLPluginC1Ev
> DynamicLibrary::failed loading "osgPlugins-2.2.0/osgdb_dae.so"
> Warning: Could not find plugin to read objects from file 
> "/home/imran/3d/3dwarehouse/45/models/45.dae".
> Error no data loaded.
> ~RegisterWindowingSystemInterfaceProxy()
> GraphicsContext::setWindowingSystemInterface() 00xb7f44bd0
>
> appreciate it
>
> On Mon, Mar 24, 2008 at 8:28 AM, Jason Daly <[EMAIL PROTECTED] 
> > wrote:
>
> skunkwerk wrote:
> > thanks Jason, once I ran ccmake . I was able to configure the
> > environment variables correctly.
> > the plugin seems to have been installed to
> > /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so
> > yet I can't get osgconv to find it - i've tried -e dae, -l
> osgdb_dae,
> > -l /usr/local/lib/osgPlugins-2.2.0/osgdb_dae.so but none of them
> > work.  how do i get osgconv to load the library?
>
> You might need to set your OSGNOTIFY environment variable to DEBUG and
> see why osgconv isn't finding it.
>
> --"J"
>
>
> 
>
> ___
> 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] Highly detailed closed scene navigations...

[Jason Daly]

Robert Osfield wrote:
> Hi Neil,
>
> PagedLOD is what you need to use to balance the load for really large 
> databases.  You databases are likely to huge though, gigabytes rather 
> than terrabytes, and the OSG' paging system allows you to scale to 
> terrabyte database pretty comfortably so you'll do just fine is you 
> manage the scene structure well.  Doing it well is not a trivial task 
> though so expect to be effort in learning about the issues and time 
> experimenting with different scene graph structures.
>
> You might also want to use some high level cull callbacks that cull 
> subgraphs based on which room floor you are as this way you can get 
> more effective culling.  You can enclose each region with its own 
> bounding mesh - see osgSim::VisibilityGroup for this type of 
> culling.   One thing you want to be careful about is tricks like 
> relaxing such culling to allow the pager to start bringing in the new 
> floor level prior to it becoming visible.

Hi, Neil,

Not sure if this is appropriate for your case or not, but when I had to 
model an office with several rows of cubicles, and then run it on a 
wearable computer, I found the osg::OccluderNode to be a great way to 
bring the frame rate up.  The cubicle walls made obvious, natural 
occluders for all of the complex furniture models inside them, so I only 
ever had to draw the few pieces of furniture that were potentially 
visible.  In your case, you've also got actual floor-to-ceiling walls 
that would make even better occluders.

One potential problem is that I'm not sure how well they scale.  My 
environment was just a section of a building that had an open plan, 
while yours seems a bit larger.  There's a tradeoff between the number 
of occluders in the scene and the potential performance gains, so you 
can't have too many occluders active at once.  However, if you combine 
this with the PagedLOD's and a higher-level culling scheme, you might 
come up with something that both fits in memory and runs pretty quickly.

--"J"

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

Re: [osg-users] Feedback sought on osgViewer swap ready support for clusters

[Mike Weiblen]

Hi,

fyi I also have need for swap sync across a networked cluster, but at
the the generic OpenGL rather than OSG level.  We've implemented an
out of band handshake protocol in our network pipeline, but would be
glad to adopt a GL standard if possible.  So I'm following this topic
w/ interest.

cheers
-- mew




On Mon, Apr 14, 2008 at 4:40 AM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm looking for feedback from users who have worked on clusters that
> implement some forms of swap ready synchronization.  In particular I'm
> looking at any hooks into osgViewer to allow users to implement their own
> swap ready implementation, also a software based swap ready could possibly
> be implemented as part of the core OSG as well.
>
> The hook to adding a swap ready barrier into the view would look something
> like:
>
>   viewer.setSwapReadyOperation(myCustomSwapReadyOperation);
>
> Something like complicates the mater is that viewer on each slave of the
> cluster might have more than one graphics context that its rendering too, so
> in this case we'll have multiple graphics threads per slave, in which case
> these threads will need to join a barrier that treats each context like a
> separate machine or the barrier does a local synchronization of the threads
> on a machine before joining the cluster swap ready barrier.
>
> I want to come up with a scheme that supports both ways above, but really
> need a bit more feedback on what goes into users own swap ready codes, i.e.
> what would your MyCustomSwapReadyOperation look like, i.e. what does it look
> right now, this will help me better understand how the most appropriate
> integration into osgViewer could be done.
>
> Robert.
>
>
>
>
>
> ___
>  osg-users mailing list
>  osg-users@lists.openscenegraph.org
>  http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



-- 
Mike Weiblen -- Austin Texas USA -- http://mew.cx/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Feedback sought on osgViewer swap ready support forclusters

[Robert Osfield]

Hi Marco,

Thanks for the link.  I've run through it quickly but other than a listing
of extensions there isn't an actual coding example showing how they are
used.  I can make educated guess for most of them, but not enough to know
exactly how they should be used in the context of osgViewer - it looks like
most calls would be done after viewer.realize() (i.e. once windows are
created) and before the frame loop starts.  W.r.t swap ready barrier it's
not clear to me whether one needs to add an extra barrier call or whether
the normal swap buffers will be sync once one joins a swap group.

In the NVidia docs the extensions are all Windows ones, but looking at
glxext.h I can see various SwapGroup/Barrier methods that look like they
correspond. From searching fpr docs on these on the web it looks like these
don't require an extra sync call, rather swap buffer itself will have the
sync inbuilt into it.  If this is correct then one could do it all without
mods to osgViewer itself.

Once could however add support for these wgl/glx extension directly into
osgViewer, even if it its technical possible to do it without mods, as
adding such support might make it a bit more straight forward to OSG users,
perhaps only needing to enable the swap groups and to specify a single group
id across the cluster might be enough.   This changes I'm thinking of right
now at quite as extensive as this though.

The tweaks to the osgViewer API I was thinking of this time around was in
terms of non driver based support for syncing swap buffers, such as software
based ones.  It might be that we'd want to try and encapsulate some of the
API for this type of syncing with the above driver/glx/glw based sync
support.  Feedback from users who've tackled this would be very useful.

Robert.

On Mon, Apr 14, 2008 at 1:08 PM, Marco Jez <[EMAIL PROTECTED]> wrote:

> Hi Robert,
>
> > I'm looking for feedback from users who have worked on clusters that
> > implement some forms of swap ready synchronization.  In particular I'm
> > looking at any hooks into osgViewer to allow users to implement their
> own
> > swap ready implementation, also a software based swap ready could
> possibly
> > be implemented as part of the core OSG as well.
>
> I have limited experience with clusters, but this feature will probably be
> required in one of our new projects. You may find useful to read the
> "Frame
> Synchronization User's Guide" by nVIDIA
> (
> ftp://download.nvidia.com/Windows/Quadro_Certified/91.36/91.36_Quadro_G-Sync_User_Guide.pdf
> ),
> especially the section named "Frame Synchronization Using the OpenGL
> Extensions". The nVIDIA OpenGL API for hardware-based swap barriers is a
> good example of what an user would expect to be able to do in a custom
> swap
> ready operation.
>
> Cheers,
> Marco
>
> ___
> 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] How to disable culling of a node

[Emilio Lozano]

Thanks! I will try this way.

2008/4/14, Serge Lages <[EMAIL PROTECTED]>:
>
> Hi Emilio,
>
> I think the best way to achieve what you want is to render your scene
> using two osg::Camera (two pass), first render your scene and then render
> the object you want to be in the first plane. Each camera have it's own
> near/far clip planes.
>
> Cheers,
>
> On Mon, Apr 14, 2008 at 3:06 PM, Emilio Lozano <[EMAIL PROTECTED]> wrote:
>
> > Hi Joachim,
> >
> > It's true, I can set the clipping plane nearer to me. But then I get
> > z-fighting effects in my scene, due to loss of precision in depth buffer
> > when near plane is close to 0.0 (and far plane has a high value due to the
> > size of my landscape).
> >
> > Kind regards,
> > Emilio.
> >
> > 2008/4/14, Joachim E. Vollrath <[EMAIL PROTECTED]>:
> >
> > > Hi Emilio,
> > >
> > > the near clipping plane defines the border between things that are "in
> > > front" or "behind" you (resp. the camera).
> > >
> > > Since you cannot see what is behind you, I should expect that
> > > deactivating the clipping will not accomplish what you're looking for.
> > >
> > > If you want to see more of the ship model you mentioned, perhaps
> > > modifying the near clipping value accordingly might give the expected
> > > results.
> > >
> > > Best,
> > > Joachim
> > >
> > > --
> > > Joachim E. Vollrath
> > > Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
> > > web:   
> > > http://www.vis.uni-stuttgart.de/~vollrajm/
> > > mail:  [EMAIL PROTECTED]
> > > phone: 49.711.7816.403
> > > fax:   49.711.7816.213
> > >
> > > german postal address:
> > > Dipl. Inf. Joachim E. Vollrath
> > > Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
> > > Nobelstrasse 15
> > > 70569 Stuttgart
> > > GERMANY
> > >
> > > ___
> > > 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
> >
> >
>
>
> --
> Serge Lages
> http://www.tharsis-software.com
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to disable culling of a node

[Serge Lages]

Hi Emilio,

I think the best way to achieve what you want is to render your scene using
two osg::Camera (two pass), first render your scene and then render the
object you want to be in the first plane. Each camera have it's own near/far
clip planes.

Cheers,

On Mon, Apr 14, 2008 at 3:06 PM, Emilio Lozano <[EMAIL PROTECTED]> wrote:

> Hi Joachim,
>
> It's true, I can set the clipping plane nearer to me. But then I get
> z-fighting effects in my scene, due to loss of precision in depth buffer
> when near plane is close to 0.0 (and far plane has a high value due to the
> size of my landscape).
>
> Kind regards,
> Emilio.
>
> 2008/4/14, Joachim E. Vollrath <[EMAIL PROTECTED]>:
>
> > Hi Emilio,
> >
> > the near clipping plane defines the border between things that are "in
> > front" or "behind" you (resp. the camera).
> >
> > Since you cannot see what is behind you, I should expect that
> > deactivating the clipping will not accomplish what you're looking for.
> >
> > If you want to see more of the ship model you mentioned, perhaps
> > modifying the near clipping value accordingly might give the expected
> > results.
> >
> > Best,
> > Joachim
> >
> > --
> > Joachim E. Vollrath
> > Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
> > web:   
> > http://www.vis.uni-stuttgart.de/~vollrajm/
> > mail:  [EMAIL PROTECTED]
> > phone: 49.711.7816.403
> > fax:   49.711.7816.213
> >
> > german postal address:
> > Dipl. Inf. Joachim E. Vollrath
> > Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
> > Nobelstrasse 15
> > 70569 Stuttgart
> > GERMANY
> >
> > ___
> > 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
>
>


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

Re: [osg-users] Installing OSG in Ubuntu

[Jeremy Moles]

Also:

# apt-get install apt-file
# apt-file update

...and when something says you're "missing Foobar.h"...

# apt-file search Foobar.h

...and install. Never goes wrong. :)

On Mon, 2008-04-14 at 12:12 +0200, Alberto Luaces wrote:
> A starting point to get OSG and the most of its plugins would be:
> 
> apt-get install g++ cmake mesa-common-dev libungif4-dev libfreetype6-dev 
> libjasper-dev libtiff4-dev libxine-dev
> ___
> 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] custom drawable

[Robert Osfield]

Hi Erland,

Follow the various subclasses of osg::Drawable to see what is required, I'd
consider subclassing osg::Drawable an advanced topic so be prepared to
invest time in reviewing this various implementations and how they related
to the include/osg/Drawable.

As for display listing - if you do need this then call
setUseDisplayList(false) in your constructor, or better still if display
lists are never suitable call setSupportsDisplayList(false);

Robert.

On Mon, Apr 14, 2008 at 12:43 PM, <[EMAIL PROTECTED]> wrote:

>  i have some custom classes which inherits from osg::Drawable, and is
> inserted into an osg::Geode but nothing renders.
>
>
>
> I have implemented the drawImplementation(osg::RenderInfo & renderInfo)
> method to do some custom OpenGL rendering calls. I found that useDisplayList
> is initially true which caused drawImplementation to be called and creating
> a display list, but i need it to be false since i update some glTranslate
> params. When i set the Drawable's _*useDisplay List to false, the
> drawImplementation is not called at all. I also overrided the computeBound()
> method of the Drawable's to create a max bounding box(min==FLT*_MIN) (
> when is *computeBound() *method called btw? before culling if not allready
> set?) i call it in the constructor just to be sure its set. I notice Geode
> also has a _bounding box, but i guess this is calculated from the Drawable's
> bounding box.
>
>
>
> Do you have any advice on how what i am doing wrong? ( i know i should
> probably use the scenegraph a lot different but im only prototyping at this
> point..)
>
>
>
> Thanks in advance.
>
>
>
> Erlend.
>
>
>
>
>
> ___
> 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] About setFont() & readImageFile() on Internet

[Robert Osfield]

Hi Dolin,

To download from a server the .net plugin reads the data via custom
streambuf, which is attached to an istream that is in turn passed on to the
plugin that does the actual loaded.  This plugin has to support reading from
istream, not all plugins support istream.  Have a look at the plugins
ReaderWriter*.cpp file to see if there is a
readNode/readImage/readObject(istream) method.

Robert.

2008/4/14 <[EMAIL PROTECTED]>:

> Hello,all,
>
> could any know that why it doesn't take effects while I use setFont("
> http://www.aaa.com/aaa.ttf";)and osgDB::readImageFile("
> http://www.aaa.com/bbb.tga";)?
>
> and on Internet, if I use Text1->setFont("Fonts/simhei.ttf"); it also
> doesn't take effects,but "Fonts/simhei.ttf" is actually on System Fonts
> position,why?
>
> The code is following:
>
> 
> ..
>
>osgText::Text()* Text1 = new osgText::Text()
>Text1->setFont("http://www.aaa.com/aaa.ttf";);
>
> ..
>
>osg::Image* Image1 = new osg::Image;
>Image1->osgDB::readImageFile("http://www.aaa.com/bbb.tga";);
>
> ..
>
>  
>  The aaa.ttf and bbb.tga is on the right Web Server.
>
> Thank you.
>
> Donlin
>
>
>
> --
> 品质打动世界，星河湾全新三期热销中VIP:8610-8551
> ___
> 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] How to disable culling of a node

[Emilio Lozano]

Hi Joachim,

It's true, I can set the clipping plane nearer to me. But then I get
z-fighting effects in my scene, due to loss of precision in depth buffer
when near plane is close to 0.0 (and far plane has a high value due to the
size of my landscape).

Kind regards,
Emilio.

2008/4/14, Joachim E. Vollrath <[EMAIL PROTECTED]>:
>
> Hi Emilio,
>
> the near clipping plane defines the border between things that are "in
> front" or "behind" you (resp. the camera).
>
> Since you cannot see what is behind you, I should expect that
> deactivating the clipping will not accomplish what you're looking for.
>
> If you want to see more of the ship model you mentioned, perhaps
> modifying the near clipping value accordingly might give the expected
> results.
>
> Best,
> Joachim
>
> --
> Joachim E. Vollrath
> Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
> web:   http://www.vis.uni-stuttgart.de/~vollrajm/
> mail:  [EMAIL PROTECTED]
> phone: 49.711.7816.403
> fax:   49.711.7816.213
>
> german postal address:
> Dipl. Inf. Joachim E. Vollrath
> Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
> Nobelstrasse 15
> 70569 Stuttgart
> GERMANY
>
> ___
> 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] Feedback sought on osgViewer swap ready support forclusters

[Marco Jez]

Hi Robert,

> I'm looking for feedback from users who have worked on clusters that 
> implement some forms of swap ready synchronization.  In particular I'm 
> looking at any hooks into osgViewer to allow users to implement their own 
> swap ready implementation, also a software based swap ready could possibly 
> be implemented as part of the core OSG as well.

I have limited experience with clusters, but this feature will probably be 
required in one of our new projects. You may find useful to read the "Frame 
Synchronization User's Guide" by nVIDIA 
(ftp://download.nvidia.com/Windows/Quadro_Certified/91.36/91.36_Quadro_G-Sync_User_Guide.pdf),
 
especially the section named "Frame Synchronization Using the OpenGL 
Extensions". The nVIDIA OpenGL API for hardware-based swap barriers is a 
good example of what an user would expect to be able to do in a custom swap 
ready operation.

Cheers,
Marco

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

[osg-users] custom drawable

[erf]

i have some custom classes which inherits from osg::Drawable, and is inserted 
into an osg::Geode but nothing renders.

I have implemented the drawImplementation(osg::RenderInfo & renderInfo) method 
to do some custom OpenGL rendering calls. I found that useDisplayList is 
initially true which caused drawImplementation to be called and creating a 
display list, but i need it to be false since i update some glTranslate params. 
When i set the Drawable's _useDisplay List to false, the drawImplementation is 
not called at all. I also overrided the computeBound() method of the Drawable's 
to create a max bounding box(min==FLT_MIN) ( when is computeBound() method 
called btw? before culling if not allready set?) i call it in the constructor 
just to be sure its set. I notice Geode also has a _bounding box, but i guess 
this is calculated from the Drawable's bounding box.

Do you have any advice on how what i am doing wrong? ( i know i should probably 
use the scenegraph a lot different but im only prototyping at this point..)

Thanks in advance.

Erlend.


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

Re: [osg-users] How to disable culling of a node

[Joachim E. Vollrath]

Hi Emilio,

the near clipping plane defines the border between things that are "in 
front" or "behind" you (resp. the camera).

Since you cannot see what is behind you, I should expect that 
deactivating the clipping will not accomplish what you're looking for.

If you want to see more of the ship model you mentioned, perhaps 
modifying the near clipping value accordingly might give the expected 
results.

Best,
Joachim

-- 
Joachim E. Vollrath
Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
web:   http://www.vis.uni-stuttgart.de/~vollrajm/
mail:  [EMAIL PROTECTED]
phone: 49.711.7816.403
fax:   49.711.7816.213

german postal address:
Dipl. Inf. Joachim E. Vollrath
Visualisierungsinstitut der Universitaet Stuttgart (VISUS)
Nobelstrasse 15
70569 Stuttgart
GERMANY
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] About setFont() & readImageFile() on Internet

[Alberto Luaces]

El Lunes 14 Abril 2008ES 12:59:13 [EMAIL PROTECTED] escribió:
>  The aaa.ttf and bbb.tga is on the right Web Server.

There are problems when accesing those URLs:

The page cannot be found
The page you are looking for might have been removed, had its name changed, or 
is temporarily unavailable.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to disable culling of a node

[Emilio Lozano]

Hi all,

Thank you for your responses.

I realize that I didn't explain myself very well. What I am looking for is a
way to render a first person model in front of my scene (in my case, the bow
of a ship). I thought that with Node::setCullingActive() I could accomplish
this effect, I mean, to render my ship's model without being clipped by near
plane (because camera is in ship's bridge).

I don't want to remove near/far clipping planes, only to have the chance for
one of the scene's object not being affected by clipping planes.

Is it possible to do this? If so, do you have any advice?

Thanks to all.

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

[osg-users] About setFont() & readImageFile() on Internet

[xyc508]

Hello,all,
 
could any know that why it doesn't take effects while I use 
setFont("http://www.aaa.com/aaa.ttf";)and 
osgDB::readImageFile("http://www.aaa.com/bbb.tga";)?
 
and on Internet, if I use Text1->setFont("Fonts/simhei.ttf"); it also doesn't 
take effects,but "Fonts/simhei.ttf" is actually on System Fonts position,why?
 
The code is following:
 

.
 
   osgText::Text()* Text1 = new osgText::Text()
   Text1->setFont("http://www.aaa.com/aaa.ttf";);
 
.
 
   osg::Image* Image1 = new osg::Image;
   Image1->osgDB::readImageFile("http://www.aaa.com/bbb.tga";);
 
.
 

 The aaa.ttf and bbb.tga is on the right Web Server.
 
Thank you.
 
Donlin
 ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Installing OSG in Ubuntu

[Alberto Luaces]

A starting point to get OSG and the most of its plugins would be:

apt-get install g++ cmake mesa-common-dev libungif4-dev libfreetype6-dev 
libjasper-dev libtiff4-dev libxine-dev
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Feedback sought on osgViewer swap ready support for clusters

[Robert Osfield]

Hi All,

I'm looking for feedback from users who have worked on clusters that
implement some forms of swap ready synchronization.  In particular I'm
looking at any hooks into osgViewer to allow users to implement their own
swap ready implementation, also a software based swap ready could possibly
be implemented as part of the core OSG as well.

The hook to adding a swap ready barrier into the view would look something
like:

  viewer.setSwapReadyOperation(myCustomSwapReadyOperation);

Something like complicates the mater is that viewer on each slave of the
cluster might have more than one graphics context that its rendering too, so
in this case we'll have multiple graphics threads per slave, in which case
these threads will need to join a barrier that treats each context like a
separate machine or the barrier does a local synchronization of the threads
on a machine before joining the cluster swap ready barrier.

I want to come up with a scheme that supports both ways above, but really
need a bit more feedback on what goes into users own swap ready codes, i.e.
what would your MyCustomSwapReadyOperation look like, i.e. what does it look
right now, this will help me better understand how the most appropriate
integration into osgViewer could be done.

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

Re: [osg-users] EllipsoidModel funtion parameters units

[nicolas peña]

Thanks Robert.

Nicolas.

2008/4/14, Robert Osfield <[EMAIL PROTECTED]>:
>
> Hi Nicolas,
>
> > Just a quick question: The latitude and longitude parameters of
> convertLatLongHeightToXYZ are in radians, and the >rest of parameters in
> meters?
>
> This is correct.  To help in future I've added clarification of units into
> the doxygen docs of EllipsoidModel.
>
> 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] problem when using multi-sceneview in 2.3

[Robert Osfield]

Hi Wangmiao,

Using multiple SceneViews does work in 2.x, osgViewer uses SceneViews under
the hood to implement rendering, and it supports multiple views across one
or more graphics context without any problems.

As to why things are working your app I can't really even have a guess at as
I don't know the code.

Robert.

On Mon, Apr 14, 2008 at 6:56 AM, wangmiao <[EMAIL PROTECTED]> wrote:

> Hello every one,
> I meet a problem when switching to osg 2.33 , multi-sceneviews doesn't
> work for 2 or more contextes.
> I do it like these:
> 1. build opengl contex by opengl call
> 2.sceneview.Init()
> looploop
> 3.destory sceneview AND  releaseAllGLObjects
> 4.destory context  wglDeleteContext
> every context has an individual contextid set by
> m_sceneview->getState()->setContextID
> this works perfect with osg 1.2.
> Is there any change may cause this problem? Thanks!
>
>
>  wangmiao
> ___
> 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] EllipsoidModel funtion parameters units

[Robert Osfield]

Hi Nicolas,

> Just a quick question: The latitude and longitude parameters of
convertLatLongHeightToXYZ are in radians, and the >rest of parameters in
meters?

This is correct.  To help in future I've added clarification of units into
the doxygen docs of EllipsoidModel.

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

Re: [osg-users] databasepager new node inserted callback???

[till busch]

hi david,

in order to do something similar i have subclassed PagedLOD and reimplemented 
addChild(), which gets called by the DatabasePager when a new node is added.

depending on your circumstances, roberts suggestion 
(osgDB::Registry::ReadFileCallback) might be easier to implement.

-till


On Friday 11 April 2008, David _ wrote:
> Is there any way to know when the data base pager loads a new node in the
> graph??
>
> right now i´m running through the whole graph each frame after the
> updateTraversal in order to see if the dbp has added a new node so i can
> make some stuff with it before it´s rendered on the screen
>
> is there any callback that i can set in the DBP so it´s called every time a
> new node is added in order to avoid visiting the whole graph in every
> frame???
>
> another question: any callback when the DBP deletes a node from the graph??
>
> thanks
>
> edit: sorry for my english
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org