Hi there.

I'm running MSVC2010, and I recently upgraded my eigen to 3.0.5. (I think from 3.0.4)

It's basic stufff, handling 3d transforms for OpenGL.

The new Eigen version is now tripping an assert in some code calculating
the inverse of a projection matrix. This code ran perfectly until now.

The assert is PACKET_ACCESS_REQUIRES_TO_HAVE_INNER_STRIDE_FIXED_TO_1. As far as I can tell,
inner stride of the Map is zero (the default?) and the assert wants one.

My code is simple:
==============================================
m_projection(0,0) = cotangent / aspect;
m_projection(1,1) = cotangent;
m_projection(2,2) = -(zFar + zNear) / deltaZ;
m_projection(2,3) = -2 * zNear * zFar / deltaZ;

m_projectionInv = m_projection.inverse(); // *** Asserts here
==============================================
where m_projection and projectionInv are both Eigen::Projective3d.

How do I control the compile-time stride values in the MapBase classes being used here?
Is there some new compile-time switch I have to set?

Thanks, in advance.

Ross.

hm that's rather strange, i'll look at it. In the meantime I think you can do:

m_projectionInv = m_projection.matrix().inverse()

I cannot reproduce with gcc...

Could you try the following self-contained example:

#include <Eigen/Dense>
using namespace Eigen;
int main()
{
double cotangent, aspect, zFar, zNear, deltaZ;
Eigen::Projective3d m_projection, m_projectionInv;
m_projection(0,0) = cotangent / aspect;
m_projection(1,1) = cotangent;
m_projection(2,2) = -(zFar + zNear) / deltaZ;
m_projection(2,3) = -2 * zNear * zFar / deltaZ;

m_projectionInv = m_projection.inverse();
}

maybe the problem is elsewhere.

Thanks ggael.

Hmm. Your first suggestion failed to build with:

c:\ross\harper\dev\sdk\eigen\eigen\src/LU/Inverse.h(300): error C2039: 'ColsAtCompileTime' : is not a member of 'Eigen::Transform<_Scalar,_Dim,_Mode>'

I'm thinking that has to be clue.

While the second isolated example compiles and runs just fine (with just some auto' initialisations to sidestep runtime
checks in my default debug build).

So clearly it 'should' work. I'll chase some more in the morning, when I'll have access to the original version of Eigen
used with this code.

[BTW: I used the original projects visual studio property sheet for both tests, which defines:
EIGEN_DONT_VECTORIZE
EIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT]

I'll update when I find something.

Ross.

Well. This appears to be a compiler problem with Visual Studio Express.

On my office machine (Visual Studio 10 - SP1 I think, on 64-bit Windows-7) everything compiles and runs OK.

On my home machine, with VS 10 Express edition on 32-Vista (yeah, I know), it fails every time.

I guess it's NOT the same compiler (as I had been assuming). Methinks Eigen is pushing it's abilities.

Ross.

Yes that's what I'm thinking too. There is absolutely no reason that the code in eigen\src/LU/Inverse.h be instantiated with a Transform<> object! That's a no sense. It is quite scary that VS10 express has such a bug.