[osg-users] How to hide a RTT camera's clear color

[Eduardo Alberto Hernández Muñoz]

Hi all,

I have a RTT camera for cube mapped reflections; it now works well,
except that I want to show only the reflected objects, not the clear
color, when applied to an object; I have tried using the clear color's
alpha with TexEnv, TexEnvCombine and AlphaFunc but I never got the
result I wanted.

Any pushes in the right direction?

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

[osg-users] Real-time BVH

[Brad Eric Hollister]

Does OSG contain a dynamic bounding volume hierarchy? If not, is it possible to 
contribute one that I have implemented for Performer?___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] help

[Oscar De Leon]

 I'm trying to set a camera that follows a node with a Cameraview node, but
   I've some troubles. In a request I've sended before I used slave cameras
and
   I tried to manually position of cameras using setViewMatrix and set
   perspective matrix but it didn't work because the master camera of viewer
   overwrite the matrices so i don't realize the meaning of allow to set the
   master camera matrices, but It doesn't matter. Following some idea I
   modofied the code adding a cameraview node to the scene graph as a leaf
of
   root and the model as  a separated branch with a position transform, then
y
   obtained the model matrices and set the master camera view with it.
   Bassically this is the same mistake, the matrices are overwritten and I
get
   the same view. So, my question is What should I do to get the view from
the
   point I want?? Here is the code, Im a newbie in this things, so please
don
   laugh so loud.
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 
   #include 

- Ignored:
   #include 
   #include 
   #include 
   #include 

   #include 
   #include 

   #include 

   #include 
   #include 
   #include 
   #include 
   #include 
   #include 

   #include 
   using namespace std;
   int main()
   {
  //osg::Node* groundNode = NULL;
  osg::Node* tankNode = NULL;
  //osg::Node* pantherNode=NULL;
  osg::CameraView* cameraNode=new osg::CameraView;
  osg::Group* root = new osg::Group();
  osgViewer::Viewer viewer;
  osg::PositionAttitudeTransform* tankXform;

 //groundNode = osgDB::readNodeFile("");
 tankNode = osgDB::readNodeFile("/root/ElephantTank/M1A1_v04b.3DS");

  osg::ClearNode* backdrop = new osg::ClearNode;
  backdrop->setClearColor(osg::Vec4(0.0f,0.0f,0.5f,1.0f));

  root->addChild(backdrop);

  tankXform = new osg::PositionAttitudeTransform();

  //  root->addChild(tankXform);
  root->addChild(tankXform);

  tankXform->addChild(tankNode);
  tankXform->setPosition( osg::Vec3(0,0,0) );
  tankXform->setAttitude(osg::Quat(osg::DegreesToRadians(0.0),
   osg::Vec3(1,2,3) ) );

  cameraNode->setPosition(osg::Vec3(100,100,100));
  cameraNode->setFocalLength(0.0);

  osg::MatrixList matrixList;
  matrixList=tankNode->getWorldMatrices(tankNode);
  root->addChild(cameraNode);
   osg::ref_ptr traits = new
   osg::GraphicsContext::Traits;
   traits->x = 250;
   traits->y = 200;
   traits->width = 1000;
   traits->height = 800;
   traits->windowDecoration = true;
   traits->doubleBuffer = true;
   traits->sharedContext = 0;

   osg::ref_ptr gc =
   osg::GraphicsContext::createGraphicsContext(traits.get());
   if (gc.valid())
   {
   // need to ensure that the window is cleared make sure that
the
   complete window is set the correct colour
   // rather than just the parts of the window that are under
the
   camera's viewports
   gc->setClearColor(osg::Vec4f(0.2f,0.2f,0.6f,1.0f));
   gc->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   }
   else
   {
   osg::notify(osg::NOTICE)<<"  GraphicsWindow has not been
created
   successfully."setViewport(new
   osg::Viewport(0,0,traits->width,traits->height));
   osg::Matrixd viewMatrix=matrixList.at(0);
   coutgetViewMatrix()).translate(osg::Vec3d(10,10,10)));


viewer.setSceneData(root);
return(viewer.run());

   }

   So, I read that is necessary to set an UpdteVisitor to make the render
but I
   don't get the idea very well, so if you know how to do this or you know
   another plan, tell me.
   Thank you so much.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ODE Trimesh with OSG ?

[Carlos Sanches]

I said terrain but I want to load a object from 3DMAX  and do collision if
trimesh in ODE.


First ,I m trying to understand how to transform my object that I read like
a .ive file in a osg::TriMesh .
May you explain me ?



On Mon, Aug 18, 2008 at 4:06 AM, Mattias Helsing <[EMAIL PROTECTED]>wrote:

> Hello Carlos!
>
> We use a TriangleRecorder (it's a NodeVisitor) and applies that to our
> terrain nodetree. It records vertices and triangles on all drawables.
> We then memcpy those into ode::dVector3[numVertices] (vertices) and
> int[3*numTriangles] (triangles). Then run
>
> dGeomTriMeshDataBuildSimple(
> and
> dCreateTriMesh
>
> unfortunately a cannot publish any code. I once had a plan to
> implement this better in my spare time but haven't got around to it
> yet. Yuo might watn to look at Delta3d since I know that they
> integrate ode with osg. I haven't looked at ode code in Delta3d myself
> but I'm sure it fine.
>
> Also:
>  * the above simple description doesn't mention dynamic(paged) terrain
> so you may need to think about that.
>  * Some of the terrains we have tried have been simplified, i.e. some
> trianles are very large, and ode seems to have problems with that.
>
> hope this helps
> Mattias
>
>
> On 8/18/08, Carlos Sanches <[EMAIL PROTECTED]> wrote:
> > Hi!
> > I m doing collisions using ODE with OSG and this is very cool, but , I
> want
> > to do a deformed ground with some triangles in 3DSMAX for example. I know
> > that I have to use trimesh but how do I have to load the object ground
> that
> > ODE understand ??
> >
> > Have anybody an example using trimesh ??
> >
> > Thank you!
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Carlos Sanches
Analista de Sistemas e computação gráfica
Tel: 55 11 3816 2888
Cel: 55 11 9650 7137

Somar Meteorologia
www.somarmeteorologia.com.br
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Tracking 2.6 branch changes

[Paul Melis]

Paul Martz wrote:
I just committed what appears to be the first change to the 2.6 branch 
post-release (see "[osg-submissions] Fix for PAT in FLT export").
 
Robert, how do you update the changeLog, are you just pulling it from 
svn periodically or do you have some kind of automatic mechanism in 
place? My concern here is that we track the changes to the 2.6 branch 
so that when/if we do a 2.6.1 release, we can easily create release 
notes that describe what went into it.
I find Changelogs hard to read, usually due to cryptic log entries. Plus 
there's more in the log than needs to be in the release notes (and vice 
versa).
I think writing release notes as we go is the easiest. We can continue 
to keep the current style of commit messages.


For (automatically) keeping track of merges between branches I'd once 
again would like to point out svnmerge 
(http://www.orcaware.com/svn/wiki/Svnmerge.py). It not only keeps track 
of which revisions have already been merged and which ones are left to 
be merged for a branch, but it also produces commit messages that 
contain the original log entries of the revisions that got merged.


Paul M

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

[osg-users] Tracking 2.6 branch changes

[Paul Martz]

I just committed what appears to be the first change to the 2.6 branch
post-release (see "[osg-submissions] Fix for PAT in FLT export").
 
Robert, how do you update the changeLog, are you just pulling it from svn
periodically or do you have some kind of automatic mechanism in place? My
concern here is that we track the changes to the 2.6 branch so that when/if
we do a 2.6.1 release, we can easily create release notes that describe what
went into it.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Write Heightfield File

[Luc Heischbourg]

Hi @all,

I have tried to save an osg::Heightfield into a file, but it has not
succeeded. Have used the function osgDB::writeHeightFieldFile(*hf, "C:\
\heightfield.osg")).. is the extension wrong or should I install
further plugins (gdal plugin)?

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

Re: [osg-users] How to Monitor VideoMemory usage

[Jason Daly]

Bob Balfour wrote:

I've used RivaTuner to monitor video memory usage on WinXP, but it
doesn't do it on Vista (it says due to Vista's virtualization of video
memory?).  Does anyone know of a way to monitor video memory usage on
WinVista?  I have a very "choppy" scene (using quad-core HP, 2 Nvidia
GTX8800, Vista, multi-thread OSG2.4-based app), and I suspect its due to
texture overload.  Whatever Vista is "virtualizing" didn't seem to help!
  


