[SOLVED] Angle mismatch in modelview and projection matrix

[renato.semadeni]

Hi there,

 

As you can see on the image we are realizing a multiscreen application. The application has different frustums since the person doesn't sit in the middle of the screen, but with an offset to the left or the right.

 

We are using a derivative of the AppWall implementation with some additional functions.

 

We observe now a strange behavior: The frustums we are calculating for all 3 screens and applying them as the projection matrix. Then for the side screens, we additionally rotate the camera due to the screens physical setup and pass them as the Modelview matrix.

 

 

 

Now when we use the same rotation angle for the modelview matrix as for the frustum calculation, we get the following offset:

 

But if we use a smaller rotation angle, we get a better result.

 

Do we miss something with the modelview and projection matrix. Because I'm quite sure, the rotation angle should be the same as we need for the calculation of the frustums.

 

Thanks for any help,

Renato

[renato.semadeni]

Hi there

 

Why is the difference between the correct angle (which results in wrong mutliscreen alignment) and the corrected one (which results in a proper alignment) exactly the ratio between a 16:10 resolution and the used resolution? Does Unigine render always a 16:10 image and the rescale it?

 

Do you have a proposition how to arrive an asymetric frustum in a multichannel setup for arbitruary resolutions?

 

Thanks in advance,

Renato

[silent]

Hi Renato,

 

I'm not sure, but maybe you forgot to multiply the projection matrix by window aspect ratio (https://developer.unigine.com/forum/topic/2909-solved-camera-comparison-3dsmax-unigine-differences/)?

 

Thanks!

[renato.semadeni]

Hi Silent

 

Thanks a lot for your answer. Even if I multiply the projection matrix with the window aspect ratio, the screens still missmatch and now I'm loosing other stuff..

 

 

Kind regards,

Renato

[renato.semadeni]

I try to show you how we are calculating the different frustums and its rotations:

// Contains infos per display, especially the rotation and the frustums
struct Display {
	int				enabled;		// enabled flag
	int				viewport_mask;		// viewport mask
	int				reflection_mask;	// reflection mask
	Unigine::mat4			projection;		// projection matrix
	Unigine::dmat4			modelview;		// modelview matrix
	Unigine::String			materials;		// post materials
	Unigine::GuiPtr			gui;			// user interface
	Unigine::dmat4			rotation;		// rotation matrix
	std::map<int, Unigine::mat4>	frustums;	// frustum matrix
	int				offset;		//  TD - screen position offset
};


// for all three windows we create an asymmetric frustum, based on geometric calculation
fmap.insert(std::pair<int, Unigine::mat4>(i, Unigine::frustum(l,r,b,t,n,f));


// Later look for the current frustum and assign it to all screens
for (int i = 1; i < wall_width; i++) {
	setProjection(i, 0, displays[i].frustums.find(curFrustum)->second);
	setReflectionMask(i, 0, reflM);
	setViewportMask(i, 0, viewM);
	setPostMaterials(i, 0, mat);
	setModelview(i, 0, displays[i].rotation * mw);
}

Cheers,

Renato

[silent]

Hi Renato,

Could you please provide a small test scene with these 3 screen setup to check it on our stand?

 

Thanks!

[renato.semadeni]

Hi Silent

 

I have a small test scenery together. Can you give me a link to your upload server?

 

Kind regards,

Renato

[esger.abbink_]

Haven't checked your code and can't remember the exact details but unigine uses internally a 1:1 aspect ratio and only changes to your window aspect as one of the last steps.

 

so if you have a problem that matches the discrepancy between 1:1 and 16:10 the above could very well cause your issue (which I think is what silent is hinting at as well)

 

I haven't got time at the moment to check what we did exactly, but the correction is fairly simple. Maybe/possibly your aspect ratio correction/multiplication is not quite correct or in the right place?

[unclebob]

Thanks for the sample, Renato!

 

We'll have a look and see what we can do with that.