Re: [osg-users] Rethinking 3rd party dependencies?
I build *everything* from source. I use Python scripts to automate the process too. It's relatively straightforward to setup and is very reliable. Fully automated. I can call one Python script that will check out all source code, compile all OSG and project specific dependencies, compile OSG, compile my application(s) and issue a release. Python is awesome. Could do the same thing with Perl but once I started to use Python I never looked back. Using CMake from the command line is easy as well - very straightforward. I highly recommend compiling all from source. On Fri, Aug 28, 2009 at 5:46 PM, Philip Lowmanphi...@yhbt.com wrote: While poring over thread after thread dealing with build dependencies on Windows I had a weird thought a while back: computers are fast these days, why not just build everything (including 3rd party dependencies) from source? The way I see it, issues on Windows are going to get worse far before they get any better. Issues like: 1. Differing compiler versions (MSVC 7.1/8/9, MinGW 3.4/4.4) 2. The need for Debug libraries with certain compilers 3. The need for 32 and/or 64-bit libraries 4. The occasional need for a complete static build 5. The need/desire for some people to compile with /MT or _SECURE_SCL=0 on MSVC ...are likely not to be going away anytime soon and they can create a confusing ecosystem. Also, security issues library bugfixes tend to get ignored once someone has that prebuilt library sitting off in CM somewhere. So I cmakeified libpng, zlib, and libjpeg (building on some work previously done by Luigi Calori and others) and wrapped them in ZIP files called CMakeports. The three put together take about 5 seconds total to build on my 3 year old core2 duo. They are available at the website below. http://code.google.com/p/cmakeports/ I've integrated and tested* the 3 ports with OSG using osgviewer --image, and things seem to be working fine. I'd like to submit this to osg-submissions assuming there is enough interest in the idea. I'm doubtful this could satisfy 100% of the dependencies people might want to use with the OSG, but I'm optimistic it could cover the major ones (png, jpg, zlib, tiff, freetype seem like no-brainers to me). * I have tested: MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=ON (Debug Release) MinGW 3.4. * I have partially tested: MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=OFF (code compiles but haven't tried building/linking a custom viewer) * I have not tested: MSVC8 MSVC9 64-bit MinGW 4.4.0 -- Philip Lowman ___ 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] node modification from within update callback -
I have a question as to what is allowed and/or what's a good/bad practice with respect to modifying the scenegraph at runtime from within an update callback. We're using one of the newer versions of OSG. 2.9.4 I believe. Our osgViewer is setup for single-threaded operation. Take a look at the attached image. From within F's update callback, we know that we must not add children to or remove children from any of the red nodes, because all of those nodes have active traversals (i.e. invocations of osg::Group::traverse, where the local iterator variable is in danger of being invalidated). But can we modify the blue nodes, since they do not have active traversals? By modify I mean add/remove child nodes of the blue nodes or change properties of the nodes themselves. attachment: example.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Windows users - VS2008 comments
Slightly off-topic for this mailing list but here goes. For the Windows users out there, those of you that are using or know of developers using VS2008 - any comments? Problems, benefits, pros/cons? My project is using VS2005 and has been for a while now but I'm considering switching to VS2008. In my case there's only one reason - the /MP benefit. /MP enables parallel compilation. For multiprocessor or multicore systems it's a real performance increase. I'm not talking about parallel builds of multiple projects but compiling multiple modules in the same project(s) in parallel. On VS2005 /MP is undocumented but works, mostly. It's a tremendous performance boost. However, I've ran into a PDB corruption issue here as of late. Error C2471. Not sure why it's suddenly happening as I've been using /MP for a long while now. I believe Gordon warned me this could happen and it has. I phoned Microsoft about this and they said that /MP is unsupported on VS2005 and I have no recourse but to either not use that feature (no way - too fast) or upgrade to VS2008. So, I may be upgrading. However, there are numerous developers on my project and I want to have a clear understanding of any potential issues before moving forward. I'll be purchasing a copy to test but I'd like to hear from the list. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error on trunk HEAD
On Fri, Feb 6, 2009 at 1:41 PM, Roger James ro...@beardandsandals.co.uk wrote: Robert Osfield wrote: Hi Roger, Sorry to hear it's still broke. I'm not the original author of version additions, just the integrator. Would it be possible for you to tweak the version support now checked in and get it working. Cheers, Robert. Robert, I tried building the svn head version of OSG using the files you attached to this thread with no success. I received RC1000 errors along with macro definition too big - What compiler are you using? I tried with VS2005 SP1. Could you re-send the rc files to me in a direct email zipped? I'll try again. Could be that my browser is mangling the files. Anyone else have a go at this? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgText crash - latest nVidia FX drivers
Hello everyone - I'm experiencing a crash using the latest nVidia
driver when I bring up the stats window and am wondering if anyone
else is experiencing the same problem. My hardware is a Dell
Workstation using a nVidia FX4600 card. I'm convinced the issue is
related to the driver upgrade. I was running version 169.96 (June 2008
release) for the FX series without issue. I immediatly started to
experience the problem when I upgraded to the latest - 178.26 October
15 2008 release. I have tested this issue on three different
development boxes:
* two Dell workstation PCs running Vista x64 Visual Studio 2005 SP1 - FX4600
* one Dell workstation XP 64 - FX4600
In all cases the crash begun as soon as I upgraded the driver. The
crash itself is very reliable. I simply bring up stats and poof -
crash. I've attached the callstack from one of the development PCs.
The last time I had a problem with osgText and a crash like this it
turned out to be a nVidia issue there as well. Had to do with
subloading of zero sized textures, which is valid but the nVidia
driver didn't care for that too much.
The crash seems to occur down in Text::renderOnlyForegroundText(...)
in the glDrawArrays call. I added some debug statements like so:
printf(enter glDrawArrays (%d)..., transformedCoords.size());
glDrawArrays(GL_QUADS,0,transformedCoords.size());
printf(exit\n);
and the output (once stats are enabled) is:
enter glDrawArrays (20)...exit
enter glDrawArrays (48)...exit
(few seconds pass with a repeat of the previous output)
enter glDrawArrays (20)...exit
enter glDrawArrays (48)...crash
Other data points:
* the crash doesn't seem to occur in debug builds
* running osgViewer in single-threaded mode
My questions are:
* anyone else experiencing this?
* can anyone else reproduce?
I'm not sure what else is broken - so far I'm only getting this one
crash. Also not clear as to the exact trigger. The count argument
passed to glDrawArrays always seems to be valid.
Any help would be appreciated.
03b22911()
nvogl32.dll!697d8331()
[Frames below may be incorrect and/or missing, no symbols loaded for
nvogl32.dll]
nvogl32.dll!697d841e()
nvogl32.dll!697dc0fe()
nvogl32.dll!6970f32c()
nvogl32.dll!69843126()
nvogl32.dll!697ddac1()
nvogl32.dll!69830881()
nvogl32.dll!697dce81()
nvogl32.dll!69831041()
nvogl32.dll!6984e460()
osg44-osgText.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1754 + 0x13
bytes C++
osg44-osgText.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1369 C++
osg44-osgText.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1253 C++
osg44-osg.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...})
Line 895 + 0xa bytes C++
osg44-osgUtil.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x04c45858) Line 420 C++
osg44-osgUtil.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x04c45858) Line 469 + 0x29
bytesC++
osg44-osgUtil.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x04c45858) Line 1235 C++
osg44-osgUtil.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x04c45858, bool
doCopyTexture=false) Line 832C++
osg44-osgUtil.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x04c45858) Line 1092
C++
osg44-osgUtil.dll!osgUtil::SceneView::draw() Line 1513 C++
ntdll.dll!7d61cc60()
kernel32.dll!7d4db3dc()
osg44-osg.dll!osg::Timer::tick() Line 61 + 0xa bytes C++
osg44-osgViewer.dll!osgViewer::Renderer::cull_draw() Line 536 C++
osg44-osg.dll!osg::GraphicsContext::runOperations() Line 683 C++
osg44-osgViewer.dll!osgViewer::ViewerBase::renderingTraversals() Line
694 + 0x14 bytes C++
osg44-osgViewer.dll!osgViewer::ViewerBase::frame(double
simulationTime=1.7976931348623157e+308) Line 592 + 0x9 bytes C++
testviewer.exe!main(int argc=2, char * * argv=0x009e5ee8) Line 248
C++
testviewer.exe!__tmainCRTStartup() Line 597 + 0x17 bytes C
kernel32.dll!7d4e7d2a()
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AutoTransform and SMALL_FEATURE_CULLING
I've attached a small demo app that illustrates an issue I've
discovered (known?) with AutoTransform nodes and small feature
culling. Briefly summarized, if I add a custom AutoTransform node (see
code for trivial example) to the scenegraph just under the root node
everything seems fine, with or without small feature culling enabled.
However, if I add this AutoTransform node as a member of a osg::Group
and then add the group to the scenegraph then this node's accept
function no longer is called after the first traversal if small
feature culling is enabled. However, if I disable small feature
culling all is well.
Is this a bug or am I doing something wrong?
#include iostream
#include direct.h
#include osgDB/ReadFile
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/Geode
#include osg/Geometry
#include osgGA/TrackballManipulator
#include osg/ShapeDrawable
#include osg/AutoTransform
#include osg/MatrixTransform
static osg::Vec3d cairoPos;
#pragma message( )
#pragma message( Please define your own earth model )
#pragma message( )
static std::string earthFileName = http://somewhere.org/earth.ive;;
class CustomeAutoTransform : public osg::AutoTransform
{
public:
CustomeAutoTransform()
{
_maxScale = 2500 * 1000;
}
void CustomeAutoTransform::accept(osg::NodeVisitor nv)
{
if(nv.getVisitorType() == osg::NodeVisitor::NODE_VISITOR)
{
osg::AutoTransform::accept(nv);
return;
};
osg::Vec3d pos = getPosition();
osg::Vec3 eye_cp = nv.getEyePoint() - pos;
pos.normalize();
eye_cp.normalize();
double deviation = (eye_cp * pos);
//crude scaling
double scaleCoefficient = osg::minimum(1.0, osg::maximum(0.0, deviation));
const double epsilon = 0.0001;
setMaximumScale(__max(_maxScale * scaleCoefficient, epsilon));
osg::AutoTransform::accept(nv);
}
double _maxScale;
};
int main(int argc, char** argv)
{
//calculate Cairo, Egypt position in ECEF
{
osg::EllipsoidModel em;
osg::Vec3d pos(osg::DegreesToRadians(30.08), osg::DegreesToRadians(31.25),
0);
em.convertLatLongHeightToXYZ(pos[0], pos[1], pos[2], pos[0], pos[1],
pos[2]);
cairoPos = pos;
}
osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
viewer.addEventHandler( new osgViewer::WindowSizeHandler );
viewer.addEventHandler( new osgViewer::StatsHandler );
viewer.addEventHandler(new osgViewer::RecordCameraPathHandler);
viewer.setReleaseContextAtEndOfFrameHint(false);
//comment this line out to demonstrate the bug
//viewer.getCamera()-setCullingMode(viewer.getCamera()-getCullingMode()
~osg::CullSettings::SMALL_FEATURE_CULLING);
osg::ref_ptrosg::Group root = new osg::Group;
{
osg::ref_ptrosg::Node earth = osgDB::readNodeFile(earthFileName);
earth-getOrCreateStateSet()-setMode(GL_LIGHTING,
osg::StateAttribute::OFF);
root-addChild(earth.get());
}
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
{
osg::ref_ptrosg::ShapeDrawable sphere = new osg::ShapeDrawable( new
osg::Sphere( cairoPos, 5000 ) ) ;
sphere-setColor(osg::Vec4(1., 0., 0., 1.));
osg::ref_ptrosg::Geode geode = new osg::Geode();
geode-addDrawable(sphere.get());
root-addChild(geode.get());
}
//simple autotransform
{
osg::ref_ptrosgText::Text text = new osgText::Text;
text-setFont(Arial.ttf);
text-setCharacterSizeMode(
osgText::TextBase::OBJECT_COORDS_WITH_MAXIMUM_SCREEN_SIZE_CAPPED_BY_FONT_HEIGHT
);
text-setCharacterSize(128);
text-setFontResolution(128, 128);
text-setColor(osg::Vec4(1,1,1,1));
text-setText(Cairo);
osgText::Text::BackdropType type = osgText::Text::OUTLINE;
text-setBackdropType(type);
text-setBackdropColor(osg::Vec4(0,0,0,1));
text-setAlignment(osgText::TextBase::CENTER_CENTER);
text-setAxisAlignment(osgText::TextBase::XY_PLANE);
text-setPosition(osg::Vec3(0,75,0));
osg::ref_ptrosg::Geode geode = new osg::Geode();
geode-addDrawable(text.get());
osg::ref_ptrCustomeAutoTransform at = new CustomeAutoTransform();
at-setAutoScaleToScreen(true);
at-setAutoRotateMode(osg::AutoTransform::ROTATE_TO_SCREEN);
at-addChild(geode.get());
at-setPosition(cairoPos);
at-getOrCreateStateSet()-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
at-getOrCreateStateSet()-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
osg::ref_ptrosg::Group group = new osg::Group();
const bool demonstrateBug = true;
if(demonstrateBug)
{
//the AutoTransform node will fail if and only if
//small feature culling is enabled
group-addChild(at.get());
root-addChild(group.get());
}
else
{
//if we add the AutoTransform directly to the root node
//then it makes no difference if small feature culling is
//enabled or not, everything still works
root-addChild(at.get());
}
}
[osg-users] osgText - size is half of font resolution
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_ptrosg::MatrixTransform mt = new osg::MatrixTransform();
mt-setMatrix(osg::Matrix::identity());
mt-setMatrix(osg::Matrix::translate(pos));
osg::ref_ptrosgText::Text 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_ptrosg::Geode 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
Re: [osg-users] glGetString returning NULL
Thanks for the reply - I am running osgViewer in single threaded mode
- still returns NULL. The drawable trick works as expected, but I
don't understand why this doesn't work in the main render loop when in
single threaded mode. I *think* this worked in 2.4. Almost positive.
Anyway, here's a simple example. glGetString fails in the loop but
succeeds in the drawable. Note the usage of single threaded mode. I'm
not so concerned about having to move this code to a drawable, but
perhaps this is indicative of a larger issue?
#include iostream
#include osgDB/ReadFile
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
class CglGetString : public osg::Drawable
{
public:
CglGetString()
{
setUseDisplayList(false);
};
virtual bool isSameKindAs(const Object* obj) const { return
dynamic_castconst CglGetString*(obj)!=NULL; }
virtual Object* cloneType() const { return new CglGetString(); }
virtual Object* clone(const osg::CopyOp copyop) const { return new
CglGetString(); }
virtual void drawImplementation(osg::RenderInfo renderInfo) const
{
char* extensions = (char*)glGetString(GL_EXTENSIONS);
}
protected:
};
int main(int argc, char** argv)
{
osg::ArgumentParser arguments(argc,argv);
osgViewer::Viewer viewer(arguments);
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
osg::Referenced::setThreadSafeReferenceCounting(true);
viewer.addEventHandler(new osgViewer::WindowSizeHandler);
viewer.addEventHandler(new osgViewer::StatsHandler);
viewer.setCameraManipulator(new osgGA::TrackballManipulator);
// load the data
osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFiles(arguments);
if (!loadedModel)
{
std::cout arguments.getApplicationName() : No data loaded
std::endl;
return 1;
}
osg::ref_ptrosg::Group group = new osg::Group();
group-addChild(loadedModel.get());
if(1)
{
osg::Geode *geode = new osg::Geode();
geode-addDrawable(new CglGetString());
group-addChild(geode);
}
viewer.setSceneData( group.get() );
viewer.realize();
while(!viewer.done())
{
viewer.frame();
char* extensions = (char*)glGetString(GL_EXTENSIONS);
}
return 0;
}
On Thu, Jul 31, 2008 at 4:34 AM, Gordon Tomlinson
[EMAIL PROTECTED] wrote:
This will in most case always return NULL in OSG 2.x and above
You Have to do OpenGL calls where in the Processes/Thread that has the
OpenGL context which in OSG is the Draw Processes, so you have to do
anything with OpenGL in Draw Call callbacks
You cannot do OpenGL calls in the App Process/Thread as your doing below (
UNLESS you have OSG in Single Thread MODE )
__
Gordon Tomlinson
[EMAIL PROTECTED]
IM: [EMAIL PROTECTED]
www.vis-sim.com www.gordontomlinson.com
__
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of sherman
wilcox
Sent: Wednesday, July 30, 2008 8:29 PM
To: OpenSceneGraph Users
Subject: [osg-users] glGetString returning NULL
Running latest version of OSG in SVN, calling glGetString(...) from
main render loop (single threaded osgViewer). Like this:
while(viewer.done() == false)
{
viewer.frame();
char* extensions = (char*)glGetString(GL_EXTENSIONS);
}
extensions is always NULL. Am I doing something wrong here? Could
someone else test this?
___
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] glGetString returning NULL
Running latest version of OSG in SVN, calling glGetString(...) from
main render loop (single threaded osgViewer). Like this:
while(viewer.done() == false)
{
viewer.frame();
char* extensions = (char*)glGetString(GL_EXTENSIONS);
}
extensions is always NULL. Am I doing something wrong here? Could
someone else test this?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] render to texture - alpha blending
Hi guys - I'm using render to texture in one of my apps and I'm experiencing alpha blending issues. Here's what I have: simple RTT (render to texture) with two quads. Each quad has as a background an opaque black background (24-bit BMP). In front of that is a small (doesn't cover the entire background) 32-bit TGA with varying transparency. Here's the issue: on the portion of the quad that is covered by 32-bit TGA I can see right through. It appears as though OpenGL is doing what it's suppose to do - blending not only the RGB but also the alpha. For my blending function I'm using (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) - So, when this 32-bit TGA is blended against the opaque black background it's blending the alpha components as well which results in an overall decreased alpha value. Hence, that opaque black background is now semi-transparent. What I did to (hopefully) solve this is to premultiply the incoming fragments via a shader attached to each incoming node that is drawn into the RTT and use (GL_ONE, GL_ONE_MINUS_SRC_ALPHA) as my blending function for that node. Seems to solve it. At least now everything is blending the way I'd expect. The opaque parts are opaque and the semi-transparent are blending as expected against the opaque background, etc. My question is this: what other method might I employ to deal with these alpha blending issues? How do you guys recommend handling this? What's the recommend route to take? attachment: Untitled.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with new version OSG 2.6.0
Can you make a small and simple prototype that *reliably* reproduces the problem? You have a better chance of getting help that way. On Sun, Jul 27, 2008 at 2:50 AM, GMD GammerMaxyandex.ru [EMAIL PROTECTED] wrote: Some offers of OSG 2.6.0( problems with new version). Let's wait with OSG 2.6.0 release. I asked this because I found a problem with osgUtil::LineSegmentIntersector function. In OSG v 2.5.5 version of OSG function viewer-computeIntersections(x,y, hlist) works very strange - when cursor movements over object is short it(cursor) falls throught the object and function returns name of object which is behind current(object over which cursor is). In earlyer(less 2.5.2) versions of OSG this error has never appeared. How can I solve this problem in this(2.5.5) version of OSG? It is necessary to solve the problem until OSG 2.6.0 release. Thanks in advance. Best regards, Max. ___ 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] Seeking OSG texture mapping application
http://www.remograph.com/ On Thu, Jun 26, 2008 at 9:53 AM, Judie [EMAIL PROTECTED] wrote: Hi, Can 3D Studio Max import osg, apply texture and export it back to osg? If not then is there another modeling software that can? I am having problems generating texture coordinates for a model representing a machined work peice. If there is an algorithm for apply textures that would also be appreciated. 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] positioning a node - XYZ with offset in screen space
On Sun, Jun 22, 2008 at 12:37 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, You could try using an osg::AutoTransform that is positioned at your XYZ and set up to scale to screen coords and rotate to screen, then have the subraph by offset up the Y axis (effectively in screen space) to give you the offset you want. The last bit - have the subraph by offset up the Y axis (effectively in screen space) to give you the offset you want. - what exactly do you suggest? What I require is an approximate offset in pixels. For example, if I want a node (lets use text as an example) to be at position XYZ in world coordinates and then offset by 45 pixels along the Y axis - what do you suggest? I have one method working that I'm not pleased with performance wise. The crucial bit is getting close to the number of pixels specified to be offset by. Cheers, Robert. On Sun, Jun 22, 2008 at 1:28 AM, sherman wilcox [EMAIL PROTECTED] wrote: I have nodes (models, text, etc.) that are positioned in XYZ coordinates that I wish to offset in screen space. My question is what's the best/fastest way to do this. An example follows. I have a piece of text that acts as a label for a point on a sphere. In this case that sphere is an osg ellipsoid model generated by virtual planet builder. I position the text at a given lat/lon/altitude which I translate to a XYZ world coordinate. However, I wish to offset the text in screen space by X,Y pixels. Imagine you want to label a point of interest on this globe but you want the label itself to be offset (updated every frame) by X pixels in the x-dimension and Y pixels in the y-dimension. I have one osg::MatrixTransform node acting as the parent of each text object. I have about 100 of these labels objects. I need to update the offset of the text every few frames. Doesn't have to be every frame, I can accept lazy updates - but it is something that needs to occur rather frequently. What's the best way to accomplish this? I have something working but it's rather slow with 50 or more objects. I'm using IntersectVisitor in the algorithm which is killing performance. Any suggestions? ___ 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] positioning a node - XYZ with offset in screen space
I have nodes (models, text, etc.) that are positioned in XYZ coordinates that I wish to offset in screen space. My question is what's the best/fastest way to do this. An example follows. I have a piece of text that acts as a label for a point on a sphere. In this case that sphere is an osg ellipsoid model generated by virtual planet builder. I position the text at a given lat/lon/altitude which I translate to a XYZ world coordinate. However, I wish to offset the text in screen space by X,Y pixels. Imagine you want to label a point of interest on this globe but you want the label itself to be offset (updated every frame) by X pixels in the x-dimension and Y pixels in the y-dimension. I have one osg::MatrixTransform node acting as the parent of each text object. I have about 100 of these labels objects. I need to update the offset of the text every few frames. Doesn't have to be every frame, I can accept lazy updates - but it is something that needs to occur rather frequently. What's the best way to accomplish this? I have something working but it's rather slow with 50 or more objects. I'm using IntersectVisitor in the algorithm which is killing performance. Any suggestions? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] NPOT textures - comments
In the olden days when I'd have a texture that wasn't power of 2 I'd use a POT (power of two) texture, update the parts of the texture that I was interested in and fix-up the texture coordinates accordingly. Nowadays I'm more inclined to use NPOT (non-power of two) or texture rectangles. Problem is every time I try to use NPOT textures I get nailed performance wise. If I use texture rectangles no problem - performance is as you'd expect...it just works. The thing I don't like about texture rectangles primarily are the lack of NDC (non-dimensional coordinates). Maybe I'm old fashioned, but I like my coordinates to be in the range of 0 - 1. Oh, and the lack of mipmaps are rather disappointing as well, but a small price to pay when you really only need a 2049 x 1025 texture. So, what's your experience? Anyone out there sucessfully using NPOT (not texture rectangles) in the OSG? What's your video hardware/OS/driver? I'm using some very good nVidia cards (FX4600) with the latest drivers on Vista - but NPOT performance is terrible. Perhaps I'm doing something boneheaded. NPOT - GL_ARB_texture_non_power_of_two: http://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt Texture rectangles - GL_ARB_texture_rectangle: http://www.opengl.org/registry/specs/ARB/texture_rectangle.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New versions of OSG and configuring CMake
To add to what Luigi saidhere's my command line: cmake -DWIN32_USE_MP=ON -DGDAL_INCLUDE_DIR:PATH=%rootdir%\3rdparty\gdal\include -DGDAL_LIBRARY:PATH=%rootdir%\3rdparty\gdal\lib\gdal_i.lib -DCURL_LIBRARY_DEBUG:PATH=%rootdir%\3rdparty\curl\lib\debug\curllib.lib -DCURL_LIBRARY:PATH=%rootdir%\3rdparty\curl\lib\release\curllib.lib -DCURL_INCLUDE_DIR:PATH=%rootdir%\3rdparty\curl\include -DCMAKE_INSTALL_PREFIX:PATH=%rootdir%\3rdparty\osg\common\OpenSceneGraph . I use this in my master build script to build everything. I simply fire off a single script and go grab some lunch! To use Visual Studio from the command line after cmake is done I use: devenv OpenSceneGraph.sln /%1 Debug /project ALL_BUILD /out %logfile% devenv OpenSceneGraph.sln /%1 Debug /project INSTALL /out %logfile% devenv OpenSceneGraph.sln /%1 RelWithDebInfo /project ALL_BUILD /out %logfile% devenv OpenSceneGraph.sln /%1 RelWithDebInfo /project INSTALL /out %logfile% where %1 is build or rebuild On Thu, Jun 12, 2008 at 7:19 PM, Luigi Calori [EMAIL PROTECTED] wrote: I presume you are workng on Windows and change build folder.If you just update from svn you should not be forced to configure again. Anyway, if you want to keep your previous cmake setup, just keep the CmakeCache.txt file. Otherwise,you can force your defaul configuration by adding -Dvar=value tou your cmake command line. I usually store my default setup in a cmake command line then run cmakesetup to eventually change options afterwards Hope it helps Brian wrote: Hi, I must be doing something wrong when using CMakeSetup. Every time I download a new release of OSG, I have to go through the steps of reconfiguring CMake to point to all the directories for the various extras (GDAL, FLTK, etc.) I've tried setting up environment variables with names like FLTK_LIBRARY or FLTK_INCLUDE_DIR in the hopes that CMake will read those and use them to help make my life easier, but it's all in vain. Is there an easy way to automatically configure CMake? Thanks, Brian ___ 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] How to stop osgViewer using two monitors/windows
Visual Studio 2005 ... Project Properties = Configuration Properties = Debugging = Environment ... add OSG_SCREEN=0 Another way is to add _putenv(OSG_SCREEN=0) in your code On Mon, Apr 21, 2008 at 4:49 AM, Roger James [EMAIL PROTECTED] wrote: How do I stop osgViewer from using both my monitors (windows vista with desktop spread over both), or two separate windows. I thought it might be something to do with a camera config file, but the newer non Producer version does not report this option as available even though it is still documented on the wiki. I apologise if I have missed something obvious. Roger ___ 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] faster builds on multiproc systems - VisualStudio2005 2008
Gordon - I do wonder if you disabled parallel project builds and enabled /MP if the problems you experience would vanish. But, how much would that hurt performance? That is, which is the bigger performance boon - /MP or parallel builds. On Thu, Apr 10, 2008 at 10:20 AM, Gordon Tomlinson [EMAIL PROTECTED] wrote: Hi Mike Yes repeating can make the build work in most cases but not all We have some very large solutions and lots of dependencies, so there's certainly room to stretch this, but we have seen issues on small solutions as well As said for use it could be a combination of our environment with Network, and ClearCase which can be an issue as most of the source will live in ClearCase VOBS etc.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: Thursday, April 10, 2008 11:13 AM To: OpenSceneGraph Users Subject: Re: [osg-users] faster builds on multiproc systems - VisualStudio2005 2008 Hi Gordon, So can good binaries be made by just repeating the build until successful completion, to bypass race issues? Or is there the more nefarious failure of bad binaries being created by an otherwise successful-looking process? -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Gordon Tomlinson Sent: Thursday, April 10, 2008 10:04 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] faster builds on multiproc systems - Visual Studio2005 2008 Hi Sherman For us he problems with the linker often not syncing correctly with the compiler Then issue when adding manifests once linked would often have timing issues and the process could fail ( not always ) And when doing post build steps such as singing assemblies etc the timing again would often be off and the process could fail ( not always ) This could be just our environment and ClearCase and maybe network issues etc. Seems for others things work fine -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sherman wilcox Sent: Wednesday, April 09, 2008 4:34 PM To: OpenSceneGraph Users Subject: [osg-users] faster builds on multiproc systems - Visual Studio 2005 2008 This is sort of off-topic but I'm sure interesting to the community none the less. I was on the phone with a fellow OSG developer earlier today complaining how slow the builds are on Windows and how I have this quad core sitting here not being fully utilized by my compiler. He touted how his Mac could perform parallel builds and how much faster it was. So off I went to see if there's a way to do this with my compiler, Visual Studio 2005. Lo and behold I found an undocumented way to enable multi-processor builds using VS 2005. I couldn't believe it. It was like someone gave me a gift. http://blog.280z28.org/archives/2007/10/17/ http://lahsiv.net/blog/?p=40 So, could some of you guys try this as well and let me know how you get on? ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] faster builds on multiproc systems - Visual Studio 2005 2008
This is sort of off-topic but I'm sure interesting to the community none the less. I was on the phone with a fellow OSG developer earlier today complaining how slow the builds are on Windows and how I have this quad core sitting here not being fully utilized by my compiler. He touted how his Mac could perform parallel builds and how much faster it was. So off I went to see if there's a way to do this with my compiler, Visual Studio 2005. Lo and behold I found an undocumented way to enable multi-processor builds using VS 2005. I couldn't believe it. It was like someone gave me a gift. http://blog.280z28.org/archives/2007/10/17/ http://lahsiv.net/blog/?p=40 So, could some of you guys try this as well and let me know how you get on? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] faster builds on multiproc systems - Visual Studio 2005 2008
Gordon, the issues you encountered - were they obvious issues as in linker errors or were they more subtle like random crashes and the like? On Wed, Apr 9, 2008 at 4:04 PM, Gordon Tomlinson [EMAIL PROTECTED] wrote: Hi We avoid using this feature at work on our projects as we have found the VS linker and compiler do not always see eye to eye when using parallel builds and also find a lot of manifest issue, but that's our experience Now back in the good old days on good SGI 32 processor monster parallel build work like a charm and screamed along .. Regards Gordon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sherman wilcox Sent: Wednesday, April 09, 2008 4:34 PM To: OpenSceneGraph Users Subject: [osg-users] faster builds on multiproc systems - Visual Studio 2005 2008 This is sort of off-topic but I'm sure interesting to the community none the less. I was on the phone with a fellow OSG developer earlier today complaining how slow the builds are on Windows and how I have this quad core sitting here not being fully utilized by my compiler. He touted how his Mac could perform parallel builds and how much faster it was. So off I went to see if there's a way to do this with my compiler, Visual Studio 2005. Lo and behold I found an undocumented way to enable multi-processor builds using VS 2005. I couldn't believe it. It was like someone gave me a gift. http://blog.280z28.org/archives/2007/10/17/ http://lahsiv.net/blog/?p=40 So, could some of you guys try this as well and let me know how you get on? ___ 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] 64bit CMake on Vista64 question
Anyone had any success getting CMake to construct x64 OSG build targets in one of the 64bit flavors of Windows? I'm using Vista64 but I'd imagine XP64 is the same. We have a developer investigating this but I thought I'd ping the list to see if anyone else is doing this. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 64bit CMake on Vista64 question
Just to be clear, did cmake construct the x64 build targets or was that something you did by hand after cmake built the solution and vcproj files? I'm using Visual Studio 2005 Pro SP1 On Fri, Apr 4, 2008 at 3:36 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi, We did it several months ago. We keep the project untouched from then. As far as I remember one needs to clear cmake cache and select VC 200x 64-bit from target build dialog. You may need a Standard/Pro version of Visual Studio. We were unable to build it with Express (although we tried hard). With Standard version it was just a matter of waitnig for the compiler and linker to build projects. 64 bit third party libs could be a pain in the neck, though. We had to rebuild few of them and each had different build philososphy (makefile vs solution/ naming conventions/ static vs shared libs/ macro defintions / dependencies etc) so the best is to look for prebuild libs on the net. I hope they will be easier to find today. Cheers, Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of sherman wilcox Sent: Friday, April 04, 2008 10:11 PM To: OpenSceneGraph Users Subject: [osg-users] 64bit CMake on Vista64 question Anyone had any success getting CMake to construct x64 OSG build targets in one of the 64bit flavors of Windows? I'm using Vista64 but I'd imagine XP64 is the same. We have a developer investigating this but I thought I'd ping the list to see if anyone else is doing this. ___ 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] osgNETDemo
I couldn't tell from reading your post - but if you're not compiling the OSG yourself (IE...running a binary distribution), grab one of the developer snapshots and compile that. On Mon, Mar 17, 2008 at 4:39 PM, [EMAIL PROTECTED] wrote: Hello All, I have been working with Phil Tessier on some work using OSG in a managed code environment. We tried using OsgDotNet, but we had some problems with that, and others on this list recommended we use C++/CLI directly to wrap just what we need form OSG directly, and there is an example provided on the language wrappers page (osgCppCLIDemo.rar). I was able to get that compiled, but it crashes with a __RTDynamicCast exception deep within osgViewer.dll. The last thing I can see in the call stack is in the InitOSG() function, in the line that uses osg::GraphicsContext::createGraphicsContext(traits.get()); The call stack looks funny to me, because it calls osg.dll, and then osgViewer.dll. I am using OSG version 2.0 (because it is compatible with OsgDotNet) and Visual Studio 2005. Perhaps I need to upgrade OSG? Thanks, -- Rick ___ 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] shader leakage (WAS traversal question w/latest developerrelease-blacknodes)
Thanks Mike - glad to hear the problem manifested for you as well. If I can be of any additional assistance let me know. On Mon, Feb 25, 2008 at 12:03 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi Sherman, Finally had a chance to look at your repro, and I agree it is an OSG bug. It's a consequence of the unique handling of glProgram state within OpenGL; I thought we'd fixed this before, but you seem to have uncovered a different failure vector. In the repro example you gave me, since I didn't have a osgdem earth model, I just used a earth-sized sphere, note the line below for the easy workaround: //osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFile(c:/brokaw/system/earth/earth.ive); osg::Geode* geode( new osg::Geode() ); geode-addDrawable(new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0,0,0), 6.371e6f ))); geode-getOrCreateStateSet()-setAttribute( new osg::Program ); // --- workaround for shader leakage osg::ref_ptrosg::Node loadedModel = geode; That empty osg::Program above on the scene root explicitly forces the scene to fixed-function. Without it, the problem seems that fixed-function default isn't enforced til a cull traversal, so there's this hole that the scene can accidently be affected by a leaking osg::Program binding. I'll be submitting a real fix rsn. cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of sherman wilcox Sent: Thursday, February 14, 2008 8:48 PM To: OpenSceneGraph Users Subject: Re: [osg-users] traversal question w/latest developerrelease- blacknodes mew - Didn't realize there was a potential shader connection till a tad later. Anyway, I spent more time on this yesterday and managed to build a sample app that is much smaller and less complicated than the app I originally found the problem in. There's a bit of propriety code in this sample app - nothing I wouldn't mind sharing with you if you want to take a peek. The thing that bugs me is why is this shader effecting other osg nodes. Now, there could most certainly be a bug in my code somewhere - but I'm using OSG code - I don't *think* I'm going outside of OSG and doing messing with OpenGL states. So, if I'm using all OSG code then I would think that even if I've got a bad shader, or doing something I shouldn't be - then that error should be confined to that node and its children and should NOT travel to its siblings. ___ 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] another one - osg and C#
Glenn - ever run into any issues where you found portions of OSG not to work with C++/CLI? I believe the OSG/C# folks run into this a lot. Any odd difficulties or does everything just work? Follow-up question - have you written any OSG/C++/CLI WPF apps? Winforms? How well does all this stuff play together? On Feb 16, 2008 10:16 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Sherman, I'll vouch for it ... I've written dozens of apps using C++/CLI and OSG and it works great. It is very convenient to be able to mix managed and unmanaged code virtually at will (there are a few restrictions) as the interop is handled transparently by the CLR. Plus with .NET 2.0, it's simple to write an OSG .NET Control in a C++/CLI assembly, and then use it in all your C# UI code. -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 On Feb 16, 2008 10:10 PM, sherman wilcox [EMAIL PROTECTED] wrote: Ok - so it sounds as if using C# with OSG is bad idea. Sounds possible - just painful. On the plus side I hear (on occasion) good things said about C++/CLI. Can anyone else comment on their experience using OSG and C++/CLI? On Feb 14, 2008 10:48 AM, hesicong2006 [EMAIL PROTECTED] wrote: Hi, You should try OSG.NET project, but the project does not contains every feature OSG could provide. A much better solution will be use of C++/CLI, this language can create mix native C++ and managed code. The main C# UI design benefit is also contained in C++/CLI. I have use C++/CLI to integrate OSG and .NET, very well, you should try it. But the plain will be the much lower compile speed due to lots of inline code of OSG. sherman wilcox wrote: I've read a few posts and I'm a bit fuzzy on the subject. I have an OSG app wrapped up in a C++ library. Now I need a UI. I can attach this and drive this libarary from a console app, MFC GUI, or even the standard Windows API, etc. - All in C++. However, I'm considering using C#. I've heard lots of good things about C# from a UI development perspective. From an OSG/C# point of view - there seems to be lots of pain. I'm not a C# developer - it's all Greek to me - so what I'm imagining may not be practical in reality hence this post. Is it possible to link in my OSG app wrapped up in a C++ blanket and use my own API from with a C# GUI? Is it painful? What would I lose by going this route? Is possible that at some point I won't be able to take advantage of some latest OSG feature due to some unforeseen incapability? My current UIs (I'm thinking of one MFC UI in particular) don't really interact with the OSG - that's all handled by my own C++ API. I'm just not sure how well all this would glue together using C#. Can some of the veterans comment? ___ 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] traversal question w/latest developer release-blacknodes
mew - Didn't realize there was a potential shader connection till a tad later. Anyway, I spent more time on this yesterday and managed to build a sample app that is much smaller and less complicated than the app I originally found the problem in. There's a bit of propriety code in this sample app - nothing I wouldn't mind sharing with you if you want to take a peek. The thing that bugs me is why is this shader effecting other osg nodes. Now, there could most certainly be a bug in my code somewhere - but I'm using OSG code - I don't *think* I'm going outside of OSG and doing messing with OpenGL states. So, if I'm using all OSG code then I would think that even if I've got a bad shader, or doing something I shouldn't be - then that error should be confined to that node and its children and should NOT travel to its siblings. You can email me privately if you want and I'll be happy to share the code with you. On Thu, Feb 14, 2008 at 5:04 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi, Usually try to keep an eye out for shader questions, but this title did not attract my attention. I'm leaving the title unmodified so you'll see this response, but if there's still an open question, pls start a new appropriately-titled thread with the current state of your investigation. Way way back, there was an issue of OSG shader state leakage. It's been fixed a long time (years?), 'course that doesn't preclude another failure mode. Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, February 13, 2008 10:07 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] traversal question w/latest developer release- blacknodes (Hm, shaders. Maybe someone with more experience with shaders in OSG can read and post an opinion?) Hi Sherman -- Interesting issue. OpenGL is a state machine, and if you're just using raw OpenGL, then you could enable blending, for example, never change blending state again, and blending would be enabled for all subsequent geometry. OSG adds a new level of functionality on top of that. As you traverse a scene graph, state changes are pushed and popped hierarchically, which is what most apps expect. If blending is off in a parent Node but on in the first child, blending is restored to a disabled state before processing the other children. Not all state: Color, as I mentioned previously, is not pushed and popped. So, if you change the color in a Drawable, and then a subsequent sibling (or even a distant cousin) Geometry is missing its color array, the previous color persists (due to OpenGL's state machine nature). I'm not sure why OSG intentionally doesn't push/pop color, but it simply doesn't, and if you always specify color for Drawables that require specific colors, this is not an issue. When it comes to shaders, though, I'm not sure how they behave. If a Node binds a Program, does OSG unbind it before processing sibling Nodes? This is a question better posed to someone like Mike W. or Bob K... =Paul I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is
Re: [osg-users] traversal question w/latest developer release -blacknodes
Is strange. I'm using all OSG code. Is possible I've found some odd OSG bug - but I think is more likely that I'm doing something that's not intended and am experiencing a side effect. I'm going to spend a bit of time and see if I can simplify this problem down to a trivial example. On Feb 13, 2008 10:07 AM, Paul Martz [EMAIL PROTECTED] wrote: (Hm, shaders. Maybe someone with more experience with shaders in OSG can read and post an opinion?) Hi Sherman -- Interesting issue. OpenGL is a state machine, and if you're just using raw OpenGL, then you could enable blending, for example, never change blending state again, and blending would be enabled for all subsequent geometry. OSG adds a new level of functionality on top of that. As you traverse a scene graph, state changes are pushed and popped hierarchically, which is what most apps expect. If blending is off in a parent Node but on in the first child, blending is restored to a disabled state before processing the other children. Not all state: Color, as I mentioned previously, is not pushed and popped. So, if you change the color in a Drawable, and then a subsequent sibling (or even a distant cousin) Geometry is missing its color array, the previous color persists (due to OpenGL's state machine nature). I'm not sure why OSG intentionally doesn't push/pop color, but it simply doesn't, and if you always specify color for Drawables that require specific colors, this is not an issue. When it comes to shaders, though, I'm not sure how they behave. If a Node binds a Program, does OSG unbind it before processing sibling Nodes? This is a question better posed to someone like Mike W. or Bob K... =Paul I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. I suspect either one of (at least) two things: 1) I'm abusing OSG some manner and the code is responding in kind. In other words, I'm doing something I shouldn't be and I'm getting undefined behavior. OR 2) There is some sort of state leakage (of my shader) issue between sibling nodes. If this is leakage - is it a bug or not? What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? I thought this was new - but went back and tried older versions of OSG and the problem persists. I have a fix (allow one cull traversal on my custom node)...but it seeems kludgy. I'm either doing something terribly wrong OR I've found some bug. It's probably the former. It does strike me as add that performing a single cull traversal addresses the issue. Seems as though some state isn't be set properly unless this cull traversal is allowed to pass through. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org
[osg-users] another one - osg and C#
I've read a few posts and I'm a bit fuzzy on the subject. I have an OSG app wrapped up in a C++ library. Now I need a UI. I can attach this and drive this libarary from a console app, MFC GUI, or even the standard Windows API, etc. - All in C++. However, I'm considering using C#. I've heard lots of good things about C# from a UI development perspective. From an OSG/C# point of view - there seems to be lots of pain. I'm not a C# developer - it's all Greek to me - so what I'm imagining may not be practical in reality hence this post. Is it possible to link in my OSG app wrapped up in a C++ blanket and use my own API from with a C# GUI? Is it painful? What would I lose by going this route? Is possible that at some point I won't be able to take advantage of some latest OSG feature due to some unforeseen incapability? My current UIs (I'm thinking of one MFC UI in particular) don't really interact with the OSG - that's all handled by my own C++ API. I'm just not sure how well all this would glue together using C#. Can some of the veterans comment? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] traversal question w/latest developer release - blacknodes
Paul - thanks for the suggestions. I've found an older code tree of mine from November 07 and everything seemed to work there. I'm investigating. On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? -Paul - anyone else is experiencing this? - or perhaps I'm abusing things in such way that is ill-advised? Comments? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] traversal question w/latest developer release - black nodes
I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? - anyone else is experiencing this? - or perhaps I'm abusing things in such way that is ill-advised? Comments? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] traversal question w/latest developer release - blacknodes
I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. I suspect either one of (at least) two things: 1) I'm abusing OSG some manner and the code is responding in kind. In other words, I'm doing something I shouldn't be and I'm getting undefined behavior. OR 2) There is some sort of state leakage (of my shader) issue between sibling nodes. If this is leakage - is it a bug or not? What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? I thought this was new - but went back and tried older versions of OSG and the problem persists. I have a fix (allow one cull traversal on my custom node)...but it seeems kludgy. I'm either doing something terribly wrong OR I've found some bug. It's probably the former. It does strike me as add that performing a single cull traversal addresses the issue. Seems as though some state isn't be set properly unless this cull traversal is allowed to pass through. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Heap and Out Of Memory error on XP
To toss my 2cents in you could also investigate the /LARGEADDRESSAWARE switch. In addition, I'd recommend looking into a new heap manager. I've had success with SmartHeap by MicroQuill. Do you have to use MFC? MFC will fragment the heap a bit by loading DLLs all over the place. To illustrate the impact of this behavior build a simple consolse app, a basic MFC dialog app, and a no-frills Win32 SDK based app. In each app attempt allocate 2GB of RAM in various chunk sizes. The results may surprise you. My point is if you can get away from using MFC that might help. MFC is a good method to develop user interfaces on Win32 systems (or QT) but MFC does have its drawbacks. I'd strongly suggest you get an eval for SmartHeap (assuming you have budget) and see if that helps - it's trivial to plug in to existing code. On Jan 30, 2008 9:47 AM, Stephen Northcott [EMAIL PROTECTED] wrote: Thanks to both of you.. Yeah (not a dig here as OS X has it's own memory issues) but I am a bit spoiled by the memory management that is offered by OS X for lazy programmers like me in this case!! The amazing thing is on Parallels on the Mac I have had none of this in Visual Studio, but when migrating to a 'real' PC it all started falling apart! Hrmph! I have done a lot of reading this afternoon, and what you both say makes sense. I have found that by allowing the heap a little time to tidy itself up, and sticking a few small allocates and de-allocates in strategic places I have alleviated the problem somewhat. Not a great fix, but it gets me through for now. I have started looking at some ways to chunk down the 500MB block and will have to hope I can page between sections at appropriate times.. Who ever said programming should be easy anyway and memory should be a nice empty block of free space!! Thanks for the input. Kind regards Stephen. On Jan 30, 2008, at 10:29 PM, Gordon Tomlinson wrote: HI Firstly under 32 bit Windows your process does not have access to 3gb memory, a process on windows can only access just over 1.8gb of memory for the heap. Secondly windows is very very dump when it comes to loading programs and DLL's it will load them all over the place in memory, what this means is that in many case trying to allocate 500mb of contigous memory will be in many cases not possible, At my company for a core product we have some sneeky tricks that we are forced to do inorder to ensure we get large contigous pieces of memory, this only work well if you do not have lots of other aplications running or if you have been running for a while Irix had a similar issue in that Irix would load system DLL's righ in the middle of the memory stack, for Performer the trick was to run all the .so through a clear scipt the forced them to load in a low or high part of the memory, you can do this for windows Dll's but its not as simple as it was on Irix H... Where to start? 1. Windows will hog quite a bit of memory to begin with, so you don't really have 3G available. My 3G machine shows 2.5G available after windows loads. 2. Even if you did, the per process limit for 32 bit is 2G. 3. I think windows even restricts that a bit further. 4. MFC is a bloated beast that will take some of that 2G. Anyway, you would be better off posting some code that did the following. 1. allocate a huge amount of space (500MB) 2. Attach it as vertex data to some OSG nodes. 3. Point out where it blows up. (if that's all it takes). You could modify osgviewer to do this. Otherwise, there are lots of different things that could be wrong. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Northcott Sent: Wednesday, January 30, 2008 4:35 AM To: OpenSceneGraph Users Subject: [osg-users] Heap and Out Of Memory error on XP I am getting Out Of Memory errors from OSG. I know why, kind of, but am surprised this is not handled more elegantly. Can anyone shed some light for me.. I have a very large data-set which requires being in memory at all times. Unprocessed it is around 750MB++. It is typically 500MB after I have loaded it and formatted it for efficiency of storage. I load it in chunks (rather than load it as a 750MB++ raw data file) and then process it to the 'working' 500MB chunk. But at the end of all this I still need to have the resultant 500MB structure sitting in memory. On a PC with 3GB of RAM I am able to do this, however, when I then try to initialize a scene graph based on about 1 or 2% of this data I get an Out Of Memory error from OSG. This is running in MFC on XP. I could, I suppose, write a wrapper class to access this 500MB chunk of data, and put it into smaller 50MB chunks, for example. But I don't see why I should have to when I have a 3GB machine for this task! I am also
Re: [osg-users] Mathematical foundations
In addition to the excellent advice from everyone else I would highly recommend taking a linear algebra class (and any needed pre-requisites) at your local university. On Jan 6, 2008 6:27 AM, Renan Mendes [EMAIL PROTECTED] wrote: Hi everyone, Since I'm new on the whole computer graphics world, I don't have the mathematical foundations needed to fully comprehend the geometric transformations involved in a scene graph and used by OSG in its methods. I'd like to ask anybody who knows about a good website that deals with this kind of subject. Thanks in advance. Renan M Z Mendes ___ 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] Changing SceneData
Here's a link with a decent intro to osg reference pointers: http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers.html On Dec 28, 2007 10:40 AM, Gordon Tomlinson [EMAIL PROTECTED] wrote: Assuming your not already using reference pointers OSG uses reference counting to aid in memory clean up and all OSG nodes are derived from reference counted objects When you add a node to a parent or the scene its reference count increments when it is removed it is decremented, in your case its reference count hits zero so the node and its attached state and children will all be delete ( assuming your not using ref_ptr's ) see the OSG web site or my FAQ's at vis-sim.com for more info So basically you need to use reference pointer objects and not raw pointers to you OSG nodes e.g ref_ptrosg::Group m_root1 = new osgGroup; ref_ptrosg::Group m_root2 = new osgGroup; m_viewer.setSceneData( m_root1.get() ); __ Gordon Tomlinson Email : [EMAIL PROTECTED] Website : www.vis-sim.com www.gordontomlinson.com __ Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival -Master Tambo Tetsura From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of maruti borker Sent: 28 December 2007 13:51 To: OpenSceneGraph Users Subject: [osg-users] Changing SceneData I have a single viewer , and two different root nodes ... When the program loads i initialize the viewer with the first root . Then on a keypress i change my viewer scene data to second root . And i also have a kepress by which the viewer should go back to earlier root ( i,e first root ) . The first keypress is working .. but the second key press is giving a segmentation fault ...On debuggin i found that the viewer.setSceneData(root1) is giving a seg fault. Any idea why this is happening ?? Cant we change hte sceneData in between ? -- -- Maruti Borker IIIT Hyderabad Website:- http://students.iiit.ac.in/~maruti Blog:- http://marutiborker.wordpress.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building a GUI in osg
Lots of links to UI toolkits, is very dated but might lead to something useful: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html On Dec 27, 2007 6:17 AM, maruti borker [EMAIL PROTECTED] wrote: Is there any external library which supports this ??? On Dec 21, 2007 4:02 PM, Sashidhar Guntury [EMAIL PROTECTED] wrote: Hi I am building an application which needs to have a small menu where people can click around, and do all that sort of stuff. Is there any library or class which gives this functionality by default. I have started making a few generic buttons using HUD and giving them the capability of handling picks, but then if there is some library for the aforementioned reason, it would save a lot of time. thanks! Bye Sashidhar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -- Maruti Borker IIIT Hyderabad Website:- http://students.iiit.ac.in/~maruti Blog:- http://marutiborker.wordpress.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ViewerEventHandlers.cpp doesn't compile, can't include values.h
In the Inventor plugin there is: #ifdef __linux #include values.h #endif #ifdef __APPLE__ #include float.h #endif So, perhaps float.h in lieu of limits.h? On Dec 24, 2007 6:01 PM, Rafa Gaitan [EMAIL PROTECTED] wrote: Hi Paul and Mike, The problem is the same in MacOSX, values.h is not found, however, the documentation says that limits.h provides the same functionality, so maybe an adecuate ifdef could be the solution. Rafa. On Dec 24, 2007 10:38 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi, I just ran into this too. In case gcc needs it, the comments in value.h say to instead use limits.h and/or float.h -- mew On Dec 24, 2007 3:16 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- I ran into this with current SVN today. ViewerEventHandlers.cpp does a #include values.h but the VS8 compiler complains that it can't find the header file. I deleted this line in my local copy and the file appeared to compile fine. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ 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 -- Rafael Gaitán Linares Instituto de Automática e Informática Industrial http://www.ai2.upv.es Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia ___ 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] GIS vector suggest
http://osggis.org/ On Dec 23, 2007 1:16 AM, MingWei [EMAIL PROTECTED] wrote: Hi EveyOne! My Application needs to render vector like line or polygon with different color (transparent effect) on the surface the terrain. And the users can select to load or unload the vector layer. I have no idea about this. hope your suggest. Thanks. ___ 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] Running OSG on Vista
Sounds like a driver issue. I have been running various flavors of OSG
on Vista x64 for months on different hardware configurations.
On Dec 19, 2007 6:24 AM, Franclin Foping [EMAIL PROTECTED] wrote:
Hello Everybody,
I am trying to run a simple code on Vista and it looks like I have got a
black screen as output.
I have installed OSG 2 on Vista and Linux. OSG works perfectly on Linux.
However I have got some issues on Vista.
As mentioned early, I cannot run some codes, even osglogo doesn't work.
For instance, the following code compiles but doesn't run on Vista:
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osg/ShapeDrawable
using namespace std;
int main()
{
osgViewer::Viewer viewer;
osg::ref_ptrosg::Group root (new osg::Group);
osg::ref_ptrosg::Node fishnode
(osgDB::readNodeFile(Oyanirami0.3ds));
root-addChild(fishnode.get());
bool result = osgDB::writeNodeFile(*(root.get()),simple.osg);
viewer.setSceneData( root.get() );
//Stats Event Handler s key
viewer.addEventHandler(new osgViewer::StatsHandler);
//Windows size handler
viewer.addEventHandler(new osgViewer::WindowSizeHandler);
return (viewer.run());
}
I am waiting for your reply.
Franclin.
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
___
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] ANN: Reference Manual for v2.2 now available
However, I like the idea of a community-written OSG Gems book, and I don't want to underestimate the community's willingness to contribute. So, I'll give this some thought, look into other Gems-style books' business models, and see if I can find a way to make this work (time-wise, as an editor). Initial thought: rather than here's how to use some feature in OSG type of articles, it might be better to have here's how I did this really cool thing using OSG or here's how my company is using OSG, if you know what I mean. I think this is more in line with other Gems books I've read. A gems book is a great idea. I second the here's how I did this really cool thing using OSG route. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Geometry shader
I have a recent need for this as well. Anyone done this yet? On Oct 26, 2007 3:05 AM, Ralph Kern [EMAIL PROTECTED] wrote: Hi, does anybody already got some of the new geometry shader extension EXT_geometry_shader4 working with OSG? see tutorial at http://appsrv.cse.cuhk.edu.hk/~ymxie/Geometry_Shader/ Seems it should be possible to implement it straight forward in the OSG core. Regards Ralph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] readFontFile possible bug
Robert, I'm not so sure the multi-threading issue is resolved. I wasn't getting simple GPU stalls. The database pager would stop working after several of these stalls. By stop working I don't mean interruptions with resumption. That database pager would not come back at all. Also, the log messages to screen was strange. Some were garbled messages and mentioned that it could no longer find plugins, etc. The inability to find plugins could explain the database pager, but the question then becomes why does running background threads dump plugins and trash log output? On Dec 14, 2007 5:25 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, I have tried out your modified osgtext example with the --mt 5 etc option along with a 8GB whole earth database and find the frame rate stalling, especially when zooming in to new high res regions. Running with on screen stats on suggests that its the GPU that is stalling things, with a single frame taking a very long time, then once its freed up the app runs freely once more with millisceond GPU times. I've put timing code into the UpdateTextOperation and neither the load nor update methods take very long most of the time, and there isn't a big hit here when the stall happen so it doesn't seem to be directly associated with the extra threads running. I haven't been able to establish the exact cause of stalls, but it looks to be an issue with the newly introduced subgraphs forcing compile of texture objects/display lists in such a way that the OpenGL driver/GPU is stalling. The texture sizes associated with osgText shouldn't be very large so the bandwidth and memory footprint shouldn't be a bottleneck, clearly something is happening down in the OpenGL fifo/GPU that is causing major problems and stalling things. One thing it doesn't look like is a threading issue, my guess running the UpdateTextOperation synchronously i.e. from the main loop would probably see the same big hits on the GPU, although perhaps doing it synchronously would regulate the amount of new data added in a subgraph per frame. Getting to the bottom of this issue will take digging down into draw dispatch, and probably adding things like GPU stats collection to the osgText::Text/Font rendering methods as well as osg::Texture texture subloading. I would suggest opening a different thread into investigations of these GPU stall issues, as it would seem so far the multi-threaded font crashes/bugs look resolved and this thread can be closed. Robert, On Dec 14, 2007 12:58 AM, sherman wilcox [EMAIL PROTECTED] wrote: OK, grabbed the latest copy of OSG out of SVN (latest as of about 2PM today) and ran my test app again. With the latest OSG the app doesn't crash, but there are still major issues. So, the multi-threading issue is still there. The database pager simply stops working, I get all manner of errors in the console window, etc. I've attached the test app. Should compile in linux, windows, etc. If you run this app, you will need a paged database to really stress things. I have one (about 148MB compressed) that I can provide if anyone is interested. Just email me and I'll provide a link to download. Oh, and be sure to pass the app an argument of --mt 5, where 5 is the number of test threads to launch, can be any reasonable number. On Dec 12, 2007 10:21 PM, sherman wilcox [EMAIL PROTECTED] wrote: I spent a bit of time this evening digging up the the code that reproduces the crash. I'll update to the SVN snapshot of OSG and give it a try. I was able to reproduce the crash on 2.2.0. On Dec 12, 2007 4:22 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, On Dec 11, 2007 11:31 PM, sherman wilcox [EMAIL PROTECTED] wrote: I can still reliably reproduce the multithreaded osgText / databasepager crash issue :) Could you explain how your recreate the crash, and the circumstances of the crash. It may be exactly the same problem as Serge has, but also just as easily could be another weakness that needs solving. Aaa you gotta love debugging multi-threaded apps remotely :-) 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 ___ 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] readFontFile possible bug
I performed my tests using the SVN trunk of OSG (as about 2 hours ago) Here are some of the log messages: Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X1_Y0_subtile.ive. Error r e.a.d.i.n ga nfoitlhee:r DeartraoIrn pcuotdSet rmeanesa mt:h:arte atdhUeI nfto(n)t: fiFlaei lceodu ltdo nroet add unsign ed in t. .v..a lbuee . opened, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X0_Y1_subtile.ive. WarnEinrgr:o rC oruelda dniontg ffiinlde :p lDuagtianI ntpou trSetarde aomb:j:ercetasd UfIrnotm( )f:i lFea ilCe:d\ tWo irnedaodw su\Fonnstisg\nteidme s.itnttf v.alue . Warning: Could not find plugin to read objects from file c:/system/earth/earth_L3_X2_Y2_subtile.ive. Error reading file: D.a.t.a.I napnuottShterre aemr:r:orre acdoUdIen tm(e)a:n sF atihlaetd tthoe rfeoandt ufnislieg n ceodu lidn tn ovtadlue. be opened, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X0_Y1_subtile.ive. WarniEnrgr:o rC orueladd innogt ffiilned: pDlautgaiInnp uttoS trreeaadm :o:brjeeacdtUsI nftr(o)m: fFialiel edC :t\oW rienaddo wusn\sFiognntesd\ tiinmte sv.atltufe.. Warning: Could not find plugin to read objects from file c:/system/earth/earth_L3_X2_Y2_subtile.ive. E.r.r..o ra nroetahdeirn ge rfriolre :co dDea tmaeIannpsu ttShtarte atmh:e: rfeoandtU Ifnitl(e) : cFoauillde dn ottod r ead unsigned i n.t. .v.a lbuee .o pened, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X1_Y0_subtile.ive. WarniEnrgr:o rC oreualddi nngo tf iflien:d DpaltuagIinn ptutoS rteraeda mo:b:jreecatdsU Ifnrto(m) :f iFlaei leCd: \tWo i nrdeowasd\ Fuonnstisg\nteidm eisn.tt tvfal.ue. Warning: Could not find plugin to read objects from file c:/system/earth/earth_L2_X0_Y1_subtile.ive. Error readin g. .f.i.l ea:n oDtahtearI neprurtoSrt rceoadme: :meraenasd UtIhnatt( )t:h eF afiolnetd ftiol er ecaodu lud n sniotgdn ed int v a.l.u.e. be o.pen ed, read or simply that it is broken..d Warning: Could not find plugin to read objects from file c:/system/earth/earth_L3_X2_Y2_subtile.ive. WarnEirnrg:o rC orueladd innogt ffiilned: p lDuagtianI ntpou trSead torbejaemc:t:sr efarodmU Ifnitl(e) : FCa:i\lWeidn dtowos \rFeoadn tusn\stiigmneesd. titnft .va lue. On Dec 14, 2007 2:13 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, On Dec 14, 2007 3:15 PM, sherman wilcox [EMAIL PROTECTED] wrote: Robert, I'm not so sure the multi-threading issue is resolved. I wasn't getting simple GPU stalls. The database pager would stop working after several of these stalls. By stop working I don't mean interruptions with resumption. That database pager would not come back at all. Also, the log messages to screen was strange. Some were garbled messages and mentioned that it could no longer find plugins, etc. The inability to find plugins could explain the database pager, but the question then becomes why does running background threads dump plugins and trash log output? OK. This does sounds like more than just a plain stall, all I was able to do was recreate the stall. Could you capture the error messages and post them? As for a thread dumping plugins etc. This suggest to be that the Registry is getting corrupted for some reason, but who knows, this is all pretty new in style of problem than we've seen before. 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] readFontFile possible bug
OK, grabbed the latest copy of OSG out of SVN (latest as of about 2PM
today) and ran my test app again. With the latest OSG the app doesn't
crash, but there are still major issues. So, the multi-threading issue
is still there. The database pager simply stops working, I get all
manner of errors in the console window, etc.
I've attached the test app. Should compile in linux, windows, etc.
If you run this app, you will need a paged database to really stress
things. I have one (about 148MB compressed) that I can provide if
anyone is interested. Just email me and I'll provide a link to
download. Oh, and be sure to pass the app an argument of --mt 5, where
5 is the number of test threads to launch, can be any reasonable
number.
On Dec 12, 2007 10:21 PM, sherman wilcox [EMAIL PROTECTED] wrote:
I spent a bit of time this evening digging up the the code that
reproduces the crash. I'll update to the SVN snapshot of OSG and give
it a try. I was able to reproduce the crash on 2.2.0.
On Dec 12, 2007 4:22 AM, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Sherman,
On Dec 11, 2007 11:31 PM, sherman wilcox [EMAIL PROTECTED] wrote:
I can still reliably reproduce the multithreaded osgText /
databasepager crash issue :)
Could you explain how your recreate the crash, and the circumstances
of the crash. It may be exactly the same problem as Serge has, but
also just as easily could be another weakness that needs solving.
Aaa you gotta love debugging multi-threaded apps remotely :-)
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
/* OpenSceneGraph example, osgtext.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osgUtil/Optimizer
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgDB/Registry
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/Geode
#include osg/Camera
#include osg/ShapeDrawable
#include osg/Sequence
#include osg/PolygonMode
#include osg/io_utils
#include osgText/Font
#include osgText/Text
osg::Group* createHUDText()
{
osg::Group* rootNode = new osg::Group;
osgText::Font* font = osgText::readFontFile(fonts/arial.ttf);
osg::Geode* geode = new osg::Geode;
rootNode-addChild(geode);
float windowHeight = 1024.0f;
float windowWidth = 1280.0f;
float margin = 50.0f;
//
// Examples of how to set up different text layout
//
osg::Vec4 layoutColor(1.0f,1.0f,0.0f,1.0f);
float layoutCharacterSize = 20.0f;
{
osgText::Text* text = new osgText::Text;
text-setFont(font);
text-setColor(layoutColor);
text-setCharacterSize(layoutCharacterSize);
text-setPosition(osg::Vec3(margin,windowHeight-margin,0.0f));
// the default layout is left to right, typically used in languages
// originating from europe such as English, French, German, Spanish etc..
text-setLayout(osgText::Text::LEFT_TO_RIGHT);
text-setText(text-setLayout(osgText::Text::LEFT_TO_RIGHT););
geode-addDrawable(text);
}
{
osgText::Text* text = new osgText::Text;
text-setFont(font);
text-setColor(layoutColor);
text-setCharacterSize(layoutCharacterSize);
text-setPosition(osg::Vec3(windowWidth-margin,windowHeight-margin,0.0f));
// right to left layouts would be used for hebrew or arabic fonts.
text-setLayout(osgText::Text::RIGHT_TO_LEFT);
text-setAlignment(osgText::Text::RIGHT_BASE_LINE);
text-setText(text-setLayout(osgText::Text::RIGHT_TO_LEFT););
geode-addDrawable(text);
}
{
osgText::Text* text = new osgText::Text;
text-setFont(font);
text-setColor(layoutColor);
text-setPosition(osg::Vec3(margin,windowHeight-margin,0.0f));
text-setCharacterSize(layoutCharacterSize);
// vertical font layout would be used for asian fonts.
text-setLayout(osgText::Text::VERTICAL);
text-setText(text-setLayout(osgText
Re: [osg-users] readFontFile possible bug
I spent a bit of time this evening digging up the the code that reproduces the crash. I'll update to the SVN snapshot of OSG and give it a try. I was able to reproduce the crash on 2.2.0. On Dec 12, 2007 4:22 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, On Dec 11, 2007 11:31 PM, sherman wilcox [EMAIL PROTECTED] wrote: I can still reliably reproduce the multithreaded osgText / databasepager crash issue :) Could you explain how your recreate the crash, and the circumstances of the crash. It may be exactly the same problem as Serge has, but also just as easily could be another weakness that needs solving. Aaa you gotta love debugging multi-threaded apps remotely :-) 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] readFontFile possible bug
I can still reliably reproduce the multithreaded osgText / databasepager crash issue :) On Dec 11, 2007 1:59 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Serge, How reliably can you recreate the crash? Does it happen with osgviewer or other OSG examples? Could you explain whats happening in your app before the crash. If we can work out the conditions that the crash happens we'll have a much better chance of isolation. It could be as your describe an object be deleted just when another thread is about to take a ref to it, I would have thought this would be a pretty rare condition though. Robert. On Dec 11, 2007 3:55 PM, Serge Lages [EMAIL PROTECTED] wrote: I have another theory about the crash, let's say that : osg::Object* object = osgDB::readObjectFile(foundFile, userOptions ? userOptions : localOptions.get()); read the object from the cache, and between this moment and the one where the font object is set to a ref_ptr into setFont, the cache is cleared (into another thread). With this scenario the pointer points to a deleted object or is there anything to prevent it ? In my case this scenario is possible as I load my IVE with the databasepager and that I remove the expired objects into the main thread. -- 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows/OSG question
I haev some of the same questions. My understanding is that to realize benefit that all libraries should be re-compiled. The part I'm fuzzy on is the should be. What happens when you mix and match SCL libraries with non-SCL is unknown to me. You should certainly see a performance boost in debug builds by disabling iterator debugging. The secure iterators, I've heard disabling those will yield increases as well in Release builds of 10-20%. I haven't tried this myself. Please do report back to the list with results if you do this. Thanks On Nov 28, 2007 10:53 AM, [EMAIL PROTECTED] wrote: Hi... we are (still) trying to find ways to improve performance on windows. Does anyone compile their windows builds with the following options? /D_SECURE_SCL=0 /D_HAS_ITERATOR_DEBUGGING=0 If so, does it produce good results? Is it necessary for *ALL* libraries to be built with these options, or is it okay to compile some with and some without? E.g., could I build OSG with these options turned on, but leave other libraries (such as boost) compiled as-is? Thanks. ___ 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] screen capture with multiple cameras
Ok. Thanks for the reply. Followup question: Is there an automagic way to determine what this last camera is or do I need to keep track of that myself? Is it reasonable to attach a camera to the scenegraph set as the last camera just for capture purposes? I wouldn't think there would be much overhead incurred, but never hurts to ask. On Nov 23, 2007 12:46 AM, Berg, Michael [EMAIL PROTECTED] wrote: sherman wilcox wrote: I want to capture my OSG screen and dump it to a jpeg or png file. My understanding is to attach a callback to the main osgViewer camera and perform a osg::Image::readPixels(...) from within the callback. That works in the simple case. But, if I have a basic HUD that is itself a camera alongside other nodes in the scenegraph, then I never see the HUD in my osg::Image::readPixels call. That would make sense since my callback is operating on the main camera and not my child node camerabut leaves the question of how do I perform a complete screen capture on a graph with multiple cameras? Is there an example I missed? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Sherman, I recently ran into the same problem on this list. Robert Osfield responded with some comments on how it might one-day be done more cleanly, but that Until these methods are added, you'll need to make do with a post draw callback on the last camera to be drawn. If your HUD is the last camera drawn, set the post draw callback on your HUD camera, and it will be a complete screen capture. - Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] screen capture with multiple cameras
I want to capture my OSG screen and dump it to a jpeg or png file. My understanding is to attach a callback to the main osgViewer camera and perform a osg::Image::readPixels(...) from within the callback. That works in the simple case. But, if I have a basic HUD that is itself a camera alongside other nodes in the scenegraph, then I never see the HUD in my osg::Image::readPixels call. That would make sense since my callback is operating on the main camera and not my child node camerabut leaves the question of how do I perform a complete screen capture on a graph with multiple cameras? Is there an example I missed? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] crash in GL2Extensions::glDeleteShader
Good call Robert. makeCurrent() was/is failing.
So, what is the proper way to shut everything down? I can side-step
the issue by calling _viewer-getView(0)-setSceneData(0); ...this
has the side effect of not calling GraphicsContext::close(...), so I
avoid the crash...but this is obviously wrong and I'm sure this will
bite me later.
I'm using osgViewer::CompositeViewer in a single threaded
configuration. I looked at the osgViewer MFC example but didn't see
anything useful. Looked at the other osgViewer examples as well and
really didn't see anything that showed me how to properly shutdown
osgViewer.
So, how do I gracefully exit?
On Nov 20, 2007 2:45 AM, Robert Osfield [EMAIL PROTECTED] wrote:
HI Sherman David,
This makes it sounds very much like a threading issue associated with
making the graphics context current. In the GraphicsContext::close()
method there is a section that does the flushing of deleted OpenGL
objects, the code is:
if (callCloseImplementation _state.valid() isRealized())
{
osg::notify(osg::INFO)Closing still viable window
sharedContextExists
_state-getContextID()=_state-getContextID()std::endl;
makeCurrent();
osg::notify(osg::INFO)Doing Flushstd::endl;
// flush all the OpenGL object buffer for this context.
double availableTime = 100.0f;
double currentTime =
_state-getFrameStamp()?_state-getFrameStamp()-getReferenceTime():0.0;
osg::FrameBufferObject::flushDeletedFrameBufferObjects(_state-getContextID(),currentTime,availableTime);
osg::RenderBuffer::flushDeletedRenderBuffers(_state-getContextID(),currentTime,availableTime);
osg::Texture::flushAllDeletedTextureObjects(_state-getContextID());
osg::Drawable::flushAllDeletedDisplayLists(_state-getContextID());
osg::Drawable::flushDeletedVertexBufferObjects(_state-getContextID(),currentTime,availableTime);
osg::VertexProgram::flushDeletedVertexProgramObjects(_state-getContextID(),currentTime,availableTime);
osg::FragmentProgram::flushDeletedFragmentProgramObjects(_state-getContextID(),currentTime,availableTime);
osg::Program::flushDeletedGlPrograms(_state-getContextID(),currentTime,availableTime);
osg::Shader::flushDeletedGlShaders(_state-getContextID(),currentTime,availableTime);
osg::notify(osg::INFO)Done Flush availableTimestd::endl;
_state-reset();
releaseContext();
}
Now there is a makeCurrent() in there, but perhaps this is failing.
It'd be interesting to focus on the success/failure of this call.
makeCurrent() should return true on success so this would be something
one could test against.
Robert.
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] Window titlebar icon/text
The most straightforward way is platform specific. Look for SetWindowText and WM_SETICON On Nov 16, 2007 6:49 AM, Robert Balfour [EMAIL PROTECTED] wrote: I'm using the osgViewer class on WinXP. Is there a straightforward way to set the application icon and text on the window titlebar? (or do I get the native window handle and do it platform-specific) Thanks. Bob. -- Robert E. Balfour, Ph.D. Exec. V.P. CTO, BALFOUR Technologies LLC 960 South Broadway, Suite 108, Hicksville NY 11801 Phone: (516)513-0030 Fax: (516)513-0027 email: [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thread politeness
On Nov 16, 2007 8:33 AM, Robert Osfield [EMAIL PROTECTED] wrote: The other thing you can do is try out an OS that can do multi-threading properly. Robert. Yeah, like Windows Vista 64! *jumps for cover* kidding...kidding ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG + sky
Here's another link: http://www.magrathea-engine.org/ On 10/31/07, Robert Osfield [EMAIL PROTECTED] wrote: On 10/31/07, Rahul Jain [EMAIL PROTECTED] wrote: Hi all, I want to integrate enviroment in my application, for example clouds and sky. As far as my knowledge is concerned this is not possible in OSG currenly. Can someone tell me the alternatives. You could try Sundogs Silverlinning. ___ 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] modelling question - 3DS Max = OSG
Hey guys, I've got a few questions related to getting 3DS models to display properly in OSG. I'm not a modeller myself, I write software, but I'm working with a modeller trying to get some of their work into my app. The objective I'm trying to reach is to import an animated, textured model from 3dsmax to OSG with either a Morph Modifier or a Skin Wrap Modifier. A good example would be a flag waving in the wind. Ideally, I would like to have good control of textures as well - including transparency, specularity, and texture maps...along with the ability to animate these features. I've used osgExport with some of the models with limited success. Seems that the skin or morph modifier isn't exported. Is what I'm trying to accomplish feasible or reasonable within the confines of OSG? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance Windows (Visual Studio) compared to MAC OS/X
Ummmthis looks suspicious. Same hardware yet different times on the Windows platform? What about checked iterators under 2005? Are you disabling those? Checked iterators: http://msdn2.microsoft.com/en-us/library/aa985965(VS.80).aspx With checked iterators, you'd need to disable them for the OSG libs as well. Do you have access to a Intel compiler for Windows? I'd encourage you to try that as well. On 10/15/07, Adrian Egli [EMAIL PROTECTED] wrote: Hi all, same code, allways default project settings, release, same CPU/RAM/... windows native and os/x native dual boot what you think about this results are equal, but computing time MAC OS/X XCode Ray Trace Time = 2.97638s Rays = 787307 (264K Rays/s) Nodes Checks= 24939199 Bounding Checks= 49512447 Triangles Checks= 16703960 Visual Studio 2003 Ray Trace Time = 3.77131s Rays= 786152 (208K/s) Nodes Checks= 24806690 Bounding Checks = 49252143 Triangles Checks= 16609007 Visual Studio 2005 Ray Trace Time = 4.62109s Rays= 786152 (170K/s) Nodes Checks= 24806705 Bounding Checks = 49252212 Triangles Checks= 16608961 -- Adrian Egli ___ 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] osgText - shimmer...wavy
I'm using osgText with the character size mode of OBJECT_COORDS_WITH_MAXIMUM_SCREEN_SIZE_CAPPED_BY_FONT_HEIGHT. The text is position on an ellipsoid model with ECEF coordinates. When the text is smaller than the maximum font height I notice that the text is somewhat wavy when I zoom in and out. Sort of shimmers. Once the text has realized it's maximum size the effect is much less noticable, sometimes completely gone. Could this be a floating point precision issue down in the bowels of osgText? BTW, I'm using an osg::MatrixTransform node to position the text. Any ideas? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgText precision issue
I'm having a bit of trouble with mangled text if I zoom in to close. This text is on an osgDem generated ellispoid. In the attached screenshots, the text appears correctly in text2.jpg. However, in text3.jpg you'll see the problem. This only occurs if I zoom in really close to the text. If I back off the camera a bit, the text reverts back to the correct state. My questions are: 1) What's causing this? 2) How best to address the issue? attachment: text3.jpgattachment: text2.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgText precision issue
Yeah, that sounds like it will do the trick. I'll have to re-work some code, but that should address the issue. On 9/8/07, Jason Beverage [EMAIL PROTECTED] wrote: Hi Sherman, The issue you're seeing is probably a precision issue since OpenGL works in floats. I've seen a similar effect with Text objects in my applications. One way to reduce this precision problem is to to not position your text using the setPosition function but to position it by using a MatrixTransform as the parent of the geode containing your text. This will allow OSG to accumulate the transformation and camera matrices in doubles and only convert to float the very last moment to increase precision. It is the same technique that osgdem uses when managing its tiles. Hope this help! Jason On 9/8/07, sherman wilcox [EMAIL PROTECTED] wrote: I'm having a bit of trouble with mangled text if I zoom in to close. This text is on an osgDem generated ellispoid. In the attached screenshots, the text appears correctly in text2.jpg. However, in text3.jpg you'll see the problem. This only occurs if I zoom in really close to the text. If I back off the camera a bit, the text reverts back to the correct state. My questions are: 1) What's causing this? 2) How best to address the issue? __ _ 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] Is text thread safe in 2.0.0?
Initial testing is encouraging. Tried it out on my quad core box, no
troubles at all. Tested in debug/release with anywhere from 3 to 20
threads running at once. No crashesever, exited cleanly, etc.
Currently compiling on my dual-processor box. Will do longer tests on
that system and my quad core box and report back tomorrow.
On 9/4/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Sheman,
Thanks for testing and changes. I have added static Mutex directly
into the DefaultFont::instance() method rather that add it the
DefaultFont class. It should provide the same effect but keep things
a little bit neater.
I have also added a mutex into Font::GlphTexture to marshal the
addGlyph and texture apply.
Could you do an svn update and let me know how you get on,
Cheers.
Robert.
On 9/2/07, sherman wilcox [EMAIL PROTECTED] wrote:
I spent a few moments digging into the crash I was having...looks like
a race condition in DefaultFont* DefaultFont::instance(). I wasn't
sure about the best course, but I thought the simplest solution was to
wrap that call with a mutex, which I did. After doing that, no more
crashes when I run --mt 10 in Release mode. I've attached the changes
defaultfont.h/.cpp.
BUT...I still get crashes in debug mode @ --mt 10 The crashes are
easily reproduced. I left the code running for quite a while in
Release mode, didn't crash. Debug dies immediatly.
I've attached the changes defaultfont.h/.cpp.
Here's a call stack from the new crashes...in void
Font::GlyphTexture::apply(osg::State state) I noticed that the
elements in the _glyphs container had bad _font objects...these _font
objects had addresses of 0xcdcdcdcd. Not sure at what point things
went off into the weeds.
Stack trace from most recent crash:
osgTextd.dll!std::_Vector_const_iteratorosg::ref_ptrosgText::Font::Glyph,std::allocatorosg::ref_ptrosgText::Font::Glyph
::operator++() Line 117 + 0x33 bytesC++
osgTextd.dll!osgText::Font::GlyphTexture::apply(osg::State
state={...}) Line 653 + 0x8 bytes C++
osgd.dll!osg::State::applyAttribute(const osg::StateAttribute *
attribute=0x0195c730, osg::State::AttributeStack as={...}) Line
1158 + 0x13 bytes C++
osgd.dll!osg::State::applyTextureAttribute(unsigned int unit=0,
const osg::StateAttribute * attribute=0x0195c730) Line 337 + 0x10
bytes C++
osgTextd.dll!osgText::Text::renderOnlyForegroundText(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1971 +
0x1d bytes C++
osgTextd.dll!osgText::Text::drawImplementation(osg::State
state={...}, const osg::Vec4f colorMultiplier={...}) Line 1587 C++
osgTextd.dll!osgText::Text::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 1471C++
osgd.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...})
Line 868 + 0x13 bytes C++
osgUtild.dll!osgUtil::RenderLeaf::render(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28) Line 60
+ 0x19 bytesC++
osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28) Line
408 + 0x19 bytesC++
osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28) Line
373 + 0x17 bytesC++
osgUtild.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28) Line
458 + 0x35 bytesC++
osgUtild.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28) Line
1053C++
osgUtild.dll!osgUtil::RenderBin::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28) Line
373 + 0x17 bytesC++
osgUtild.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28, bool
doCopyTexture=false) Line 722 C++
osgUtild.dll!osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x09837b28) Line
913 + 0x1b bytesC++
osgUtild.dll!osgUtil::SceneView::draw() Line 1456 + 0x34 bytes C++
osgViewerd.dll!osgViewer::Renderer::draw() Line 382 + 0xf bytes
C++
osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext
* context=0x01926430) Line 573 C++
osgd.dll!osg::GraphicsContext::runOperations() Line 671 + 0x33
bytes C++
osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext *
context=0x01926430) Line 135 C++
osgd.dll!osg::GraphicsOperation::operator()(osg::Object *
object=0x01926430) Line 50 + 0x19 bytesC++
osgd.dll!osg::OperationThread::run() Line 413 + 0x26
Re: [osg-users] Is text thread safe in 2.0.0?
Success! Well, not that kind of success. You see, I was running the
osgText multithreaded sample you wrote...it would not crash. Ran
perfectly on all my systems. So..I crank up my app, which just so
happens has an option to update osgText objects on a background
thread. CRASH!!! Time and time again...crash! So, I spent most of the
night trying to debug this.
Long story shortened, I haven't figured out the crash BUT I have a
clue. If I introduce an earth model built using osgDem into your
osgText demo with about 10 threads running (probably will happen with
fewer, haven't tried) I get the same crash as I do in my app. I
suspect the problem has something to do with the databasepager.
Let me explain. The crash in the new --MT osgText demo (as well as in
my app) both die in:
osgText::Font::getGlyphImageMarginRatio() Line 241 C++
Here's my call stack:
osgText.dll!osgText::Font::getGlyphImageMarginRatio() Line 241 C++
osgdb_freetype.dll!FreeTypeFont::setFontResolution(unsigned int width=60,
unsigned int height=60) Line 64 + 0x9 bytes C++
osgText.dll!osgText::Text::computeGlyphRepresentation() Line 485 C++
osgText.dll!osgText::Text::setFont(osgText::Font * font=0x0828e2c8)
Line 119 + 0x7 bytes C++
osgText.dll!osgText::Text::setFont(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
fontfile=Arial.ttf) Line 124 + 0x1a bytes C++
Here's the call stack from the osgText demo:
osgText.dll!osgText::Font::getGlyphImageMarginRatio() Line 241 C++
osgdb_freetype.dll!FreeTypeFont::setFontResolution(unsigned int
width=32, unsigned int height=32) Line 64 + 0x9 bytes C++
osgText.dll!osgText::Text::computeGlyphRepresentation() Line 485 C++
osgText.dll!osgText::Text::setText(const osgText::String text={...})
Line 165 + 0x7 bytes C++
osgText.dll!osgText::Text::setText(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
text=)]#œ) Line 170 + 0x1e bytes C++
osgtest.exe!UpdateTextOperation::load() Line 561 C++
osgtest.exe!UpdateTextOperation::operator()(osg::Object *
callingObject=0x) Line 498 + 0x5 bytes C++
osg.dll!osg::OperationThread::run() Line 416 C++
OpenThreads.dll!OpenThreads::ThreadPrivateActions::StartThread(void *
data=0x00f29f90) Line 120 C++
msvcr80.dll!__endthreadex() + 0x3b bytes
msvcr80.dll!__endthreadex() + 0xc7 bytes
[EMAIL PROTECTED]@12() + 0xe bytes
[EMAIL PROTECTED]() + 0x23 bytes
They both die in osgText::Font::getGlyphImageMarginRatio().
I'm wondering if there's a reference count problem somewhere that's
causing the Font object to be prematurely deleted? That is, the
activeFont object in Text::computeGlyphRepresentation is getting the
rug pulled out from under it. I say that because the databasepager
will call Registry::readImplementation(const ReadFunctor readFunctor,
bool useObjectCache) with useObjectCache as false...which clears the
cache which decrements the refcount on cached Font objects...sometimes
this decrement is fatal? Maybe? I dunno, maybe I'm grasping @ straws,
but I do know if you don't incorporate the database pager then things
seem to run fine.
Any ideas?
On 9/4/07, Robert Osfield [EMAIL PROTECTED] wrote:
Hi Sheman,
Thanks for testing and changes. I have added static Mutex directly
into the DefaultFont::instance() method rather that add it the
DefaultFont class. It should provide the same effect but keep things
a little bit neater.
I have also added a mutex into Font::GlphTexture to marshal the
addGlyph and texture apply.
Could you do an svn update and let me know how you get on,
Cheers.
Robert.
On 9/2/07, sherman wilcox [EMAIL PROTECTED] wrote:
I spent a few moments digging into the crash I was having...looks like
a race condition in DefaultFont* DefaultFont::instance(). I wasn't
sure about the best course, but I thought the simplest solution was to
wrap that call with a mutex, which I did. After doing that, no more
crashes when I run --mt 10 in Release mode. I've attached the changes
defaultfont.h/.cpp.
BUT...I still get crashes in debug mode @ --mt 10 The crashes are
easily reproduced. I left the code running for quite a while in
Release mode, didn't crash. Debug dies immediatly.
I've attached the changes defaultfont.h/.cpp.
Here's a call stack from the new crashes...in void
Font::GlyphTexture::apply(osg::State state) I noticed that the
elements in the _glyphs container had bad _font objects...these _font
objects had addresses of 0xcdcdcdcd. Not sure at what point things
went off into the weeds.
Stack trace from most recent crash:
osgTextd.dll!std::_Vector_const_iteratorosg::ref_ptrosgText::Font::Glyph,std::allocatorosg::ref_ptrosgText::Font::Glyph
::operator++() Line 117 + 0x33 bytesC++
osgTextd.dll!osgText::Font::GlyphTexture::apply(osg::State
state={...}) Line 653 + 0x8 bytes C++
osgd.dll!osg::State::applyAttribute(const osg::StateAttribute *
attribute=0x0195c730, osg::State
[osg-users] compressed textures (DDS) and texture rectangles
OSG doesn't support compressed textures when using texture rectangles, does it?
Earlier today I tried to load some DDS files using the
osg::TextureRectangledidn't work. Thought it was something I was
doing wrong so I started digging and ran across this comment in
texturerectangle.cpp:
// UH: ignoring compressed for now.
Yep, that was the first clue! Anyway, I hacked in a quick change, just
not sure how robust it is. Here tis:
*old code
// UH: ignoring compressed for now.
glTexImage2D(target, 0, _internalFormat,
image-s(), image-t(), 0,
(GLenum)image-getPixelFormat(),
(GLenum)image-getDataType(),
image-data() - dataMinusOffset + dataPlusOffset );
*new code
if(isCompressedInternalFormat(_internalFormat)
extensions-isCompressedTexImage2DSupported())
{
extensions-glCompressedTexImage2D(target, 0, _internalFormat,
image-s(), image-t(), 0,
image-getImageSizeInBytes(),
image-data() - dataMinusOffset + dataPlusOffset);
}
else
{
// UH: ignoring compressed for now.
glTexImage2D(target, 0, _internalFormat,
image-s(), image-t(), 0,
(GLenum)image-getPixelFormat(),
(GLenum)image-getDataType(),
image-data() - dataMinusOffset + dataPlusOffset );
}
In my limited testing with DXT5 DDS files, this quick change appears
to work. Admittedly, I didn't spend too much time on this, it's late
and I'm tired. So, if anyone sees a problem or would simply like to
offer suggestions...
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is text thread safe in 2.0.0?
An update...left the osgtext --mt demo running all night on both systems, both had crashed by the time I got up this morning. On 8/30/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi Sherman, Thanks for the ThreadChecker output, just scanned through it. I don't know how to interpret all the various warnings. W.r.t crash on exit, I can recreate that here, and strongly suspect its an order of destruction issue caused by the DeleteHandler caching objects. I am considering avoiding use of DeleteHandler, but this will require use of ref_ptr in some way in the rendering backend, something that could have a significant performance impact unless we are really careful. This is a different topic to text threading issue though. Since there are lots of warnings, it'd be nice to isolate the different problems more, and fix them all - if they are real problems rather than false positives. Doing such a complete purge will take some time though. Robert. On 8/30/07, sherman wilcox [EMAIL PROTECTED] wrote: I ran this on two different systems. Dell 470 - Windows XP 32 dual processor nVidia FX 3400 : no crashes at runtime, ran extensively, exited cleanly Dell 490 - Windows Vista 64 Quad Core nVidia 8800GTX : no crashes at runtime, crashes on exit in the delete handlers. The crash on exit isn't consistent, have to run it for a while. There's a call stack from the crash at the bottom of my message. In both tests I was using the DrawThreadPerContext threading model. I ran Intel ThreadChecker 3.1 against this test app on the XP32 box. I've attached the logfile from threadchecker. I'm afraid there's a lot of noise in there, but hopefully it will help someone. If you find the threadchecker output interesting and wish to pursue it further, I'm willing to host a WebEx meeting and allow you to pop in on one of my dev boxes to further investigate with me if you like. osg.dll!std::list osg::ref_ptrosg::Operation,std::allocatorosg::ref_ptrosg::Operation ::clear() Line 826 + 0x19 bytes C++ osg.dll!osg::OperationQueue::~OperationQueue() Line 56 + 0x43 bytes C++ osgViewer.dll!osg::OperationQueue::`scalar deleting destructor'() + 0x9 bytes C++ osg.dll!osg::DeleteHandler::flushAll() Line 141 + 0x10 bytes C++ osgViewer.dll!osgViewer::`dynamic atexit destructor for 'createWindowingSystemInterfaceProxy''() + 0x21 bytes C++ osgViewer.dll!_CRT_INIT(void * hDllHandle=0x00db, unsigned long dwReason=939280740, void * lpreserved=0x0001) Line 412 + 0x9 bytes C osgViewer.dll!__DllMainCRTStartup(void * hDllHandle=0x00db, unsigned long dwReason=0, void * lpreserved=0x) Line 512 + 0x8 bytes C osgViewer.dll!_DllMainCRTStartup(void * hDllHandle=0x00db, unsigned long dwReason=0, void * lpreserved=0x0001) Line 462 + 0x11 bytes C [EMAIL PROTECTED] () + 0x14 bytes [EMAIL PROTECTED]() - 0xd1 bytes [EMAIL PROTECTED]() - 0x13 bytes kernel32.dll!761292c7() msvcr80.dll!___crtExitProcess() + 0x14 bytes msvcr80.dll!__cinit() + 0x102 bytes msvcr80.dll!_exit() + 0xd bytes osgtest.exe!__tmainCRTStartup() Line 614 C [EMAIL PROTECTED]@12() + 0xe bytes msvcr80.dll!_exit() + 0xd bytes osgtest.exe!__tmainCRTStartup() Line 614 C [EMAIL PROTECTED]@12 () + 0xe bytes [EMAIL PROTECTED]@12() + 0xe bytes On 8/28/07, Robert Osfield [EMAIL PROTECTED] wrote: To help in the process of isolating and fixing the osgText threading issues users have seen I have modified the osgtext example to do text creation in a background thread. You can now run it via: osgtext --mt What you will see on screen is a box with text strings randomly appearing/disappearing in the box. As yet I haven't see any crashes due to the font glyphs being queried at the same time the text is being updated - which was the point of the example code... These are the ones Ewe's changes look like they might address. I have also added the stats handler into the example to allow us to see the performance, but also by coincidence it adds a failure mode - when you enable stats freetype errors start appearing. These errors look to be down to freetype being based around a state model where one of threads is setting the sizes and current fonts to one thing and the other thread is try at the same time to set them to another. Freetype itself might not be thread safe either, but my current feel is that we might need more than just serializing access to freetype, we'll need to group several operations at once and serialize these batches. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list
Re: [osg-users] Is text thread safe in 2.0.0?
Here's a trace off the XP32 box. The crash is somewhat 'reliable' in that it will crash if left running long enough. 3ff0() osg.dll!osg::OperationThread::run() Line 416 C++ OpenThreads.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data=0x00c921e0) Line 120 C++ msvcr80.dll!_callthreadstartex() Line 348 + 0x6 bytes C msvcr80.dll!_threadstartex(void * ptd=0x00c97948) Line 326 + 0x5 bytes C kernel32.dll!7c80b683() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!7c911538() ntdll.dll!7c911596() On 8/30/07, Robert Osfield [EMAIL PROTECTED] wrote: On 8/30/07, sherman wilcox [EMAIL PROTECTED] wrote: An update...left the osgtext --mt demo running all night on both systems, both had crashed by the time I got up this morning. Did you get a stack trace for the crashes? 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