You probably need something like gDEBugger that can talk to the video 
card's performance counters directly.  Unfortunately, it isn't free, but 
you can get a free 30-day trial to see if it works for what you're 
trying to do.


--"J"

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

[osg-users] How to Monitor VideoMemory usage

[Bob Balfour]

I've used RivaTuner to monitor video memory usage on WinXP, but it 
doesn't do it on Vista (it says due to Vista's virtualization of video 
memory?).  Does anyone know of a way to monitor video memory usage on 
WinVista?  I have a very "choppy" scene (using quad-core HP, 2 Nvidia 
GTX8800, Vista, multi-thread OSG2.4-based app), and I suspect its due to 
texture overload.  Whatever Vista is "virtualizing" didn't seem to help!


Thanks.

Bob.
--

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

[osg-users] Add a PNG FIle to a terrain model in osgviewer

[dzff fxdgjfrj]

Hi,

I have a terrain model built with VPB and I need to modify the osgviewer to add 
PNG files with transparecy.

Can you give me any ideas.

Thanks,
Oscar Romero

_
¡El Mundo Messenger te espera! Entra ya en "I love Messenger" y descubre las 
últimas novedades, trucos, emoticonos…
http://www.vivelive.com/ilovemessenger/___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Generate MipMap bug

[Mark Sciabica]

Hi Robert,

I attached the modified Texture2D.cpp as well as the sample program 
illustrating the bug.


Regards,

Mark

Robert Osfield wrote:

HI Mark,

Could you send the whole test example and whole changed file as
copying and pasting from emails leads to various errors.

Cheers,
Robert.

On Thu, Aug 21, 2008 at 8:00 PM, Mark Sciabica <[EMAIL PROTECTED]> wrote:
  

Hi All,

I'm in the process of upgrading 2.2 ->2.6 and came across a bug in mipmap
generation. For NPOT textures when the ResizeNonPowerOfTwoHint is false, I'm
not getting textures applied correctly.

Sample program demonstrating the bug:

#include 
#include 

#include 
#include 

int main(int, char **)
{
osg::ref_ptr redTexture = new osg::Texture2D;
osg::Image* image = new osg::Image;
static unsigned char bytes[12] = { 0xff, 0x00, 0x00, 0xff, 0xff, 0x00,
0x00, 0xff, 0xff, 0x00, 0x00, 0xff };
image->setImage(3, 1, 1, GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE, &bytes[0],
osg::Image::NO_DELETE, 1);
redTexture->setImage(image);
redTexture->setResizeNonPowerOfTwoHint(false);
redTexture->setFilter( osg::Texture::MIN_FILTER,
osg::Texture::LINEAR_MIPMAP_LINEAR );

osg::ref_ptr geode = new osg::Geode();
osg::ref_ptr sphere1 = new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),10));
geode->addDrawable(sphere1.get());

osg::ref_ptr text = new osgText::Text();
text->setText( L"Text" );
text->setAxisAlignment(osgText::Text::XZ_PLANE);

osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);

viewer.setSceneData( geode.get() );

osg::StateSet* stateset = new osg::StateSet();
stateset->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
stateset->setTextureAttributeAndModes(0, redTexture.get(),
osg::StateAttribute::ON);
geode->setStateSet( stateset );

viewer.run();

return 0;
}

The problem appears to be that in mipmapAfterTexImage, called by
applyTexImage2D_load, getTextureObject(contextID) is returning NULL. Moving
the assignment of the TextureObject to the _textureObjectBuffer before
applyTexImage2D_load is called fixes the problem. The change to
Texture2D::apply is shown below, controlled by #define MIPMAP_FIX. Other
code (in the same function even) is assigning to _textureObjectBuffer
immediately upon generation of the TextureObject so I figure this should be
a safe change.

