Re: [osg-users] RFC: Positional state container in the render bin, was: clip planes
Good morning Robert, On Thursday 13 September 2007, Robert Osfield wrote: I'm just trawling through the morning inbox and a blurry headed so not in a zone able to contemplate complex stuff too deeply. I will review your changes a latter date though. :) Was there much fallout from applying your changes? Do things function w.r.t normal OSG usage and the type of usage you need? Well it helps for reusing clip plane numbers for different parts of the scenegraph. You remember that we discussed that topic for flightgears instrument panels when you visited us in Tübingen. Also I can imagine that being able to reuse light numbers is a good idea for some applications. That will definitely help me implementing instrument panels for flightgear. With the current osg implementation, I will need to implement them as a custom drawable. With that patch I can make use of scenegraph elements for that. That will definitely be more generic than ... As you can see in the changed clip node example, usage of clip nodes and light sources is the same than before. Just the scope where such a positional state is valid is then a render bin instead of a render stage. To be honest, I do not really understand what you mean with fallout. So, I hope that this will answer your question. An other possible solution to that 'reuse of clip plane numbers problem' would be to introduce some PositionalStateBin derived from the RenderBin and the Render Stage derived from the PositionalStateBin. Then we would need something to trigger the usage of a such a PositionalStateBin instead of a normal RenderBin in the rendering backend. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PSSM: Latest Version : Please Test and Debug
Hi latest version,
(1) NVidea Cards, the setting of the Polygon offset seems to be not correct
on my ATI it's seems to be correct (looks nice)
please test and check for good values, i don't now a good value for
this
(2) GLSL shader has to be generated dynamic, if we change the number of
split planes
the version no longer need any IF in the GLSL shader, this makes the
good a little bit different form the suggestion in the paper PSSM
(3) try it out and test
pssm --help
enjoy and have a nice weekend, i will be not online till monday. if you have
some ideas, fixes etc please send me the new code. then i will be able to
test it
out. i hope for next osg release we will have a good and robust PSSM
implementation what would be greate.
the next version of PSSM would have project maps, at the moment it supports
just directional lights
/adegli
2007/9/14, Adrian Egli [EMAIL PROTECTED]:
hi,
i will post the first version of the PSSM for a sun as directional lights.
Please help in test, debug, and optimisation, than we can integrate it
into OSG core, i would like doing this as soon as possible.
call in a console...
PSSM --help
example
PSSM.exe dumptruck.osg --noUpdate --mapcount 3
PSSM.exe dumptruck.osg --noUpdate --mapcount 3 --NO-DEBUG
* we need a better GLSL shader ! My version isn't yet good enough (and
robust)
* i guess there is still a little bug, the near-far clipping plane for the
each camera (shadow)
* ...
others
thanks for help
/ adrian
--
Adrian Egli
--
Adrian Egli
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commericial and non commericial applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
//#define ADDITIONAL_BASE_PLANE 1
#define MOVING_LIGHT 1
const int ReceivesShadowTraversalMask = 0x1;
const int CastsShadowTraversalMask = 0x2;
const int MAX_SPLIT_TEXTURES = 3;
const int size_display_debug_texture = 100;
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osgText/Text
#include osg/MatrixTransform
#include osg/Projection
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgGA/FlightManipulator
#include osgGA/DriveManipulator
#include osgGA/KeySwitchMatrixManipulator
#include osgGA/StateSetManipulator
#include osgGA/AnimationPathManipulator
#include osgGA/TerrainManipulator
#include osg/ComputeBoundsVisitor
#include osg/ShapeDrawable
#include osg/Geometry
#include osgShadow/ShadowedScene
#include ShadowPSSM.h
#include iostream
namespace ModelThree
{
osg::Group* createModel(osg::ArgumentParser arguments)
{
osg::Group* scene = new osg::Group;
osg::ref_ptrosg::Geode geode_1 = new osg::Geode;
scene-addChild(geode_1.get());
osg::ref_ptrosg::Geode geode_2 = new osg::Geode;
osg::ref_ptrosg::MatrixTransform transform_2 = new osg::MatrixTransform;
transform_2-addChild(geode_2.get());
transform_2-setUpdateCallback(new osg::AnimationPathCallback(osg::Vec3(0, 0, 0), osg::Z_AXIS, osg::inDegrees(45.0f)));
scene-addChild(transform_2.get());
osg::ref_ptrosg::Geode geode_3 = new osg::Geode;
osg::ref_ptrosg::MatrixTransform transform_3 = new osg::MatrixTransform;
transform_3-addChild(geode_3.get());
transform_3-setUpdateCallback(new osg::AnimationPathCallback(osg::Vec3(0, 0, 0), osg::Z_AXIS, osg::inDegrees(-22.5f)));
scene-addChild(transform_3.get());
const float radius = 0.8f;
const float height = 1.0f;
osg::ref_ptrosg::TessellationHints hints = new osg::TessellationHints;
hints-setDetailRatio(2.0f);
osg::ref_ptrosg::ShapeDrawable shape;
shape = new osg::ShapeDrawable(new osg::Box(osg::Vec3(0.0f, 0.0f, -2.0f), 10, 10.0f, 0.1f), hints.get());
shape-setColor(osg::Vec4(0.5f, 0.5f, 0.7f, 1.0f));
geode_1-addDrawable(shape.get());
shape = new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0.0f, 0.0f, 0.0f), radius * 2), hints.get());
shape-setColor(osg::Vec4(0.8f, 0.8f, 0.8f, 1.0f));
geode_1-addDrawable(shape.get());
shape = new osg::ShapeDrawable(new osg::Sphere(osg::Vec3(-3.0f, 0.0f, 0.0f), radius), hints.get());
shape-setColor(osg::Vec4(0.6f, 0.8f, 0.8f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new osg::ShapeDrawable(new osg::Box(osg::Vec3(3.0f, 0.0f, 0.0f), 2 * radius), hints.get());
shape-setColor(osg::Vec4(0.4f, 0.9f, 0.3f, 1.0f));
geode_2-addDrawable(shape.get());
shape = new osg::ShapeDrawable(new osg::Cone(osg::Vec3(0.0f, -3.0f, 0.0f), radius, height), hints.get());
shape-setColor(osg::Vec4(0.2f, 0.5f, 0.7f,
Re: [osg-users] Dos, Don'ts and DOH's of Drawables with threading?
Hi Adam, Paul did a nice explanation so I have little to add. For future reference what was the change that fixed the problem you were seeing? Robert. On 9/15/07, Adam Coates [EMAIL PROTECTED] wrote: Excellent - that was all the explanation I needed. Everything is humming along just fine now. Thanks, Paul! AC On 9/14/07, Paul Martz [EMAIL PROTECTED] wrote: I'm not sure why you have a thread hung in drawImplementation() after Viewer's destructor has been called. But I can explain some of the other stuff you have questions on, and hopefully that'll help. My question is, how do you guys normally deal with data (scene graph, geometry, text, whatever) being modified on the main thread while Viewer is apparently busy rendering the same data? Mark the Node or Drawable as DYNAMIC DataVariance, and only modify it during the update traversal (or outside the rendering traversals). Having looked at a lot of the other drawables included in OSG, I don't see how the double buffering scheme works -- how is that any of the scene graph or other geometry data get updated without creating a race condition like this? OSG operates on a gentleman's agreement under which you can do whatever you want to DYNAMIC nodes during the update traversal, and OSG's possibly multiple threads can perform read-only operations during the cull/draw traversals. With osgViewer-based apps, marking nodes that you intend to modify as DYNAMIC is critical, otherwise OSG might let the update traversal start (or return from frame()) before it has finished processing the node that you're going to modify. What's the trick here? What can/can't one do from with the drawImplementation() method in order to remain thread safe? drawImplementation() should be const, so as long as you don't modify it or anything else in the scene graph, you should be OK. Hope that helps. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.1.10 windows refresh / performance
HI Gert, On 9/15/07, Gert van Maren [EMAIL PROTECTED] wrote: Tried it on a couple more machines and all the same issue. This issue has been there since post OSG1.2. Have a look at the attached screenshot. OSG 2.x has a completely new windowing support. In theory it should actual be more Windows friendly than the old Producer Win32 support, supporting a wider range of capabilities. I'm not the author of the src/osgViewer/GraphicWindowWin32.cpp or a windows expert so can't really comment or help directly on finding out what this problem stems from. The best I can divine is that problem itself is a window manage issue, i.e. its the window managers responsibility to draw its own decoration and menu bars etc, of for some reason is being rather too lazy in updating itself. Under windows do you have to give the window manager a kick (i.e. send it an event) each time you close a window? This is something Windows developers will need to answer code a solution. Happens in debug and release. I haven't yet worked out how to make CMake by itself default to selecting Release build. Under unices you can use the configure script which simple does: cmake . -DCMAKE_BUILD_TYPE=Release Its absolutely essential to make a release build before doing any benchmarking as it makes a massive difference to performance. Did do the Cmake release compile but the /O2 option didn't get set in the vs project by Cmake (running VS2003 7). Had to add it manually. Now have comparable fps as OSG12. How are you building using CMake? Using CMakeSetup? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.1.10 crash in osgText / osgdb_freetyped
What kind of performance penalty is there for adding the dynamic flag to text, if, say, you're dealing with 10's of thousands of text objects? --- Robert Osfield [EMAIL PROTECTED] wrote: Hi Gert, Glad to hear that you have your app back up and running. I do wonder if it would be worth use adding a setDataVariance(DYNAMIC) any time a user applies an update callback to a Drawable of StateSet, its perhaps a little overprotective but as this problem seems to biting a number of developers perhaps its reasonable. Robert. On 9/14/07, Gert van Maren [EMAIL PROTECTED] wrote: Hi Robert, Is this in your own application or one of the OSG examples? It is our own app. Are you creating text and then updating per frame? We're creating text and using UpdateCallback to add. Are you running osgViewer multi-threaded? If so which threading model? Well when I run dual core the OSG automatically picks the DrawThreadPerContext model - crash. If I turn dual core off - SingleThread no crash. One possibility is that the new DrawThreadPerContext threaded model is overlapping the drawing of the text with any updating of the text. The way to prevent problems like this is to explictly set the data variance on the text to DYNAMIC so that the draw traversal knows to hold back the next frame till all the dynamic objects have been dispatched. You can ensure this via: myText-setDataVariance(osg::Object::DYNAMIC); Great, that did the trick Thanks Robert. -- Gert van Maren Head of Research Development K2Vi Virtual Reality Software Data Interface Technologies Ltd Phone: +64 21 2855581 Email: [EMAIL PROTECTED] Web: http://www.k2vi.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] Background image texture rescaling problem
Thanks Robert, I have this working now without rescaling the image. My solution was to pad the image with zeros making it a power of two and then specify the correct percentage of the image to use as 2D texture. Not sure if this is the best solution but it works and is fast enough for me. -- John On 9/13/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi John, The rescaling is done on non power of two textures by default, rescaling is slow op so best avoided. You have two choices to disable the resize of the non power of two texture as you have down to move to using TextureRectangle instead of Texture2D. If moving to the TextureRectangle you'll need to move you pixel coords rather than normal non dimensions texture coords - see osgtexturerectangle example. Robert. On 9/12/07, John Steinbis [EMAIL PROTECTED] wrote: For an AR project, I need to render a model with video image as background. My program is based around osgViewer using osg v2.0. I found an example for a HUD and with a few changes made it work as background. The code can be found below. The code runs ok but there is a problem occurring that I cannot figure out. Any ideas … ? When new images are loaded, they are rescaled for some reason. This adds a noticeable delay, ~250 ms, and distorts the images, which is not acceptable. Output looks like Scaling image 'x' from (720,480) to (512,512). To prevent resizing I use BGTexture-setResizeNonPowerOfTwoHint(false). To update an image I use BGTexture-setImage(newImg). Thanks, John root-addChild(BGProjectionMatrix); BGProjectionMatrix-setMatrix(osg::Matrix::ortho2D(0,width,0,height)); BGProjectionMatrix-addChild(BGModelViewMatrix); BGModelViewMatrix-setMatrix(osg::Matrix::identity()); BGModelViewMatrix-setReferenceFrame(osg::Transform::ABSOLUTE_RF); BGModelViewMatrix-addChild( BGGeode ); BGTexture-setDataVariance(osg::Object::DYNAMIC); BGTexture-setResizeNonPowerOfTwoHint(false); // -- BGTexture-setImage(BGImage); BGGeode-addDrawable(BGBackgroundGeometry); BGGeode-setStateSet(BGStateSet); BGBackgroundVertices-push_back( osg::Vec3( 0, 0, 0) ); BGBackgroundVertices-push_back( osg::Vec3(width, 0, 0) ); BGBackgroundVertices-push_back( osg::Vec3(width, height, 0) ); BGBackgroundVertices-push_back( osg::Vec3( 0, height, 0) ); (*texcoords)[0].set(0.0f,0.0f); (*texcoords)[1].set(1.0f,0.0f); (*texcoords)[2].set(1.0f,1.0f); (*texcoords)[3].set(0.0f,1.0f); BGcolors-push_back(osg::Vec4(1.0f,1.0f,1.0f,1.0f)); BGnormals-push_back(osg::Vec3(1.0f,1.0f,1.0f)); BGBackgroundGeometry-setTexCoordArray(0,texcoords); BGBackgroundGeometry-setColorArray(BGcolors); BGBackgroundGeometry-setColorBinding(osg::Geometry::BIND_OVERALL); BGBackgroundGeometry-setNormalArray(BGnormals); BGBackgroundGeometry-setNormalBinding(osg::Geometry::BIND_OVERALL); BGBackgroundGeometry-addPrimitiveSet(BGBackgroundIndices); BGBackgroundGeometry-setVertexArray(BGBackgroundVertices); BGBackgroundIndices-push_back(0); BGBackgroundIndices-push_back(1); BGBackgroundIndices-push_back(2); BGBackgroundIndices-push_back(3); BGStateSet-setTextureAttributeAndModes(0,BGTexture,osg::StateAttribute::ON); BGStateSet-setMode(GL_DEPTH_TEST,osg::StateAttribute::OFF); BGStateSet-setRenderingHint( osg::StateSet::TRANSPARENT_BIN ); BGStateSet-setRenderBinDetails( 1, RenderBin); ___ 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] OSG 2.1.10 crash in osgText / osgdb_freetyped
On 9/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: What kind of performance penalty is there for adding the dynamic flag to text, if, say, you're dealing with 10's of thousands of text objects? If you aren't updating the text you should set the data variance to STATIC, and set it to DYNAMIC when its being updated. The only time that setting the data variance to DYNAMIC will make a difference to performance is when you are using DrawThreadPerContext or CullThreadPerCameraDrawThreadPerContext threading models, in SingleThreaded and CullDrawThreadPerContext it won't make any difference. The reason for the difference is that DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext threading models allow the next frames update cull to begin whilst the draw traversal is underway, but... and this is the critical part, the draw traversals holds back the next frame until varying Drawables and StateSets have been dispatched. The only way the draw traversal knows whether anything varies is that its DataVariance is set to DYNAMIC, so its important to set this other wise you'll be modifying data that is also been read at the same time - which is what causes crashes. Performance wise the less DYNAMIC data that needs to be dispatched the earlier the next frame came commense. If the last objects to be drawn is DYNAMIC then effectively you hold the next frame back for till the entire previous frame is dispatched, and you end up with SingleThreaded/CullDrawTheradPerContext performance levels. So its no really the number of dynamic objects, rather how late they are dispatched in the frame. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Background image texture rescaling problem
Hi John, On 9/15/07, John Steinbis [EMAIL PROTECTED] wrote: Thanks Robert, I have this working now without rescaling the image. My solution was to pad the image with zeros making it a power of two and then specify the correct percentage of the image to use as 2D texture. Not sure if this is the best solution but it works and is fast enough for me. This is not an elegant way to tackle the problem, workable yes, but I'd recommend spending a little time - readying up about TextureRectangle or just disabling the resize of non power of two textures, you'll end up with a more efficient and elegant solution. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Background image texture rescaling problem
I tryed disabling the resize of non power of two textures by using setResizeNonPowerOfTwoHint but it did not seem to have any effect. Do you think there is a bug or I just wasnt doing something right? You can find the line where I tried this in my original post. I havent been able to figure out how to set the position of a window. How can I do this? Also, if I try to drag the window to a new location, it freezes. -- js On 9/15/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi John, On 9/15/07, John Steinbis [EMAIL PROTECTED] wrote: Thanks Robert, I have this working now without rescaling the image. My solution was to pad the image with zeros making it a power of two and then specify the correct percentage of the image to use as 2D texture. Not sure if this is the best solution but it works and is fast enough for me. This is not an elegant way to tackle the problem, workable yes, but I'd recommend spending a little time - readying up about TextureRectangle or just disabling the resize of non power of two textures, you'll end up with a more efficient and elegant solution. 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] Background image texture rescaling problem
On 9/15/07, John Steinbis [EMAIL PROTECTED] wrote: I tryed disabling the resize of non power of two textures by using setResizeNonPowerOfTwoHint but it did not seem to have any effect. Do you think there is a bug or I just wasnt doing something right? You can find the line where I tried this in my original post. It'll only work if you have capable hardware - i.e. Gefore6 series or later, otherwise it'll detect this an resize things as usual. I havent been able to figure out how to set the position of a window. How can I do this? Also, if I try to drag the window to a new location, it freezes. We'll if you want to ask this, then start a new thread. Also in the meantime look at the osgwindow example. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] probs running OSG on non-dev system?
Hi, The official location for this vcredist_x86.exe is http://www.microsoft.com/downloads/details.aspx?FamilyID=200B2FD9-AE1A-4A14-984D-389C36F85647displaylang=en This is the updated SP1 redistributable, works for plain MSVC8 too. Cheers Olaf Thrall, Bryan schrieb: [EMAIL PROTECTED] wrote on Friday, September 14, 2007 3:12 PM: Hi Mike, My bells rang: Include a manifest. For DLL's: mt -manifest test.dll.manifest -outputresource:test.dll;2 For EXE's: mt -manifest test.exe.manifest -outputresource:test.exe;1 Also, the MSVCRT used by VS8 is not typically installed on WinXP, so this link might help: http://msdn2.microsoft.com/en-us/library/ms235299(VS.80).aspx Basically, Visual Studio 8 includes a file (on my PC its in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86) vcredist_x86.exe that will install the updated MSVCRT for you and allow the app to run. Mike Weiblen wrote: Pardon the sparse details, had a problem in wee hours this morn... Built a 2.1.10-ish OSG on one system w/ winxppro/vs8, tried to run the resulting osgviewer on a different system w/ winxphome but no VS8 installed. I got entirely unhelpful errormsgs/dialogs along the lines of that application cant be run or trying reinstalling the app. The VS8 runtime libs were present on the non-VS8 system Does this ring any bells? Could the VS8 or Cmake ocnfigs be triggering some OS or binary dependency? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
