Re: [osg-users] shaders experiments
very nice :) On 13/05/10 00:47, Trajce (Nick) Nikolov wrote: Hi community, I have been experimenting with ambient occlusion and environmental mapping (among the others) and some lighting. Here some results http://www.youtube.com/watch?v=H7yTMI3TY70 http://www.youtube.com/watch?v=H7yTMI3TY70 -Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg latest developer release, memory leak under linux
I've checked build with VERBOSE=1, nothing like -march is not set... Cheers, Paweł -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27848#27848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] reuse of clipping planes?
Hi Jason, Clip planes are an example of positional state, other examples are lights and eye linear texgen. All positional state requires a specific modelview matrix to be bound to them to position them correctly in space, so unlike other OpenGL/OSG state you can't just push/pop and state sort their state and expect to get the correct results. This difference is handled by the OSG by binding the positional state together with a modelview matrix found when encountering the ClipNode/TexGenNode/LightSource nodes, and these positional state are then applied once at the start of each RenderStage. Applying the state just once for whole RenderStage does enable us to position the state uniquely but unfortauntely also means that the positional state can only be in one place for the whole stage - you can't nest it. You can emulate having multiple sets of Clip planes/texgen/lights by having multiple stages, or do what is currently done in FlightGear, to use a custom StateAttribute that does the binding to the required modelview matrix in the CustomAttribute::apply() method taking care to push back the current modelview matrix to prevent the rest of the scene being affected. Robert. On Thu, May 13, 2010 at 2:14 AM, Jason Jerald ja...@digitalartforms.com wrote: Evidently most graphics hardware only supports 6-8 clipping planes and our application requires more than that so I need to somehow reuse clipping planes. I searched the archives and saw there was some discussion of this back in 2007 (something about possibly using the render bin instead of the render stage but it is not clear how to do so). Has reuse of clipping planes since been implemented? If so how do I do so (I have not been able to figure out how to do so by looking through clipnode)? Or if not, does anyone have any ideas/example of how to implement reuse of clipping planes? Thanks so much! Jason ___ 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] [3rdparty] osgShadow issues
Hi Garrett, Which shadow algorithm did you used (Softshadow?) Did you still tested the scene with osgShadow.exe ? there are different algorithm to work with. i am using parallel split shadow maps and it works fine for most of my applications. /adrian 2010/5/6 Garrett Cope garrett.cope@simcen.usuhs.edu Hi, I'm trying out osgShadow and have encountered various problems that I can't seem to find mentioned in the forum. The biggest one is shown in the attached jpg. The shadow is rendered below the object (using SoftShadow), but it has a bunch of light un-shadowed pixels appearing in the middle. They also appear in the self-shadowing on the side of the object. The only way I've been able to improve it is by *decreasing* the size of the shadow map which leads to other obvious quality issues. Has anyone else experienced this problem or could you tell me what the proper name is for this issue? I saw a mention of 'shadow acne' in the source which sounds like it could be the same thing, but the solution (using setBias function) did not change the problem. Any insights are appreciated. Thank you! Cheers, Garrett [img][/img] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27610#27610 Attachments: http://forum.openscenegraph.org//files/shadowtest_717.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgviewer::GraphicsWindowCarbon and wxWidgets conflict
Hi, osgViewer::GraphicsWindowCarbon and wxWidgets do not work well together on Mac OSX in case you are using dynamic wxWidget event handlers (event handlers that are linked by using wxEvtHandler::Connect). The quit-event is not caught by wxWidgets but is handled by OSG. And this means that sometimes your application does not quit. If you are using static wxWidget event handlers (like in the osgViewerWX example) the example seems to work. But I am not sure if it works in general or if it is a coincidence which library is initialized first. I recommend to disable the OSG quit event handlers in GraphicsWindowCarbon altogether when using wxWidgets. As the OSG event handlers are configured during the static initialization phase of the library I do not see any other solution than commenting out the event handler part. I would have preferred some kind of parameter during runtime but this seems to be difficult (especially when considering a platform independent handling). Any other ideas? BTW: I am using wxWidget 2.8.x and osg 2.8.2 but I do not think that this matters. BTW2: I do not want to use / did not test the Cocoa graphics window because I am still using the Carbon wxWidget library and I do not believe that it is wise to mix Cocoa and Carbon in general. Cheers, Hartwig -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27851#27851 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osgUtil::IntersectVisitor and osg::LineSegment
Hi, Thank you for your answer. Indeed, I installed both libraries, debug and release. I always compile my code in release mode (it compiles in debug mode but I don't know why the exe doesn't work then). I'll check on monday if both libraries are correctly and separately installed. Do you think it could cause the problem I have ? Cheers, Olivier -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27856#27856 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problems with EventHandlers, slave cameras and CompositeViewer
Hi Robert, Am 12.05.10 18:28, schrieb Robert Osfield: Modifying/creating an example that recreates this issue would be useful. After debugging the code once again I found my error: My master camera must not have a viewport. Without viewport the calculations of the projected mouse-coordinates are right, but with a viewport on the master camera they are wrong, because the reprojecting takes the master-viewport into account, but sets the input-rage is set to -1 .. 1. Not sure if this behavior is intentional or a bug. Nevertheless my code works now without hacking osg. thanks for your help, cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osgUtil::IntersectVisitor and osg::LineSegment
Hi, Yes Windows doesn't like that or certain parts of it, such as anything that uses memory allocation. http://stackoverflow.com/questions/1227653/linking-against-library-in-releas e-and-exe-in-debug-crashes-in-visual-studio Have a look at the above. Of course it could be 1001 other things, but I guess this is the first place to start. Check your linker settings and make sure that you are linking against the correct versions. I did something the other day and linked my release version again osgd.lib instead of osg.lib and my release version was crashing. Also if you post the stack trace it may help find the problem? -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Olivier Martinaud Sent: 13 May 2010 12:53 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] problem with osgUtil::IntersectVisitor and osg::LineSegment Hi, Thank you for your answer. Indeed, I installed both libraries, debug and release. I always compile my code in release mode (it compiles in debug mode but I don't know why the exe doesn't work then). I'll check on monday if both libraries are correctly and separately installed. Do you think it could cause the problem I have ? Cheers, Olivier -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27856#27856 ___ 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] Crash using collada files
Hi, I'm running into a crash when displaying collada files. The same collada files load cleanly in osgviewer, and other files load cleanly in my app. So this is probably a bug in my code, but still - maybe someone here has an idea what's wrong. The setup is very similar to osgscreencapture. Everything is being rendered into a pbuffer. The first symptom that something is wrong is this output when running in valgrind: View::init() Done DatabasePager::addLoadedDataToSceneGraph0.497ms, 0.21ms objects0 ==1271== ==1271== Conditional jump or move depends on uninitialised value(s) ==1271==at 0x7B19753: ComputeBound::vertex(osg::Vec3f const) (BoundingBox:149) ==1271==by 0x7B18401: ComputeBound::drawArrays(unsigned int, int, int) (Drawable.cpp:690) ==1271==by 0x7BBD5F1: osg::DrawArrayLengths::accept(osg::PrimitiveFunctor) const (PrimitiveSet.cpp:91) ==1271==by 0x7B2EFE4: osg::Geometry::accept(osg::PrimitiveFunctor) const (Geometry.cpp:2241) ==1271==by 0x7B123C9: osg::Drawable::computeBound() const (Drawable.cpp:773) ==1271==by 0x7B2B0BE: osg::Geode::computeBound() const (Drawable:203) ==1271==by 0x7B68871: osg::Group::computeBound() const (Node:334) ==1271==by 0x7C2B008: osg::Transform::computeBound() const (Transform.cpp:157) ==1271==by 0x7B68871: osg::Group::computeBound() const (Node:334) ==1271==by 0x7C2B008: osg::Transform::computeBound() const (Transform.cpp:157) ==1271==by 0x7B68871: osg::Group::computeBound() const (Node:334) ==1271==by 0x7C2B008: osg::Transform::computeBound() const (Transform.cpp:157) ==1271==by 0x7B68871: osg::Group::computeBound() const (Node:334) ==1271==by 0x7B68871: osg::Group::computeBound() const (Node:334) ==1271==by 0x8B76661: osgViewer::ViewerBase::renderingTraversals() (Node:334) ==1271==by 0x8B74B92: osgViewer::ViewerBase::frame(double) (ViewerBase.cpp:609) ==1271==by 0x7A0BE44: avg::OSGNode::preRender() (in /opt/data/devel/Archimedes/alib/libavg_plugins/OSG_runs/plugin/osgnode.so) ==1271==by 0x48A86A9: avg::DivNode::preRender() (DivNode.cpp:227) ==1271==by 0x48A86A9: avg::DivNode::preRender() (DivNode.cpp:227) ==1271==by 0x48D5AD3: avg::Canvas::render(avg::Pointint, bool, avg::ProfilingZone) (Canvas.cpp:239) ==1271==by 0x48D9969: avg::MainCanvas::render() (MainCanvas.cpp:77) ==1271==by 0x48D50DF: avg::Canvas::doFrame(bool) (Canvas.cpp:147) ==1271==by 0x48B6484: avg::Player::doFrame(bool) (Player.cpp:914) ==1271==by 0x48BDAF7: avg::Player::play() (Player.cpp:433) ==1271==by 0x47EBF67: boost::python::objects::caller_py_function_implboost::python::detail::callervoid (avg::Player::*)(), boost::python::default_call_policies, boost::mpl::vector2void, avg::Player ::operator()(_object*, _object*) (invoke.hpp:94) Thanks for any help, Uli -- Ulrich von Zadow Software Engineer (Dipl. Inf.) Exhibit Development Tel +49 (0)30 / 2000 577 12 Fax +49 (0)30 / 2000 577 20 Skype: uzadow Archimedes Solutions GmbH Saarbrücker Str. 24 10405 Berlin www.archimedes-solutions.com Geschäftsführung: W. Rien | J. Schmidtsiefen | S. Spenling Amtsgericht: Berlin Charlottenburg HR Nr.: 107563 B UST-ID Nr.: DE-253.771.793 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewer::GraphicsWindowCarbon and wxWidgets conflict
Hi Stephan, yes, this would help in case a window is open having an OpenGL context. But in the Carbon version OSG also takes all quit events in case no window or other windows are open. Cheers, Hartwig -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27866#27866 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash using collada files
Hi Uli, On 14/05/10 2:06 , Ulrich von Zadow wrote: I'm running into a crash when displaying collada files. The same collada files load cleanly in osgviewer, and other files load cleanly in my app. So this is probably a bug in my code, but still - maybe someone here has an idea what's wrong. The setup is very similar to osgscreencapture. Everything is being rendered into a pbuffer. The first symptom that something is wrong is this output when running in valgrind: View::init() Done DatabasePager::addLoadedDataToSceneGraph0.497ms, 0.21ms objects0 ==1271== ==1271== Conditional jump or move depends on uninitialised value(s) ==1271==at 0x7B19753: ComputeBound::vertex(osg::Vec3f const) (BoundingBox:149) ==1271==by 0x7B18401: ComputeBound::drawArrays(unsigned int, int, int) (Drawable.cpp:690) What I'd try first is to save the scenegraph to a file and check that for anything out of the ordinary. Are you able to get a stack trace from the crash? Is it in the same spot that valgrind is reporting? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Does OSG have a vertex-reducer?
Hey, Thanks a lot, guys! It was exactly what I was looking for. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27870#27870 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