void Texture2D::apply(State& state) const
{

//state.setReportGLErrors(true);

// get the contextID (user defined ID of 0 upwards) for the
// current OpenGL context.
const unsigned int contextID = state.getContextID();

// get the texture object for the current contextID.
TextureObject* textureObject = getTextureObject(contextID);

if (textureObject != 0)
{
textureObject->bind();

if (getTextureParameterDirty(state.getContextID()))
applyTexParameters(GL_TEXTURE_2D,state);

if (_subloadCallback.valid())
{
_subloadCallback->subload(*this,state);
}
else if (_image.valid() && getModifiedCount(contextID) !=
_image->getModifiedCount())
{
applyTexImage2D_subload(state,GL_TEXTURE_2D,_image.get(),
_textureWidth, _textureHeight,
_internalFormat, _numMipmapLevels);

// update the modified tag to show that it is up to date.
getModifiedCount(contextID) = _image->getModifiedCount();

}
else if (_readPBuffer.valid())
{
_readPBuffer->bindPBufferToTexture(GL_FRONT);
}

}
else if (_subloadCallback.valid())
{

_textureObjectBuffer[contextID] = textureObject =
generateTextureObject(contextID,GL_TEXTURE_2D);

textureObject->bind();

applyTexParameters(GL_TEXTURE_2D,state);

_subloadCallback->load(*this,state);


textureObject->setAllocated(_numMipmapLevels,_internalFormat,_textureWidth,_textureHeight,1,0);

// in theory the following line is redundent, but in practice
// have found that the first frame drawn doesn't apply the textures
// unless a second bind is called?!!
// perhaps it is the first glBind which is not required...
//glBindTexture( GL_TEXTURE_2D, handle );

}
else if (_image.valid() && _image->data())
{

// keep the image around at least till we go out of scope.
osg::ref_ptr image = _image;

// compute the internal texture format, this set the _internalFormat
to an appropriate value.
computeInternalFormat();

// compute the dimensions of the texture.
computeRequiredTextureDimensions(state,*image,_textureWidth,
_textureHeight, _numMipmapLevels);

#define MIPMAP_FIX
#if defined MIPMAP_FIX
_textureObjectBuffer[contextID] = textureObject =
generateTextureObject(

contextID,GL_TEXTURE_2D,_numMipmapLevels,_internalFormat,_textureWidth,_textureHeight,1,0);
#else
 textureObject = generate

Re: [osg-users] FLT writer and PositionAttitudeTransform

[Paul Martz]

There is shared code for all the Transforms that depends on a Matrix
representation, and it appears that the code for converting the
PositionAttitudeTransform to a Matrix is bogus. I'm working on a fix and
should post it shortly.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Argentieri,
John-P63223
Sent: Thursday, August 21, 2008 7:50 AM
To: [EMAIL PROTECTED]
Subject: Re: [osg-users] FLT writer and PositionAttitudeTransform


Paul,
 
The attached file demonstrates the bug with PositionAttitudeTransform if you
convert it to FLT. View it in wireframe to see the problem.
 
John

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz
Sent: Wednesday, August 20, 2008 10:03 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] FLT writer and PositionAttitudeTransform


Sounds like a bug. You can fix it yourself and submit a change, or post a
.osg file that can be ran through osgconv to repro the issue. I'll add it to
my queue, or maybe someone else will chip in and fix it. I do recall PAT was
someone difficult to support during FLT export.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Argentieri,
John-P63223
Sent: Wednesday, August 20, 2008 3:00 PM
To: [EMAIL PROTECTED]
Subject: [osg-users] FLT writer and PositionAttitudeTransform



All, 

I've built a little cube and placed it on the surface of a big square using
PositionAttitudeTransform. 

No surprise that this works great during runtime in OSG 2.6. 

Then, I make a call to osgDB::writeNodeFile and save it as both IVE and FLT.

In the IVE file, it looks just like it did during runtime. 
BUT, in the FLT file, it looks like it breaks the order of rotate/translate
operations and flops the little cube way off the surface of the big square.

Any thoughts? 

Thanks, 
John Argentieri 
Software Engineer 
GENERAL DYNAMICS 
C4 Systems 
(407) 281-5568 
[EMAIL PROTECTED] 

"This email message is for the sole use of the intended recipient(s) and may
contain GDC4S confidential or privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not an
intended recipient, please contact the sender by reply email and destroy all
copies of the original message."

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

Re: [osg-users] Segfaults in osg::State::applyTextureAttributes when working with osgText::Text

[Alexander Löffler]

Hi Robert,

Robert Osfield wrote:

Hi Alexander,

Are you dynamically modifying the text?  If so then just set the
DataVariance of the Text objects to DYNAMIC.

Explanation : When running in DrawThreadPerContext, and
CullThreadPerCameraDrawThreadPerContext the update,cull of the next
frame is allowed to overlap with rendering of the previous frame.
This also means that their is potential for the update phase to be
modifying the scene graph at the same time that its being read - which
causes crashes.  The mechinism for prevent these read/write collisions
is to set the dynamically modified Drawables and
StateSet/StateAttribute to have a DataVariance of DYNAMIC, and then
the rendering traversal then holds back the next frame till all
DYNAMIC objects have been drawn.

This topic has been written about lots of time on osg-users over the
past year, and also mentioned in the Quick Start Guide.


yes, I dynamically modify text a lot in my application and setting the 
DataVariance correctly completely resolved the issue for now. I've used 
DataVariance a lot, but saw it more as an optimization device and didn't know 
that setting it wrong could cause such problems.


Thanks a lot for your immediate help,
Alex.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Segfaults in osg::State::applyTextureAttributes when working with osgText::Text

[Alexander Löffler]

Hi David,

David Spilling wrote:

There was a whole load of message traffic on this topic a while ago. From
what I remember, the upshot was that the freetype library wasn't thread
safe. I don't know whether it all got finally resolved or not; my advice
would be to check the archives.


thanks for your quick answer. I saw these threads:

http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg01489.html
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg05841.html

Both sounded quite "resolved" to me in the end (but maybe the the original 
authors can veto on that). I also ran the multithreaded example mentioned 
(osgtext --mt) with 5 threads and more without a crash or even the slightest 
problem. That is why I thought those problems would not apply anymore. Also, the 
posts are up to a year old and text seems to me being something that many people 
need. Also in a multithreaded application. :)


Anyways, my problems are quite similar; so it is probable the crashes are 
somehow freetype's fault. Can somebody say something about the status of 
multithreaded text in the current OSG?


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

Re: [osg-users] Segfaults in osg::State::applyTextureAttributes when working with osgText::Text

[Robert Osfield]

Hi Alexander,

Are you dynamically modifying the text?  If so then just set the
DataVariance of the Text objects to DYNAMIC.

Explanation : When running in DrawThreadPerContext, and
CullThreadPerCameraDrawThreadPerContext the update,cull of the next
frame is allowed to overlap with rendering of the previous frame.
This also means that their is potential for the update phase to be
modifying the scene graph at the same time that its being read - which
causes crashes.  The mechinism for prevent these read/write collisions
is to set the dynamically modified Drawables and
StateSet/StateAttribute to have a DataVariance of DYNAMIC, and then
the rendering traversal then holds back the next frame till all
DYNAMIC objects have been drawn.

This topic has been written about lots of time on osg-users over the
past year, and also mentioned in the Quick Start Guide.

Robert.

On Fri, Aug 22, 2008 at 10:36 AM, Alexander Löffler
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I am experiencing very frequent segfaults in OSG'S rendering thread when
> working with osgText::Text objects. The problem always appears in
> State::applyTextureAttributes(), but at different positions in there. Most
> of the time in StateAttribute::getTypeMemberPair(), though, an exemplary
> backtrace for this is attached.
>
> The crash happens when changing text attributes, like color and size, but
> also when manipulating higher-level objects in the scene graph (setting
> NodeMasks of subgraphs containing the Text, etc.).
>
> Has anyone experienced similar behavior before? It always seems to be
> connected to updates of textures, especially when having overlapping
> textures like Text on top of an image texture.
>
> Could this also be somehow related to third party libraries like Freetype?
>
> Thanks a lot for your help,
> Alex.
>
> BTW, I am working with OSG 2.6.0 under Linux (SUSE, GCC 4.2.1) and an nVidia
> GeForce 8400.
>
> --
>
> #0  0xb6dba374 in osg::StateAttribute::getTypeMemberPair (this=0x862b7f0)
>at /home/al/src/OpenSceneGraph-2.6.0/include/osg/StateAttribute:228
> #1  0xb6dc2945 in osg::State::applyTextureAttribute (this=0x8212840, unit=0,
> attribute=0x862b7f0)
>at /home/al/src/OpenSceneGraph-2.6.0/include/osg/State:335
> #2  0xb60ec704 in osgText::Text::renderOnlyForegroundText (this=0xac1213e0,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgText/Text.cpp:1750
> #3  0xb60efc1a in osgText::Text::drawImplementation (this=0xac1213e0,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgText/Text.cpp:1365
> #4  0xb60f01ee in osgText::Text::drawImplementation (this=0xac1213e0,
> [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgText/Text.cpp:1252
> #5  0xb63cb5cb in osg::Drawable::draw (this=0xac1213e0,
> [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/include/osg/Drawable:895
> #6  0xb63ca508 in osgUtil::RenderLeaf::render (this=0x83114f0,
> [EMAIL PROTECTED], previous=0x8315610)
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderLeaf.cpp:60
> #7  0xb63bed52 in osgUtil::RenderBin::drawImplementation (this=0x8969248,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:419
> #8  0xb63be5cd in osgUtil::RenderBin::draw (this=0x8969248,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:384
> #9  0xb63befe4 in osgUtil::RenderBin::drawImplementation (this=0x8215bb8,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:469
> #10 0xb63cc062 in osgUtil::RenderStage::drawImplementation (this=0x8215bb8,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderStage.cpp:1233
> #11 0xb63be5cd in osgUtil::RenderBin::draw (this=0x8215bb8,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:384
> #12 0xb63ccb48 in osgUtil::RenderStage::drawInner (this=0x8215bb8,
> [EMAIL PROTECTED], [EMAIL PROTECTED],
>[EMAIL PROTECTED]) at
> /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderStage.cpp:829
> #13 0xb63cf995 in osgUtil::RenderStage::draw (this=0x8215bb8,
> [EMAIL PROTECTED], [EMAIL PROTECTED])
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderStage.cpp:1090
> #14 0xb63dda57 in osgUtil::SceneView::draw (this=0x8214d60) at
> /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/SceneView.cpp:1509
> #15 0xb6a9f756 in osgViewer::Renderer::draw (this=0x8214b60) at
> /home/al/src/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:413
> #16 0xb6a9b2db in osgViewer::Renderer::operator() (this=0x8214b60,
> context=0x80bbe58)
>at /home/al/src/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:640
> #17 0xb6e0d96c in osg::GraphicsContext::runOperations (this=0x80bbe58)
>at /home/al/src/OpenSceneGraph-2.6.0/src/osg/GraphicsContext.cpp:688
> #18 0xb6e18fd5 in osg::RunOperations:

