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::vector<int,std::allocator<int> >::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 429 C++
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!000000007678f33d()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!0000000076e82ca1()
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 (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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
