Re: [osg-users] [osgPlugins] png plugin - problem loading images
Hi Andrey, Most likely your osgdb_png.dll depens on a dll not in your path. It might be libpng.dll but now I am just guessing. use dependencywalker (http://www.dependencywalker.com/) http://www.dependencywalker.com/ to see what's the problem. Laurens. On 11/23/2011 6:33 PM, Andrey Ibe wrote: Hello good ppl! i am quite new to OSG, though i managed to build it from source with several plugins. now one of them is not working - PNG. and i do need it. i am using MinGW gcc compiler suite and w7/x64 system. i built osg 3.xy from sources, with libpng, zlib, libjpg and coin plugins, which i also built from sources. i have a model that is supposed to load .png files as textures, but i'm getting this message with all the files Code: Warning: Could not find plugin to read objects from file .\textures\13.png. [Arrow] i tried renaming the png file to some nonsense and the program screamed that the file does not exist - so i guess the file path in the model is all right. [Arrow] i also tried putting the folder with osg plugins into the system path, as suggested in one of the threads. [Arrow] then i tried renaming the texture to load in the model then saving the texture into .jpg file - it worked. so the plugins themselves DO work. so where is or can the prblem be? [Question] why does the plugin not work? [Question] i do have mingw_osgdb_png.dll in the plugins folder, which is accessible from the console i run my applcation, or the osgviewer program. you may ask why do i need png textures when i am able to use .jpg textures - the answer is easy - i need transparent textures. Thank you for your time! Cheers, Andrey [/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44012#44012 ___ 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] Custom osg::NotifyHandler problems and multi-threading
Hello everyone! :]
I am trying to redirect all OSG notifications to a file by creating my own
notify handler class (inheriting from osg::NotifyHandler) but I get some random
crushes. Mostly during run-time and sometimes when I close the application. All
of them reporting some kind of heap corruption. Sometimes it might take about
5-10 minutes in order to crush. Here is my code:
Code:
class LogFileHandler : public osg::NotifyHandler
{
public:
LogFileHandler(const std::string filename) {
_log.open( filename.c_str() );
_validFile = _log.is_open();
}
void notify( osg::NotifySeverity severity, const char* message ) {
OpenThreads::ScopedLockOpenThreads::Mutex lock(_mutex);
if(!_validFile) return;
_log message;
}
protected:
~LogFileHandler(void) {
_log.close();
}
protected:
std::ofstream _log;
OpenThreads::Mutex _mutex;
bool _validFile;
};
In order to test this class I set the handler like this:
osg::setNotifyHandler( new LogFileHandler(log.txt) );
Why do I get crushes reporting an invalid heap? Am I doing something wrong?
OSG notes:
Note that osg notification API is not thread safe although notification
handler is called from many threads. When incorporating handlers into GUI
widgets you must take care of thread safety on your own.
Isn't the ScopedLock I have at the top of my notify() function enough?
If I set the osgViewer threading mode to SingleThreaded, the problem goes away.
This makes me believe that my problem has something to do with multithreading.
I am using OSG 3.0.0 and Visual Studio 2008 SP1.
Thanks a lot for your time.
Cheers,
George
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44063#44063
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] What is a good scene graph setup for post processing?
Hello, I am a little bit frustrated. I want to render my scene into a texture and map this on a plane. After that, I render the plane with an orthogonal camera. My scene use shadows (standard shadow map) and I use callbacks. My current scene graph looks like the follow example: [viewer] -- slave [rttCam] || [rootNode] [MyScene] -- Callbacks doesn't work. | [orthoCam] | [texturedPlane] I tried another setup few days ago: [viewer] /\ [rootNode] [rttCam] -- nested cam | | [orthoCam] [MyScene] -- Shadows doesn't work. | [texturedPlane] I tink this is not a special problem and my be my basic understanding is wrong (or bad) about post process effects in the scene graph. What is a good scene graph structure, if I want to render a scene in a texture and want to do some effects (motion blur, depth of field or tone mapping)? Is there a basic rule or concept? Thank you very much. Martin -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMapping in a multipass deferred setup
Hello, I have used the osg shadow implementations with great success in state of the art forward rendering. Right now I'm trying to implement shadowmapping into my deferred rendering approach. Can anyone point me into the right direction, regarding the correct usage of the view dependent shadow mapping algorithms in a RTT environment? What I need to perform is to render the shadowmap in to depth texture and apply it later in separate pass. But how do I setup the shadowmapping graph to only render the shadow texture so I can use it later on in my lighting/combine pass? any hints are welcome cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Single scene, multiple viewers : problem with texture
Hi, I've got a problem when viewing the same scene from two different viewers : - Viewer A with Camera A - Viewer B with Camera B I load a node with : Code: osg::ref_ptrosg::Node pNode = osgDB::readNodeFile(...); Then I do : Code: p_viewerA-setCamera(p_cameraA); p_viewerA-setSceneData(pNode); p_viewerB-setCamera(p_cameraB); p_viewerB-setSceneData(pNode); Everything works fine, but when viewer B is deleted, pNode's textures are no more rendered in viewer A (geometry is still rendered correctly). Is there anything special to do to share data between two viewer ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44072#44072 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to create a decal on a road segment?
To demonstrate the problem here is a screenshot.
[Image: http://forum.openscenegraph.org/files/ramp_segment_587.png ]
The code below shows a simplified version of the problem. When you look at the
same angle as shown in the screenshot, the 'lanes' (red triangles) will appear
through the 'road' (green rectangles).
Code:
#include osg/Geode
#include osg/Geometry
#include osg/ShapeDrawable
#include osg/Depth
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osgDB/WriteFile
#include vector
#include osg/Stencil
osg::Geometry * createGeometry( const std::vectorfloat roadheight, float
width, osg::Vec4Array *color, bool isDecal )
{
osg::ref_ptrosg::Geometry geometry = new osg::Geometry;
// Geometry
osg::Vec3Array* vertices = new osg::Vec3Array;
for( int i = 0; i roadheight.size(); ++i )
{
vertices-push_back(osg::Vec3( (float) i, 0 , roadheight[i]));
if( !isDecal || i % 2 == 1 )
{
vertices-push_back(osg::Vec3( (float) i, width , roadheight[i]));
}
}
geometry-setVertexArray(vertices);
// Set color
geometry-setColorArray(color);
geometry-setColorBinding(osg::Geometry::BIND_OVERALL);
// Normals, all upwards for now
osg::Vec3Array* normals = new osg::Vec3Array;
normals-push_back(osg::Vec3(0.0f,0.0f,1.0f));
geometry-setNormalArray(normals);
geometry-setNormalBinding(osg::Geometry::BIND_OVERALL);
geometry-addPrimitiveSet(new osg::DrawArrays( ( isDecal ?
osg::PrimitiveSet::TRIANGLES : osg::PrimitiveSet::TRIANGLE_STRIP )
,0,vertices-size()));
return geometry.release();
}
osg::Geode* stencilGeometry( osg::Geometry *road, osg::Geometry *decal)
{
osg::Geode *geode = new osg::Geode;
// Write to stencil buffer
{
osg::Stencil* stencil = new osg::Stencil;
stencil-setFunction(osg::Stencil::ALWAYS, 1,~0u); // Always pass where we
draw. Write 1 to stencil buffer.
stencil-setOperation(osg::Stencil::KEEP, osg::Stencil::REPLACE,
osg::Stencil::REPLACE);
osg::StateSet *stateset = road-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setAttributeAndModes(stencil,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_STENCIL_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
}
geode-addDrawable( road );
{
osg::Stencil* stencil = new osg::Stencil;
stencil-setFunction(osg::Stencil::EQUAL, 1, ~0u); // Draw only if 1.
stencil-setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP,
osg::Stencil::KEEP);
osg::StateSet *stateset = decal-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setAttributeAndModes(stencil,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_STENCIL_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_CULL_FACE, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
}
geode-addDrawable( decal );
return geode;
}
osg::Geode* multipassGeometry( osg::Geometry *road, osg::Geometry *decal)
{
osg::Geode *geode = new osg::Geode;
// road
{
osg::StateSet *stateset = road-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF |
osg::StateAttribute::OVERRIDE);
geode-addDrawable( road );
}
// Decal
{
osg::StateSet *stateset = decal-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_CULL_FACE, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
geode-addDrawable( decal );
}
// road again
{
osg::Geometry *road2 = (osg::Geometry *)
road-clone(osg::CopyOp::DEEP_COPY_STATESETS);
osg::StateSet *stateset = road2-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::ColorMask *mask = new osg::ColorMask(false, false, false, false);
stateset-setAttributeAndModes(mask, osg::StateAttribute::ON);
geode-addDrawable( road2 );
}
return geode;
}
int main(int argc, char *argv[])
{
const bool ENABLE_STENCILING = false;
osg::DisplaySettings::instance()-setMinimumNumStencilBits(1);
osg::ArgumentParser args(argc, argv);
osgViewer::Viewer viewer(args);
unsigned int clearMask = viewer.getCamera()-getClearMask();
viewer.getCamera()-setClearMask(clearMask | GL_STENCIL_BUFFER_BIT);
viewer.getCamera()-setClearStencil(0);
osg::Group* root = new osg::Group;
std::vectorfloat roadHeight;
roadHeight.push_back( 1.0f );
roadHeight.push_back( 1.0f );
roadHeight.push_back( 0.0f );
Re: [osg-users] How to create a decal on a road segment?
Hi, Thanks for your answer, but unfortunately the multi-pass technique gives the same result as the stencil buffer. (I tried it, to be really sure.) Cheers Raymond. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44073#44073 Attachments: http://forum.openscenegraph.org//files/ramp_segment_170.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to create a decal on a road segment?
Raymond,
We had a similar problem with a few, older, air field models. Luckily the
polygons that represent the stripes where positioned in the models scene-graph
to draw last (with respect to the model). All that was required was for us to
turn off depth for the sections that needed it (indicated by comments at the
nodes that mattered).
//
class SetAllNodesToNoDepth : public osg::NodeVisitor
{
public:
SetAllNodesToNoDepth():
osg::NodeVisitor( osg::NodeVisitor::TRAVERSE_ALL_CHILDREN )
{}
void apply( osg::Node node )
{
osg::StateSet* stateset = node.getStateSet();
if ( stateset )
{
stateset-setMode( GL_DEPTH_TEST, osg::StateAttribute::OFF );
node.setStateSet( stateset );
}
traverse(node);
}
};
...
model-accept( new SetAllNodesToNoDepth() );
...
I think the order can be managed with render bins as well.
There are a few ways to skin that cat.
Good luck!
-B
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Raymond Bosman
Sent: Monday, November 28, 2011 8:25 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] How to create a decal on a road segment?
To demonstrate the problem here is a screenshot.
[Image: http://forum.openscenegraph.org/files/ramp_segment_587.png ]
The code below shows a simplified version of the problem. When you look at the
same angle as shown in the screenshot, the 'lanes' (red triangles) will appear
through the 'road' (green rectangles).
Code:
#include osg/Geode
#include osg/Geometry
#include osg/ShapeDrawable
#include osg/Depth
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osgDB/WriteFile
#include vector
#include osg/Stencil
osg::Geometry * createGeometry( const std::vectorfloat roadheight, float
width, osg::Vec4Array *color, bool isDecal )
{
osg::ref_ptrosg::Geometry geometry = new osg::Geometry;
// Geometry
osg::Vec3Array* vertices = new osg::Vec3Array;
for( int i = 0; i roadheight.size(); ++i )
{
vertices-push_back(osg::Vec3( (float) i, 0 , roadheight[i]));
if( !isDecal || i % 2 == 1 )
{
vertices-push_back(osg::Vec3( (float) i, width , roadheight[i]));
}
}
geometry-setVertexArray(vertices);
// Set color
geometry-setColorArray(color);
geometry-setColorBinding(osg::Geometry::BIND_OVERALL);
// Normals, all upwards for now
osg::Vec3Array* normals = new osg::Vec3Array;
normals-push_back(osg::Vec3(0.0f,0.0f,1.0f));
geometry-setNormalArray(normals);
geometry-setNormalBinding(osg::Geometry::BIND_OVERALL);
geometry-addPrimitiveSet(new osg::DrawArrays( ( isDecal ?
osg::PrimitiveSet::TRIANGLES : osg::PrimitiveSet::TRIANGLE_STRIP )
,0,vertices-size()));
return geometry.release();
}
osg::Geode* stencilGeometry( osg::Geometry *road, osg::Geometry *decal)
{
osg::Geode *geode = new osg::Geode;
// Write to stencil buffer
{
osg::Stencil* stencil = new osg::Stencil;
stencil-setFunction(osg::Stencil::ALWAYS, 1,~0u); // Always pass where we
draw. Write 1 to stencil buffer.
stencil-setOperation(osg::Stencil::KEEP, osg::Stencil::REPLACE,
osg::Stencil::REPLACE);
osg::StateSet *stateset = road-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setAttributeAndModes(stencil,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_STENCIL_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
}
geode-addDrawable( road );
{
osg::Stencil* stencil = new osg::Stencil;
stencil-setFunction(osg::Stencil::EQUAL, 1, ~0u); // Draw only if 1.
stencil-setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP,
osg::Stencil::KEEP);
osg::StateSet *stateset = decal-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setAttributeAndModes(stencil,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_STENCIL_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF |
osg::StateAttribute::OVERRIDE);
stateset-setMode(GL_CULL_FACE, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
}
geode-addDrawable( decal );
return geode;
}
osg::Geode* multipassGeometry( osg::Geometry *road, osg::Geometry *decal)
{
osg::Geode *geode = new osg::Geode;
// road
{
osg::StateSet *stateset = road-getOrCreateStateSet();
stateset-setRenderBinDetails(1,RenderBin);
stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF |
osg::StateAttribute::OVERRIDE);
geode-addDrawable( road );
}
// Decal
{
osg::StateSet *stateset =
[osg-users] ON_DEMAND and other windows in Qt
I am using OSG osgEarth in my Qt application. When I use ON_DEMAND, it does not always repaint when I would expect it to. The easiest way to describe this would be as follows (I have seen several variations to this, but believe they are all related): 1) Open up the application using osgEarth in ON_DEMAND mode. 2) Wait until no painting is being done. 3) Open up Task Manager and drag it around the application in #1. 4) You will see the task manager window everywhere it was dragged. 5) As soon as the mouse or keyboard causes an update, the view is fixed. It almost seems that somewhere a message is being ignored. Okay, maybe ignored is not the right word . . . handled??? For example, maybe a paintEvent is triggered in Qt because of a rectangle or region has become invalid. I found a way to fix this by forcing frame() to be called if the rect() is different than the graphics window. Is there a more elegant way of doing this??? Is this actually a bug in OSG or osgEarth? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44077#44077 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::GraphicsWindow::getWindowRectangle() results
I had developed some Qt code on Windows that worked great. When I compiled it on Linux, I noticed some oddities. The most interesting one is that: osgViewer::GraphicsWindow::getWindowRectangle() returns an absolute window position in Windows (x != y != 0) whereas it seems to be relative in Linux (x = y = 0). Is that normal? Is that just the way it works with the different windowing? Should I be looking at the parent instead or something? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44078#44078 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindow::getWindowRectangle() results
Hi Thomas, I had developed some Qt code on Windows that worked great. When I compiled it on Linux, I noticed some oddities. The most interesting one is that: osgViewer::GraphicsWindow::getWindowRectangle() returns an absolute window position in Windows (x != y != 0) whereas it seems to be relative in Linux (x = y = 0). Is that normal? Is that just the way it works with the different windowing? Should I be looking at the parent instead or something? I've seen the same problem manifested differently: when someone (say Robert) develops an example and tests it in Linux, they will often call this function to create a default window: viewer.setUpViewInWindow(0,0,1024,768); If I then run this example on Windows, the window's title bar will be outside the screen. So on Windows, it seems like the position (0,0) means the window's client area, whereas on Linux it means the window itself. I guess someone should fix this inconsistency (just choose one behavior and stick to it on all OSes...) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindow::getWindowRectangle() results
Thank you for your reply. I actually got around this by getting the central widget's (Qt) window rectangle instead of using the graphic window's rectangle. I agree that this seems like an inconsistency that would be nice to take care of. Incidentally, I took a quick look and did not see a parent to the graphic window, but could have missed it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44080#44080 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Full-scene blend with render to texture problems
I am encountering some problems with full-scene blending using render to texture. It appears that the blend operation is reading the main scene data as being completely blank (ie. matching the clear colour). I have already spent a fair few hours trying to solve this on my own, and I was wondering if anyone has any tips that may help me track down the cause. Frustratingly, I seem to be stuck on the easy part of the problem (the blending), but not on the more difficult part (the render to texture). What I am doing is as follows: I have created an osgViewer::Viewer (viewer), and a main camera (mcam), and an empty owg::Group (root), and attached the latter two to the first (viewer.setCamera(mcam), viewer.setSceneData(root)). I have created a second camera (ovcam) which manages CEGUI, and attached it to the root (root.addChild ovcam). I mention CEGUI only in case it is interfering with the rest somehow. I set up a scene, which is basically an osg::Group with a bunch of children. This is added to the root group. Later on, after some updates, I create a new scene, add that to root, remove the first from root, and set up a render-to-texture camera. The means of doing this is roughly based upon the code here: http://sourceforge.net/apps/mediawiki/delta3d/index.php?title=Tutorial_Render_To_Texture Both cameras are added to root. I am uncertain if the resultant structure is correct and would welcome suggestions. I have tried experimenting with the structure but have either been met with crashes or it does not solve the problem. I suspect it may be related though. The RTT texture camera has the render order set to PRE_RENDER, the blending camera is set to POST_RENDER. The main scene uses the default render order, which should lie between the two (is this right?). The problem occurs when I try to blend the result into the main scene. The plan is to render the RTT quad with a variable alpha value to manage the fade. For now, I'm just rendering the RTT quad over a section of the main view (I'll call that the box), and using a BlendFunc of CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA. Setting the alpha value with BlendColor affects the result roughly as you'd expect. I'm just using a fixed value for now (until I get it working, of course). The colours in the source image (the image rendered to the texture) seem to come through fine, but the target colour always seems set to the clear colour of the main camera. To explain further: - Using CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA, if you drop the constant alpha down lower, the prerendered image in the box becomes fainter, eventually fading to the main camera solid clear colour. This is only correct behaviour if the main scene was completely blank (ie. solid clear colour). It should be fading out to the main scene. - If you blend with ONE/ZERO, you get the RTT image untouched (but not blended) in the box. This is expected, and confirms the RTT step is working correctly (ie. the scene rendered to texture is entirely correct). The result is the same with CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA and alpha 1.0. - If you blend with ZERO/ONE, you get a solid box matching the clear colour. It should get the image from the main scene (ie. you should not be able to see the box at all). The result is the same with CONSTANT_ALPHA/ONE_MINUS_CONSTANT_ALPHA and alpha 0.0. - If you change the clear colour for the main camera, the colour of the box for ZERO/ONE matches, which is the basis behind my theory that the destination colour is always being read by the blend function, rather than the scene data. If I had to guess as to what the problem may be, I would guess: - I am setting up the scene graph containing the cameras incorrectly to ensure they are rendering in the correct order. It is almost as if the blending camera (set to POST_RENDER) is rendering *before* the main scene camera, but after the clear for that camera. - I am missing something that is causing the blend function to use the wrong destination data as the destination input to the blend function. Perhaps I am not enabling something that needs enabling, or have not correctly specified where the destination input data should come from. I have been experimenting on these fronts (and others), trying to guess the correct way to do things. I have been unsuccessful so far. I think I have correctly isolated the problem as the destination input for the blend function as being incorrect. I am just not sure what to change to correct it. Any advice or pointers appreciated. I'm sure it's something simple that I have overlooked. Please feel free to ask any questions to clarify what I am doing. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44081#44081 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Full-scene blend with render to texture problems
I forgot to mention: I am using OpenSceneGraph 3.0.1 under Linux. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44082#44082 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Single scene, multiple viewers : problem with texture
Aurelien wrote: Hi, I've got a problem when viewing the same scene from two different viewers : - Viewer A with Camera A - Viewer B with Camera B I load a node with : Code: osg::ref_ptrosg::Node pNode = osgDB::readNodeFile(...); Then I do : Code: p_viewerA-setCamera(p_cameraA); p_viewerA-setSceneData(pNode); p_viewerB-setCamera(p_cameraB); p_viewerB-setSceneData(pNode); Everything works fine, but when viewer B is deleted, pNode's textures are no more rendered in viewer A (geometry is still rendered correctly). Is there anything special to do to share data between two viewer ? Thank you! Cheers, Aurelien Well, I would look at it differently (like using slave cameras), but in this case, have you tried dynamically linking the node? D Glenn David Glenn --- D Glenn 3D Computer Graphics amp; Media Systems. www.dglenn.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44083#44083 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Full-scene blend with render to texture problems
... and solved. :) I think getting a good night's sleep helped. My code (and the example I was basing it off of) did not set the clear mask for orthoCamera. Checking the source, this defaults to wiping the colour and depth buffer, which isn't what I wanted (depth buffer only, or no depth testing). Explicitly setting it immediately solved the problem. As for the destination clear colour bleeding through? It turns out that wasn't the case at all. The textureCamera clear colour and alpha values and simple sceney I was using by awful coincidence just happened to blend together to *appear* to match that colour. When I changed the colours earlier, it was before I'd set them to two distinct colours, so I came to the wrong conclusion. I knew the bleeding colour problem made no sense! For anyone who ends up in this thread with a similar problem, my best suggestion I guess would be to double-check all the clears, colours, and dimensions of the extra cameras you are using. If the destination colour seems to be missing, it might be because one of the cameras is wiping it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44084#44084 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Setting modelview matrix with viewer.getCamera()-setViewMatrix(modelViewMatrix) not working
Hi,
I want to set the modelview matrix with
viewer.getCamera()-setViewMatrix(modelViewMatrix) like in the
following code:
int main(int argc, char **argv)
{
osgViewer::Viewer viewer;
osg::Node* rootNode = createRootNode();
viewer.setSceneData(rootNode);
return viewer.run();
}
Later, in an osg::NodeCallback, I perform:
viewer.getCamera()-setViewMatrix(modelViewMatrix);
But the modelview matrix isn't modified at all.
On the other hand,
viewer.getCamera()-setProjectionMatrix(projectionMatrix) seems to
work.
What should I do to the viewer in order for setViewMatrix() to work?
Thank you!
Cheers,
Juan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting modelview matrix with viewer.getCamera()-setViewMatrix(modelViewMatrix) not working
Hi,
This might be your problem:
If you use CameraManipulator (for example TrackballManipulator), it will
overwrite your ViewMatrix every frame ... see Viewer.cpp @1040
Code:
if (_cameraManipulator.valid())
{
setFusionDistance( getCameraManipulator()-getFusionDistanceMode(),
getCameraManipulator()-getFusionDistanceValue() );
_camera-setViewMatrix(_cameraManipulator-getInverseMatrix());
}
Cheers,
Filip
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44087#44087
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