Re: [osg-users] Challenge for DatabasePager and cameras with high zoom

[Robert Osfield]

Hi Ralf,

Only tiles that are required for the view frustum are paged in, so you
shouldn't have any problems with too many tiles being loaded at high
resolution.

Robert.

On Fri, Aug 22, 2008 at 9:30 AM, Ralf Stokholm <[EMAIL PROTECTED]> wrote:
> Hi Robert
>
> Im using the setLodScale and that works fine solved  the huge problems i had
> before.
>
> But based on my current understanding the range based lod scale is less than
> optimal for a camera with a large zoom that will only change its
> transformation in the world slowly. It will page in an enourmous amount on
> textures but will only ever display a small percentage.
>
> This sort of camera must be perfectly suited to a frustrum or screen based
> paging algorithm, and my question was if it in your oppinion was feasable in
> the current architecture to integrate this as an optional pagingalgorithm.
>
> Based on Ulrichs answer somethin similar might already exist though?
>
> Brgs.
>
> Ralf
>
> 2008/8/22 Robert Osfield <[EMAIL PROTECTED]>
>>
>> Hi Ralf,
>>
>> You can use LODScale to scale the LOD ranges to fit case where you
>> want to zoom in.  This can be done without modifying the scene graph
>> at - just by setting the osg::Camera in question i.e
>>
>>  mycamera->setLODScale(0.25);
>>
>> Robert.
>>
>> On Fri, Aug 22, 2008 at 8:52 AM, Ralf Stokholm <[EMAIL PROTECTED]>
>> wrote:
>> > Hi List
>> >
>> > Im working on a flightsimulator and have a wery high resolution
>> > orthophoto
>> > based terrain.
>> >
>> > One of my cameras is a targetingpod(TGP) camera with a very high zoom
>> > factor, to compensate for this I set the cameras lodscale to fit. This
>> > all
>> > works fine but the range based loading of lods could be optimised for
>> > the
>> > Targeting pod camera by basing it on the frustrum. The TGP will ofthen
>> > focus
>> > at the same spot for a loong time and will rearly have a high rate when
>> > changing focus.
>> >
>> > So I guess my questin is if it is viable to design the a special paging
>> > scheme based on not only range but also the direction of the camera.
>> >
>> > This could then substitute the normal range based paging for special
>> > applications like my TGP camera.
>> >
>> > Brgs.
>> >
>> > Ralf Stokholm
>> > Arenalogic
>> >
>> > ___
>> > osg-users mailing list
>> > osg-users@lists.openscenegraph.org
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> >
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] present3d + compositeViewer

[Robert Osfield]

Hi Dieter,

On Fri, Aug 22, 2008 at 9:40 AM, Dieter Pfeffer
<[EMAIL PROTECTED]> wrote:
> - to use it as a single view within a viewer - does this mean that I can
> change in the present3d sources from viewer to view and use addView
> (present3d_view) in my application?

Well you could try modifying present3d.cpp so that it creates a
CompositeViewer, and adds a View instead of using a straight Viewer.

However, Present3D in its present incarnation is a program, not a
library, so you can't just staight link it into another application.

Also, can you confirm that your application is under the GPL and that
all modifications to present3D will be released under the GPL?   If
it's isn't, then trying to use the Present3D in this way you your
application is Copyright infringement.

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

Re: [osg-users] Segfaults in osg::State::applyTextureAttributes when working with osgText::Text

[David Spilling]

Alex,

There was a whole load of message traffic on this topic a while ago. From
what I remember, the upshot was that the freetype library wasn't thread
safe. I don't know whether it all got finally resolved or not; my advice
would be to check the archives.

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

Re: [osg-users] Segfaults in osg::State::applyTextureAttributes when working with osgText::Text

[Alexander Löffler]

Alexander Löffler wrote:
I am experiencing very frequent segfaults in OSG'S rendering thread when 
working with osgText::Text objects. The problem always appears in 
State::applyTextureAttributes(), but at different positions in there. 
Most of the time in StateAttribute::getTypeMemberPair(), though, an 
exemplary backtrace for this is attached.


The crash happens when changing text attributes, like color and size, 
but also when manipulating higher-level objects in the scene graph 
(setting NodeMasks of subgraphs containing the Text, etc.).


Has anyone experienced similar behavior before? It always seems to be 
connected to updates of textures, especially when having overlapping 
textures like Text on top of an image texture.


Could this also be somehow related to third party libraries like Freetype?

Thanks a lot for your help,
Alex.

BTW, I am working with OSG 2.6.0 under Linux (SUSE, GCC 4.2.1) and an 
nVidia GeForce 8400.


Oh, I forgot to mention that the segfaults happen only when running the 
osgViewer displaying my scene in any of the multithreaded modes. When switching 
the TreadingModel to SingleThreaded, none of the errors occur anymore.


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

Re: [osg-users] Challenge for DatabasePager and cameras with high zoom

[Ulrich Hertlein]

Ulrich Hertlein wrote:
> Ralf Stokholm wrote:
>> Havent tried that, is this a camera setting or will it affect my pilot
>> view camera as well?
> 
> Can't say for sure but it should since the screen area of the LOD (bounding 
> sphere I
> assume) changes with the projection matrix.

Sorry, I meant it should *not* affect another view.
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Challenge for DatabasePager and cameras with high zoom

[Ulrich Hertlein]

Ralf Stokholm wrote:
> Havent tried that, is this a camera setting or will it affect my pilot
> view camera as well?

Can't say for sure but it should since the screen area of the LOD (bounding 
sphere I
assume) changes with the projection matrix.

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

[osg-users] Segfaults in osg::State::applyTextureAttributes when working with osgText::Text

[Alexander Löffler]

Hi all,

