Jump to content

[SOLVED] Angle mismatch in modelview and projection matrix


photo

Recommended Posts

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.

 

post-1459-0-57555800-1437984833_thumb.png

 

 

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

post-1459-0-17163800-1437985167_thumb.png

 

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

post-1459-0-44969700-1437985186_thumb.png

 

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

Link to comment

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

Link to comment

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..

 

post-1459-0-19890600-1438072108_thumb.png

 

Kind regards,

Renato

Link to comment

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

Link to comment

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?

Link to comment
×
×
  • Create New...