Re: [osg-users] getting eye position / direction
Hi, this post is for those reading this thread wondering how i solved the issue. I solved it by creating the line segment intersectors in model coordinate space, transforming the starting/ending point using this matrix: Code: osg::Matrixd matrix; matrix.preMult(_masterCamera-getViewport()-computeWindowMatrix()); matrix.preMult(_masterCamera-getProjectionMatrix()); matrix.preMult(_masterCamera-getViewMatrix()); _renderMatrixInverse-invert(matrix); This way the lineSegmentIntersector gets initialized correctly and the intersections are computed well. The problem itself originated elsewhere - i was using the camera as the ROOT node for intersectionVisitor, which did not behave the way expected. I encountered another issue when using the camera as the root - the invisible parts of the scene got culled away (as expected for rendering), however, while computing reflected rays, this caused serious issues, as these rays did not hit the expected objects, because they 'were not there'. I had to use own matrix transformation for the primary rays and let all the rest compute in the model coordinate space, the scene being the root (without any other transformations). take care, Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47056#47056 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] making a copy of camera root node or whole scene graph
Hi guys, I solved the issue NOT using a osg::Camera at all. It caused a series of other fatal issues (culling away some geometry, that was then missing in reflections). anyone doing ray-tracing, do not use osg::Camera as a root of your scene for intersectionVisitor ! it will fail with secondary rays. take care, Andrey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47057#47057 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] default lighting
Hi,
just a guess - try global ambient intensity.
i'm using this code:
Code:
osg::LightModel *lightModel = collisionStateSet ?
dynamic_castosg::LightModel*
(collisionStateSet-getAttribute(osg::StateAttribute::LIGHTMODEL)) : NULL;
if (lightModel) {
globalAmbientIntensity = lightModel-getAmbientIntensity();
}
Cheers,
Andrey
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47058#47058
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building new website, assistance appreciated!
Hi Torben, On 13 April 2012 06:16, Torben Dannhauer tor...@dannhauer.info wrote: I have dedicated servers in a data center. If you need storage place for all the OSG packed files like releases, dependencies, additional files and others I can provide webspace with gigabytes of size and terabyte of traffic with FTP Upload (or any other protocaol you prefer) Just give me a note if I can help! Thanks for the offer. I have space on my Dreamhost account that should hopefully be sufficient for our needs so will continue with the current experiment with openscenegraph.com. If this looks viable we can keep it on Dreamhost otherwise I might well be looking for help. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building new website, assistance appreciated!
Hi Robert, that sounds good :) btw: the registration email of openscenegraph.com ist still not delivered to my Email server. Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47060#47060 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Dose anybody has other learing resources about osgOcean?
Hi, Kim, Thank your for your help. I will try to read the code myself. If I meet some problems that make me confused, I'll send massage to you for help. Regards, Han kcbale wrote: Hi Han, I'm the author of the code, if you can be more specific about what you want to know maybe I can help you. There isn't any documentation, only the example program to guide your way I'm afraid. Regards, Kim. On 6 April 2012 08:02, Han Wang () wrote: Hi, I find it difficult to learn the osgOcean by reading the source code only. In addition, the document of this code is not very specific. So, I need some other guidebook or some similar documents, which can help me to understand the osgOcean quickly(No special detailed). Thank you! Cheers, Han Wang -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46894#46894 (http://forum.openscenegraph.org/viewtopic.php?p=46894#46894) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47061#47061 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg_NormalMatrix calculated incorrectly
The weekend has been a total loss work-wise, so I didn't get too far with this, sorry. But I did back-date trunk to r13018, which was the last time oversimple3.cpp was modified, and the lines of code in your proposed change haven't been modified since then either. The example ran and lit correct at that svn revision. I also checked the eye coordinate light vector used in oversimple3 and I believe it's correct. Moving forward, please let me dig into this a little more and see if I can identify the svn revision that broke lighting in this example. Thanks. -Paul On 4/13/2012 8:53 AM, Paul Martz wrote: Something odd is going on here, as this works correctly in 3.0.1. I don't have time to dig in to the math right now; maybe over the weekend... -Paul On 4/12/2012 10:22 PM, Roland Hill wrote: Hi, I believe osg_NormalMatrix may be being calculated incorrectly in the trunk version of OSG. At present, it is calculated as the inverse 3x3 of the modelview matrix, but should be the transpose inverse. The patch below appears to correct this. To test, try running osgsimplegl3 cow.osg. You will see the cow is mostly black until you spin it around a bit. After the patch is applied the cow appears fully lit all the time as expected. Cheers, Roland Index: src/osg/State.cpp === --- src/osg/State.cpp (revision 13060) +++ src/osg/State.cpp (working copy) @@ -1414,9 +1414,12 @@ Matrix matrix; matrix.invert(mv); - Matrix3 normalMatrix(matrix(0,0), matrix(1,0), matrix(2,0), - matrix(0,1), matrix(1,1), matrix(2,1), - matrix(0,2), matrix(1,2), matrix(2,2)); + Matrix3 normalMatrix(matrix(0,0), matrix(0,1), matrix(0,2), + matrix(1,0), matrix(1,1), matrix(1,2), + matrix(2,0), matrix(2,1), matrix(2,2)); _normalMatrixUniform-set(normalMatrix); } -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47039#47039 ___ 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_NormalMatrix calculated incorrectly
Hi Paul, Thanks for looking into this. At least I know that it can be replicated outside my environment! Cheers, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47064#47064 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] why display like this ?
tjq@jq-e13b5f0ddeed /cygdrive/d/DriversBackup/examples/osgAndroidExampleGLES1/jni $ ndk-build NDK_APPLICATION_MK=Application.mk Compile++ thumb : osgNativeLib = osgNativeLib.cpp /bin/sh: -Itype: No such file or directory /cygdrive/d/TDDOWNLOAD/android-ndk-r7b-windows/android-ndk-r7b/build/core/build-binary.mk:243: recipe for target `/cygdrive/d/DriversBackup/examples/osgAndroidExampleGLES1/obj/local/armeabi/objs/osgNativeLib/osgNativeLib.o' failed make: *** [/cygdrive/d/DriversBackup/examples/osgAndroidExampleGLES1/obj/local/armeabi/objs/osgNativeLib/osgNativeLib.o] Error 1 how to solve this error?___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg_NormalMatrix calculated incorrectly
Hi Roland -- I dug in quite a bit further this evening and have narrowed down the issue only a little. The issue seems to be related to r13050, r13059, and the latest r13060, so I've copied their authors on this post to solicit their feedback on this thread and help track down what the root cause and best resolution might be. I'd spend more time on it, but am underwater on another project right now, and it's getting late here in the US. Here's what I know: 13018 lighting is correct. 13040 lighting is correct. 13049 lighting is correct. 13050 crashes (see call stack). 13058 crashes (see call stack). 13059 crashes (see call stack). 13060 lighting is incorrect. Everything was fine up until 13050, which caused a crash. The crash is fixed in 13060, but at that point lighting is no longer correct. 13059 is related to uniforms, but I didn't try to wedge the r13060 crash fix in before r13059, so I don't know how much it relates to the issue at hand. The crash is a vector out of range issue that occurs while querying uniform locations, apparently attempting to insert the uniform location into the first element of a vector that has size 0. Here's the call stack: msvcp100d.dll!std::_Debug_message(const wchar_t * message, const wchar_t * file, unsigned int line) Line 15 C++ osg92-osgd.dll!std::vectorint,std::allocatorint ::operator[](unsigned __int64 _Pos) Line 933 C++ osg92-osgd.dll!osg::Program::PerContextProgram::linkProgram(osg::State state) Line 784 + 0xf bytes C++ osg92-osgd.dll!osg::Program::compileGLObjects(osg::State state) Line 233 C++ osg92-osgd.dll!osg::StateSet::compileGLObjects(osg::State state) Line 1335 C++ osg92-osgUtild.dll!osgUtil::GLObjectsVisitor::apply(osg::StateSet stateset) Line 114 C++ osg92-osgUtild.dll!osgUtil::GLObjectsVisitor::apply(osg::Node node) Line 42 C++ osg92-osgd.dll!osg::NodeVisitor::apply(osg::Group node) Line 87 C++ osg92-osgd.dll!osg::Group::accept(osg::NodeVisitor nv) Line 38 + 0x60 bytes C++ osg92-osgViewerd.dll!osgViewer::Renderer::compile() Line 541 + 0x33 bytes C++ osg92-osgViewerd.dll!osgViewer::Renderer::draw() Line 671 C++ osg92-osgViewerd.dll!osgViewer::Renderer::operator()(osg::GraphicsContext * context) Line 894 C++ osg92-osgd.dll!osg::GraphicsContext::runOperations() Line 778 C++ osg92-osgd.dll!osg::RunOperations::operator()(osg::GraphicsContext * context) Line 138 C++ osg92-osgd.dll!osg::GraphicsOperation::operator()(osg::Object * object) Line 54 C++ osg92-osgd.dll!osg::OperationThread::run() Line 429C++ osg92-osgd.dll!osg::GraphicsThread::run() Line 41 C++ ot12-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void * data) Line 113 + 0x10 bytes C++ msvcr100d.dll!_callthreadstartex() Line 314 + 0x17 bytes C msvcr100d.dll!_threadstartex(void * ptd) Line 297 C kernel32.dll!7678f33d() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!76e82ca1() I've been doing this work on Win7 built with VS2010 64bit. I'm using OSG built for GL3, but I understand osgsimplegl3 also runs when OSG is built for GL2, so the lighting issue should be reproducible with a typical OSG build. The command line I've been using for testing is: osgsimplegl3 cow.osg That's about all the info I was able to dig up. Hopefully David, Ulrich, and Martin can contribute to a resolution? -Paul On 4/15/2012 5:51 PM, Paul Martz wrote: The weekend has been a total loss work-wise, so I didn't get too far with this, sorry. But I did back-date trunk to r13018, which was the last time oversimple3.cpp was modified, and the lines of code in your proposed change haven't been modified since then either. The example ran and lit correct at that svn revision. I also checked the eye coordinate light vector used in oversimple3 and I believe it's correct. Moving forward, please let me dig into this a little more and see if I can identify the svn revision that broke lighting in this example. Thanks. -Paul On 4/13/2012 8:53 AM, Paul Martz wrote: Something odd is going on here, as this works correctly in 3.0.1. I don't have time to dig in to the math right now; maybe over the weekend... -Paul On 4/12/2012 10:22 PM, Roland Hill wrote: Hi, I believe osg_NormalMatrix may be being calculated incorrectly in the trunk version of OSG. At present, it is calculated as the inverse 3x3 of the modelview matrix, but should be the transpose inverse. The patch below appears to correct this. To test, try running osgsimplegl3 cow.osg. You will see the cow is mostly black until you spin it around a bit. After the patch is applied the cow appears fully lit all the time as expected. Cheers, Roland Index: src/osg/State.cpp === --- src/osg/State.cpp
Re: [osg-users] osg_NormalMatrix calculated incorrectly
Hi Paul, Just a bit more information from me. I'm using Ubuntu 11.04 64 bit on two machines (1 Nividia 1 ATI). I also compiled for Win64 and got the same result. I'm building OSG for GL2 - the only deviation from a 'standard' build is that I disable Display Lists on both machines otherwise the ATI doesn't show any geometry (see http://forum.openscenegraph.org/viewtopic.php?t=10145). Cheers, Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47067#47067 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