I am experiencing very frequent segfaults in OSG'S rendering thread when working 
with osgText::Text objects. The problem always appears in 
State::applyTextureAttributes(), but at different positions in there. Most of 
the time in StateAttribute::getTypeMemberPair(), though, an exemplary backtrace 
for this is attached.


The crash happens when changing text attributes, like color and size, but also 
when manipulating higher-level objects in the scene graph (setting NodeMasks of 
subgraphs containing the Text, etc.).


Has anyone experienced similar behavior before? It always seems to be connected 
to updates of textures, especially when having overlapping textures like Text on 
top of an image texture.


Could this also be somehow related to third party libraries like Freetype?

Thanks a lot for your help,
Alex.

BTW, I am working with OSG 2.6.0 under Linux (SUSE, GCC 4.2.1) and an nVidia 
GeForce 8400.


--

#0  0xb6dba374 in osg::StateAttribute::getTypeMemberPair (this=0x862b7f0)
at /home/al/src/OpenSceneGraph-2.6.0/include/osg/StateAttribute:228
#1  0xb6dc2945 in osg::State::applyTextureAttribute (this=0x8212840, unit=0,
attribute=0x862b7f0)
at /home/al/src/OpenSceneGraph-2.6.0/include/osg/State:335
#2  0xb60ec704 in osgText::Text::renderOnlyForegroundText (this=0xac1213e0,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgText/Text.cpp:1750
#3  0xb60efc1a in osgText::Text::drawImplementation (this=0xac1213e0,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgText/Text.cpp:1365
#4  0xb60f01ee in osgText::Text::drawImplementation (this=0xac1213e0,
[EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgText/Text.cpp:1252
#5  0xb63cb5cb in osg::Drawable::draw (this=0xac1213e0, [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/include/osg/Drawable:895
#6  0xb63ca508 in osgUtil::RenderLeaf::render (this=0x83114f0,
[EMAIL PROTECTED], previous=0x8315610)
at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderLeaf.cpp:60
#7  0xb63bed52 in osgUtil::RenderBin::drawImplementation (this=0x8969248,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:419
#8  0xb63be5cd in osgUtil::RenderBin::draw (this=0x8969248,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:384
#9  0xb63befe4 in osgUtil::RenderBin::drawImplementation (this=0x8215bb8,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:469
#10 0xb63cc062 in osgUtil::RenderStage::drawImplementation (this=0x8215bb8,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderStage.cpp:1233
#11 0xb63be5cd in osgUtil::RenderBin::draw (this=0x8215bb8,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderBin.cpp:384
#12 0xb63ccb48 in osgUtil::RenderStage::drawInner (this=0x8215bb8,
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) at
/home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderStage.cpp:829
#13 0xb63cf995 in osgUtil::RenderStage::draw (this=0x8215bb8,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/RenderStage.cpp:1090
#14 0xb63dda57 in osgUtil::SceneView::draw (this=0x8214d60) at
/home/al/src/OpenSceneGraph-2.6.0/src/osgUtil/SceneView.cpp:1509
#15 0xb6a9f756 in osgViewer::Renderer::draw (this=0x8214b60) at
/home/al/src/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:413
#16 0xb6a9b2db in osgViewer::Renderer::operator() (this=0x8214b60,
context=0x80bbe58)
at /home/al/src/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:640
#17 0xb6e0d96c in osg::GraphicsContext::runOperations (this=0x80bbe58)
at /home/al/src/OpenSceneGraph-2.6.0/src/osg/GraphicsContext.cpp:688
#18 0xb6e18fd5 in osg::RunOperations::operator() (this=0x82171d8, 
context=0x80bbe58)
at /home/al/src/OpenSceneGraph-2.6.0/src/osg/GraphicsThread.cpp:134
#19 0xb6e196bc in osg::GraphicsOperation::operator() (this=0x82171d8,
object=0x80bbe58)
at /home/al/src/OpenSceneGraph-2.6.0/src/osg/GraphicsThread.cpp:50
#20 0xb6e5dab4 in osg::OperationThread::run (this=0x8216f58) at
/home/al/src/OpenSceneGraph-2.6.0/src/osg/OperationThread.cpp:413
#21 0xb6e1975b in osg::GraphicsThread::run (this=0x8216f58) at
/home/al/src/OpenSceneGraph-2.6.0/src/osg/GraphicsThread.cpp:38
#22 0xb67b29de in OpenThreads::ThreadPrivateActions::StartThread 
(data=0x8216f68)
at 
/home/al/src/OpenSceneGraph-2.6.0/src/OpenThreads/pthreads/PThread.c++:170
#23 0xb7d42192 in start_thread () from /lib/libpthread.so.0
#24 0xb687b02e in clone () from /lib/libc.so.6

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

Re: [osg-users] present3d + compositeViewer

[Dieter Pfeffer]

Hi Robert

thanks for the hints -

- to use it as a single view within a viewer - does this mean that I can
change in the present3d sources from viewer to view and use addView
(present3d_view) in my application?


Dieter


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert
Osfield
Sent: Friday, 22 August, 2008 10:11
To: OpenSceneGraph Users
Subject: Re: [osg-users] present3d + compositeViewer


Hi Dieter,

Combining Present3D with other applications would require refactoring
of Present3D a bit as it isn't built as a shared library at all - just
a straight application.  Present3D is also under the GPL, so if you
wish to make a derivative work, such as what you describe, it will
also have to be GPL'd.

If your app is GPL'd and want to move to integrating with Present3D in
some way, then it might be possible to set Present3D to use a single
view within a Viewer.  Present3D is a bit of tangled mess in the main,
and awaits a rewrite that I'll be doing over the next year, so it
might be possible to move things in a direction that is more
interoperable.

Robert.

On Fri, Aug 22, 2008 at 8:13 AM, Dieter Pfeffer
<[EMAIL PROTECTED]> wrote:
> Hi
>
>
> I would like to combine my application (using osgcompositeviewer with
> multiple views) and present3d, so that I can switch between the two parts
by
> pressing a key.
>
> Any hints what the best way is to combine these ?
>
> Thanks
>
> Dieter
>
>
> Unclassified Mail
>
>
>
> Disclaimer:
>
> If you are not the intended recipient of this email, please notify the
> sender and delete it.
> Any unauthorized copying, disclosure or distribution of this email or its
> attachment(s) is forbidden.
> Thales Nederland BV will not accept liability for any damage caused by
this
> email or its attachment(s).
> Thales Nederland BV is seated in Hengelo and is registered at the Chamber
of
> Commerce under number 06061578.
>
>
> ___
> 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


Disclaimer:

If you are not the intended recipient of this email, please notify the sender 
and delete it. 
Any unauthorized copying, disclosure or distribution of this email or its 
attachment(s) is forbidden. 
Thales Nederland BV will not accept liability for any damage caused by this 
email or its attachment(s). 
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of 
Commerce under number 06061578.

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

Re: [osg-users] Challenge for DatabasePager and cameras with high zoom

[Ralf Stokholm]

Hi Robert

Im using the setLodScale and that works fine solved  the huge problems i had
before.

But based on my current understanding the range based lod scale is less than
optimal for a camera with a large zoom that will only change its
transformation in the world slowly. It will page in an enourmous amount on
textures but will only ever display a small percentage.

This sort of camera must be perfectly suited to a frustrum or screen based
paging algorithm, and my question was if it in your oppinion was feasable in
the current architecture to integrate this as an optional pagingalgorithm.

Based on Ulrichs answer somethin similar might already exist though?

Brgs.

Ralf

2008/8/22 Robert Osfield <[EMAIL PROTECTED]>

> Hi Ralf,
>
> You can use LODScale to scale the LOD ranges to fit case where you
> want to zoom in.  This can be done without modifying the scene graph
> at - just by setting the osg::Camera in question i.e
>
>  mycamera->setLODScale(0.25);
>
> Robert.
>
> On Fri, Aug 22, 2008 at 8:52 AM, Ralf Stokholm <[EMAIL PROTECTED]>
> wrote:
> > Hi List
> >
> > Im working on a flightsimulator and have a wery high resolution
> orthophoto
> > based terrain.
> >
> > One of my cameras is a targetingpod(TGP) camera with a very high zoom
> > factor, to compensate for this I set the cameras lodscale to fit. This
> all
> > works fine but the range based loading of lods could be optimised for the
> > Targeting pod camera by basing it on the frustrum. The TGP will ofthen
> focus
> > at the same spot for a loong time and will rearly have a high rate when
> > changing focus.
> >
> > So I guess my questin is if it is viable to design the a special paging
> > scheme based on not only range but also the direction of the camera.
> >
> > This could then substitute the normal range based paging for special
> > applications like my TGP camera.
> >
> > Brgs.
> >
> > Ralf Stokholm
> > Arenalogic
> >
> > ___
> > 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] Challenge for DatabasePager and cameras with high zoom

[Ralf Stokholm]

Hi Ulrich

Havent tried that, is this a camera setting or will it affect my pilot view
camera as well?

Brgs.

Ralf Stokholm

2008/8/22 Ulrich Hertlein <[EMAIL PROTECTED]>

> Ralf Stokholm wrote:
> > One of my cameras is a targetingpod(TGP) camera with a very high zoom
> > factor, to compensate for this I set the cameras lodscale to fit. This
> > all works fine but the range based loading of lods could be optimised
> > for the Targeting pod camera by basing it on the frustrum. The TGP will
>
> Did you try osg::LOD::setRangeMode(PIXEL_SIZE_ON_SCREEN)?
> /ulrich
> ___
> 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] Challenge for DatabasePager and cameras with high zoom

[Robert Osfield]

Hi Ralf,

You can use LODScale to scale the LOD ranges to fit case where you
want to zoom in.  This can be done without modifying the scene graph
at - just by setting the osg::Camera in question i.e

  mycamera->setLODScale(0.25);

Robert.

On Fri, Aug 22, 2008 at 8:52 AM, Ralf Stokholm <[EMAIL PROTECTED]> wrote:
> Hi List
>
> Im working on a flightsimulator and have a wery high resolution orthophoto
> based terrain.
>
> One of my cameras is a targetingpod(TGP) camera with a very high zoom
> factor, to compensate for this I set the cameras lodscale to fit. This all
> works fine but the range based loading of lods could be optimised for the
> Targeting pod camera by basing it on the frustrum. The TGP will ofthen focus
> at the same spot for a loong time and will rearly have a high rate when
> changing focus.
>
> So I guess my questin is if it is viable to design the a special paging
> scheme based on not only range but also the direction of the camera.
>
> This could then substitute the normal range based paging for special
> applications like my TGP camera.
>
> Brgs.
>
> Ralf Stokholm
> Arenalogic
>
> ___
> 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] Challenge for DatabasePager and cameras with high zoom

[Ulrich Hertlein]

Ralf Stokholm wrote:
> One of my cameras is a targetingpod(TGP) camera with a very high zoom
> factor, to compensate for this I set the cameras lodscale to fit. This
> all works fine but the range based loading of lods could be optimised
> for the Targeting pod camera by basing it on the frustrum. The TGP will

Did you try osg::LOD::setRangeMode(PIXEL_SIZE_ON_SCREEN)?
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] present3d + compositeViewer

[Robert Osfield]

Hi Dieter,

Combining Present3D with other applications would require refactoring
of Present3D a bit as it isn't built as a shared library at all - just
a straight application.  Present3D is also under the GPL, so if you
wish to make a derivative work, such as what you describe, it will
also have to be GPL'd.

If your app is GPL'd and want to move to integrating with Present3D in
some way, then it might be possible to set Present3D to use a single
view within a Viewer.  Present3D is a bit of tangled mess in the main,
and awaits a rewrite that I'll be doing over the next year, so it
might be possible to move things in a direction that is more
interoperable.

Robert.

On Fri, Aug 22, 2008 at 8:13 AM, Dieter Pfeffer
<[EMAIL PROTECTED]> wrote:
> Hi
>
>
> I would like to combine my application (using osgcompositeviewer with
> multiple views) and present3d, so that I can switch between the two parts by
> pressing a key.
>
> Any hints what the best way is to combine these ?
>
> Thanks
>
> Dieter
>
>
> Unclassified Mail
>
>
>
> Disclaimer:
>
> If you are not the intended recipient of this email, please notify the
> sender and delete it.
> Any unauthorized copying, disclosure or distribution of this email or its
> attachment(s) is forbidden.
> Thales Nederland BV will not accept liability for any damage caused by this
> email or its attachment(s).
> Thales Nederland BV is seated in Hengelo and is registered at the Chamber of
> Commerce under number 06061578.
>
>
> ___
> 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] Efficient live camera rendering on textureRectangle using callback?

[Robert Osfield]

Hi Fabian,

It would be cleaner to use a StateAttribute (Texture is subclassed
from StateAttribute) callback rather than a Drawable callback.  The
image dirty is also redundent as the setImage will automatically do
this for you.

Other than this the approach you are taking is OK.  The OSG will
automatically use texture subloading and the PBO that you attach to
the image, so you'll get good performance from this side of things.

Robert.

On Fri, Aug 22, 2008 at 4:52 AM, Fabian Bützow <[EMAIL PROTECTED]> wrote:
> Hello,
> i want to display a live camera stream on a texture rectangle which i pass
> to a bunch of shaders.
> I just want to ask if the way im doing it is the most efficient one?
> The best solution would be to upload the live camera image once to the GPU
> and pass the texture to the several shader..
>
> is this accomplished by the following code?
> (the picture Quads state attribute is linked to the shader)
>
> struct DrawableUpdateCallback : public osg::Drawable::UpdateCallback
> {
>
>   DrawableUpdateCallback(){};
>   DrawableUpdateCallback(CameraBase* camera, TextureRectangle* texture)
>   {
>   this->camera= camera;
>   this->texture= texture;
>   };
>
>   virtual void update(osg::NodeVisitor*, osg::Drawable* drawable)
>   {
>   Image* img= texture->getImage();
>   img->setImage(camera->getWidth(), camera->getHeight(), 1,
> GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE, camera->getRawFrame(),
> Image::NO_DELETE, 1);
>   img->dirty();
>   }
>
>   CameraBase* camera;
>   TextureRectangle* texture;
> };
>
> //in my class:
> ref_ptr camImg= new Image();
> PixelBufferObject* pbo= new PixelBufferObject(camImg.get());
> camImg->setPixelBufferObject(pbo);
>
> ref_ptr texture= new TextureRectangle(camImg.get());
>
> StateSet* state= pictureQuad->getOrCreateStateSet();
> state->setTextureAttributeAndModes(0, texture.get(),
> osg::StateAttribute::ON);
> pictureQuad->setUpdateCallback(new DrawableUpdateCallback(camera,
> texture.get()));
>
> cheers,
> Fabian
>
> ___
> 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] Drawing disappears after being minimized and then restored

[Robert Osfield]

Hi Li,

Does this only happen in your C# app, or does this happen with OSG
examples like osgviewer as well?

Robert.

On Thu, Aug 21, 2008 at 11:19 PM, Ke Li <[EMAIL PROTECTED]> wrote:
> HI all,
>
> When I minimize and then restore a Windows form rendering OSG contents, the
> drawing disappears.
>
> I added a resize event in which I tried various methods and their
> combinations such as OsgViewer.Viewer.frame(),
> SimpleOpenGlControl.Invalidate(), SimpleOpenGlControl.Draw(),
> SimpleOpenGlControl.Refresh(), etc. None of these methods works.
>
> Can anyone give me some enlightenment? Thanks in advance.
>
> BTW, I'm using OSG in C#.
>
> Regards,
>
> Li
>
> 
> Get thousands of games on your PC, your mobile phone, and the web with
> Windows(R). Game with Windows
> ___
> 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] Generate MipMap bug

[Robert Osfield]

HI Mark,

Could you send the whole test example and whole changed file as
copying and pasting from emails leads to various errors.

Cheers,
Robert.

On Thu, Aug 21, 2008 at 8:00 PM, Mark Sciabica <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm in the process of upgrading 2.2 ->2.6 and came across a bug in mipmap
> generation. For NPOT textures when the ResizeNonPowerOfTwoHint is false, I'm
> not getting textures applied correctly.
>
> Sample program demonstrating the bug:
>
> #include 
> #include 
>
> #include 
> #include 
>
> int main(int, char **)
> {
> osg::ref_ptr redTexture = new osg::Texture2D;
> osg::Image* image = new osg::Image;
> static unsigned char bytes[12] = { 0xff, 0x00, 0x00, 0xff, 0xff, 0x00,
> 0x00, 0xff, 0xff, 0x00, 0x00, 0xff };
> image->setImage(3, 1, 1, GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE, &bytes[0],
> osg::Image::NO_DELETE, 1);
> redTexture->setImage(image);
> redTexture->setResizeNonPowerOfTwoHint(false);
> redTexture->setFilter( osg::Texture::MIN_FILTER,
> osg::Texture::LINEAR_MIPMAP_LINEAR );
>
> osg::ref_ptr geode = new osg::Geode();
> osg::ref_ptr sphere1 = new osg::ShapeDrawable(new
> osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),10));
> geode->addDrawable(sphere1.get());
>
> osg::ref_ptr text = new osgText::Text();
> text->setText( L"Text" );
> text->setAxisAlignment(osgText::Text::XZ_PLANE);
>
> osgViewer::Viewer viewer;
> viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);
>
> viewer.setSceneData( geode.get() );
>
> osg::StateSet* stateset = new osg::StateSet();
> stateset->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
> stateset->setTextureAttributeAndModes(0, redTexture.get(),
> osg::StateAttribute::ON);
> geode->setStateSet( stateset );
>
> viewer.run();
>
> return 0;
> }
>
> The problem appears to be that in mipmapAfterTexImage, called by
> applyTexImage2D_load, getTextureObject(contextID) is returning NULL. Moving
> the assignment of the TextureObject to the _textureObjectBuffer before
> applyTexImage2D_load is called fixes the problem. The change to
> Texture2D::apply is shown below, controlled by #define MIPMAP_FIX. Other
> code (in the same function even) is assigning to _textureObjectBuffer
> immediately upon generation of the TextureObject so I figure this should be
> a safe change.
>
> void Texture2D::apply(State& state) const
> {
>
> //state.setReportGLErrors(true);
>
> // get the contextID (user defined ID of 0 upwards) for the
> // current OpenGL context.
> const unsigned int contextID = state.getContextID();
>
> // get the texture object for the current contextID.
> TextureObject* textureObject = getTextureObject(contextID);
>
> if (textureObject != 0)
> {
> textureObject->bind();
>
> if (getTextureParameterDirty(state.getContextID()))
> applyTexParameters(GL_TEXTURE_2D,state);
>
> if (_subloadCallback.valid())
> {
> _subloadCallback->subload(*this,state);
> }
> else if (_image.valid() && getModifiedCount(contextID) !=
> _image->getModifiedCount())
> {
> applyTexImage2D_subload(state,GL_TEXTURE_2D,_image.get(),
> _textureWidth, _textureHeight,
> _internalFormat, _numMipmapLevels);
>
> // update the modified tag to show that it is up to date.
> getModifiedCount(contextID) = _image->getModifiedCount();
>
> }
> else if (_readPBuffer.valid())
> {
> _readPBuffer->bindPBufferToTexture(GL_FRONT);
> }
>
> }
> else if (_subloadCallback.valid())
> {
>
> _textureObjectBuffer[contextID] = textureObject =
> generateTextureObject(contextID,GL_TEXTURE_2D);
>
> textureObject->bind();
>
> applyTexParameters(GL_TEXTURE_2D,state);
>
> _subloadCallback->load(*this,state);
>
>
> textureObject->setAllocated(_numMipmapLevels,_internalFormat,_textureWidth,_textureHeight,1,0);
>
> // in theory the following line is redundent, but in practice
> // have found that the first frame drawn doesn't apply the textures
> // unless a second bind is called?!!
> // perhaps it is the first glBind which is not required...
> //glBindTexture( GL_TEXTURE_2D, handle );
>
> }
> else if (_image.valid() && _image->data())
> {
>
> // keep the image around at least till we go out of scope.
> osg::ref_ptr image = _image;
>
> // compute the internal texture format, this set the _internalFormat
> to an appropriate value.
> computeInternalFormat();
>
> // compute the dimensions of the texture.
> computeRequiredTextureDimensions(state,*image,_textureWidth,
> _textureHeight, _numMipmapLevels);
>
> #define MIPMAP_FIX
> #if defined MIPMAP_FIX
> _textureObjectBuffer[contextID] = textureObject =
> generateTextureObject(
>
> contextID,GL_TEXTURE_2D,_numMi

Re: [osg-users] Performance of osgdem generated databases using --terrain

[Robert Osfield]

Hi Jason,

Good to hear you've tracked down the problem.  W.r.t the crash, I
think we need to start drawing up extension disable lists for
different hardware/drivers profiles, and have some formal system for
it so we can better cope with hardware claming to support
extensions/OGL features but failing.  This is topic for a separate
thread.

Robert,

On Thu, Aug 21, 2008 at 7:58 PM, Jason Beverage <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> I finally figured out the issue I was having.  I was passing in
> --no-mip-mapping to osgdem to compensate for the ATI compressed textures
> issue that existed before their drivers got updated.  Removing the
> --no-mip-mapping argument caused the performance to be great on the
> machine.  I still have to disable VBO on the system to avoid crashing, but
> other than that, things are looking really good using --terrain.
>
> Thanks again for all your help, I don't know how I would get anything done
> without it:)
>
> Jason
>
> On Thu, Aug 21, 2008 at 11:29 AM, Robert Osfield <[EMAIL PROTECTED]>
> wrote:
>>
>> Hi Jason,
>>
>> It would be worth bringing up the viewer stats to look at the update,
>> cull, draw dispatch times.  My expectation is that its draw dispatch
>> is stalling due to the graphics driver, but it would still be worth
>> checking.
>>
>> Another thing you could try would be to rebuild a osg --terrain
>> database, but limiting the image resolution per tile to something like
>> 64x64.  You can do this adding --tile-image-size 64 to the command
>> line.  The default size is 256x256 image size, a 64x64 terrain size.
>>
>> Robert.
>>
>> On Thu, Aug 21, 2008 at 3:57 PM, Jason Beverage <[EMAIL PROTECTED]>
>> wrote:
>> > Hi Robert,
>> >
>> > I noticed that anisotropy setting as well and tried commenting it out
>> > and it
>> > didn't have any affect.  Still large hiccups when downloading textures
>> > using
>> > --terrain.  Looking at the memory usage of my app in the Intel driver's
>> > control panel says that it has a max of 128 mb of memory, which should
>> > be
>> > enough.  Both osgdem options (--terrian and not) keep the "used graphics
>> > memory" at about 126mb.
>> >
>> > Right now, it just seems that the card might not be up to the challenge.
>> > I'm going to try updating the drivers on the machine and see if that
>> > helps
>> > at all.  I think I may just have to revert back to using regular old
>> > osgdem
>> > with no --terrain option for now.
>> >
>> > Thanks!
>> >
>> > Jason
>> >
>> > On Thu, Aug 21, 2008 at 4:25 AM, Robert Osfield
>> > <[EMAIL PROTECTED]>
>> > wrote:
>> >>
>> >> Hi Jason,
>> >>
>> >> It does sounds like you are hitting problems with texture download.
>> >> When using osgTerrain the texturing should be the same as when using
>> >> just osg::Geometry/osg::StateSet based paged databases.  The only
>> >> difference I can spot would be the setting of anisotropic filtering on
>> >> the textures, perhaps the Intel hardware is having problems with this.
>> >>  To test this possibility out, comment out the following line of
>> >> src/osgTerrain/GeometryTechnique.cpp (line 690 in OSG-2.6/svntrunk):
>> >>
>> >>texture2D->setMaxAnisotropy(16.0f);
>> >>
>> >> It'd also be worth checking how texture memory you have available.
>> >>
>> >> Robert.
>> >>
>> >>
>> >> On Wed, Aug 20, 2008 at 10:28 PM, Jason Beverage
>> >> <[EMAIL PROTECTED]> wrote:
>> >> > Hi all,
>> >> >
>> >> > More integrated graphics woes for me today.  I'm working with an
>> >> > Intel
>> >> > 945GM
>> >> > graphics card and trying to load a terrain database generated with
>> >> > --terrain.  Robert, your suggestion of disabling VBO programatically
>> >> > worked
>> >> > great for getting the machine to stop crashing.  For some reason, the
>> >> > machine only crashes if I loaded in some polygonal feature data as
>> >> > well
>> >> > as
>> >> > the terrain database unless I disable VBO.
>> >> >
>> >> > The issue I'm facing now is that the performance of the terrain
>> >> > database
>> >> > is
>> >> > terrible on this machine.  A database generated without the --terrain
>> >> > option
>> >> > works really well, but takes a long time to build.
>> >> >
>> >> > When I move around in my application or in osgviewer, I get huge
>> >> > frame
>> >> > hiccups (up to 2 seconds sometimes) when tiles are being paged in.
>> >> >  The
>> >> > interesting thing is that this only happens if I have texturing
>> >> > turned
>> >> > on.
>> >> > If I hit 't' in osgviewer to disable texturing, tiles come in just
>> >> > fine.
>> >> > I've also noticed that if I turn texturing off for just the high
>> >> > resolution
>> >> > ortho imagery on my database (layer 0) but leave on my lower
>> >> > resolution
>> >> > map
>> >> > (layer 1) that thigns run smoothly.
>> >> >
>> >> > I've tried reducing the sample ratio as Robert has suggested using an
>> >> > osgTerrain::Terrain decorator as well, and this doesn't help the
>> >> > hiccups
>> >> > as
>> >> > they seem to be related to the textures

[osg-users] Challenge for DatabasePager and cameras with high zoom

[Ralf Stokholm]

Hi List

Im working on a flightsimulator and have a wery high resolution orthophoto
based terrain.

One of my cameras is a targetingpod(TGP) camera with a very high zoom
factor, to compensate for this I set the cameras lodscale to fit. This all
works fine but the range based loading of lods could be optimised for the
Targeting pod camera by basing it on the frustrum. The TGP will ofthen focus
at the same spot for a loong time and will rearly have a high rate when
changing focus.

So I guess my questin is if it is viable to design the a special paging
scheme based on not only range but also the direction of the camera.

This could then substitute the normal range based paging for special
applications like my TGP camera.

Brgs.

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

[osg-users] osgText - size is half of font resolution

[sherman wilcox]

Can someone explain why the code below consistently produces text that
is half the height specified? If I render this text, take a screenshot
and measure the height of the text "ABC" in a paint program it will
measure up as approximately 64 pixels tall for a character size /
resolution of 128. I change the 128 to 256, the text will then
measures 128 and so on. Always measures half of what I specify. Should
this not render text that is approximately 128 pixels in height? I
understand that the characters won't be exactly the width/height I
specify, but half? Is this a bug or what?

{
osg::Vec3d pos(osg::DegreesToRadians(someLat),
osg::DegreesToRadians(someLon), 0);
ellipsoidModel->convertLatLongHeightToXYZ(pos[0], pos[1], pos[2],
pos[0], pos[1], pos[2]);
osg::ref_ptr mt = new osg::MatrixTransform();
mt->setMatrix(osg::Matrix::identity());
mt->setMatrix(osg::Matrix::translate(pos));

osg::ref_ptr text = new osgText::Text;
text->setFont("Arial.ttf");
osgText::Text::BackdropType type = osgText::Text::OUTLINE;
text->setBackdropType(type);
text->setColor(osg::Vec4(1,1,1,1));
text->setBackdropColor(osg::Vec4(0,0,0,1));
text->setAlignment(osgText::TextBase::CENTER_CENTER);
text->setAutoRotateToScreen(true);
text->setText("ABC");
text->setCharacterSizeMode( osgText::TextBase::SCREEN_COORDS );
text->setCharacterSize(128);
text->setFontResolution(128, 128);


osg::ref_ptr geode = new osg::Geode();
geode->addDrawable(text.get());

mt->addChild(geode.get());
mt->getOrCreateStateSet()->setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
root->addChild(mt.get());
  }
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] present3d + compositeViewer

[Dieter Pfeffer]

Hi


I would like to combine my application (using osgcompositeviewer with
multiple views) and present3d, so that I can switch between the two parts by
pressing a key.

Any hints what the best way is to combine these ?


Thanks

Dieter


Unclassified Mail



Disclaimer:

If you are not the intended recipient of this email, please notify the sender 
and delete it. 
Any unauthorized copying, disclosure or distribution of this email or its 
attachment(s) is forbidden. 
Thales Nederland BV will not accept liability for any damage caused by this 
email or its attachment(s). 
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of 
Commerce under number 06061578.

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