SetMatrix, SetViewport and SetProjection2d

Wingnut

Well-known member
3rd Party Module Dev
Tutorial Author
Joined
Jan 2, 2020
Messages
1,393
In Cerberus what is the difference between SetMatrix, SetViewport and SetProjection2d?

I mean you can zoom up and make the resolution low or high using SetViewport but also using the matrix you can zoom and unzoom?
Also what does SetProejction2D actually do its hard to understand for me. Is it like a Orthocam?

TIA!
 
This is also some confusing stuff for me as well and whenever I am working on something related I have to read myself into it again. So no guarantee for accuracy at all. ;-)

First of all, even if mojo2 is for 2d graphics it sits on OpenGL which is made for 3d graphics rendering, so while it kind of only uses a fraction of the capabilities it has to deal with all the stuff that is related to 3d math.
I would divide this into two things: One is the stuff that are just representations of points in space and all the fancy math you need to deal with their transformations ... and the other thing is how those things are transferred to the two dimensional screen.
If you want to get into the first thing, which includes SetMatrix (Internally seen as ModelMatrix and ViewMatrix) and SetProjection2d (ProjectionMatrix), this chapter from LearnOpenGL is a great read. All those matrices are multiplied at the end to get the ModelViewProjection matrix, so you could get the same result by completely different changes to each of the input matrices.
The other thing regarding mojo2 is the actual screen, where you define where the data given by the ModelViewProjection matrix is displayed. With SetScissors you specify which part of the screen is used for displaying and with SetViewport you specify where and how large the data is shown there.
While all the matrices and the resulting ModelViewProjection matrix is handled by mojo2 itself, scissor and viewport are nearly one to one implementations of the GL commands.

Also what does SetProejction2D actually do its hard to understand for me. Is it like a Orthocam?
Yes, I think so not being familar with the term Orthocam. It is a orthogonal projection of the 3d coordinates. Just like a view from an infinitely far away viewpoint while using a teleobjective to zoom in on the object.
 
Thanks a lot for that nice explanation this is actually what I felt to be true but i wasn't sure (so now we're two (y)
I think this is correct when I hear it as you describe it and from my experience as well.

In some code on other platforms I used viewport and no matrix as I wanted to see If I really needed it first.
On other platforms I have preferred matrix and I set the viewport to be native fullscreen and I let the matrix do the job instead.

But I think there is a subtle thing here; what if you set a low resolution using the Viewport and then start rotating using the matrix, it will show coarse pixels being rotated. On the other hand when you use the matrix to set a low resolution and then start rotating, you will instead get a smooth rotation in the native resolution, containing those chunky pixels.

Both of these styles are very interesting but I'm not sure if this always true.
I guess I have to try and see. Hopefully my brain will allow this to happen soon :cool:

(Sorry I meant OrthographicCamera)
 
I did a quick test and I think I'm wrong regarding that last statement, it seems to be smooth and ultra hi res either way by the looks of it.
Whenever you want that lo res look you will need to use a offscreen buffer I guess.

So I guess it's all math that gets combined and it seems to behave like this on every platform.
 
But I think there is a subtle thing here; what if you set a low resolution using the Viewport and then start rotating using the matrix, it will show coarse pixels being rotated. On the other hand when you use the matrix to set a low resolution and then start rotating, you will instead get a smooth rotation in the native resolution, containing those chunky pixels.
My first guess here is that you are talking about rendering to an image and scaling this afterwards. In your second scenario the pixel effect comes from the texture itself given that you use nearest filtering (no filter in mojo2). In the first example, if you are rendering to a texture you have the pixelated effect because you are rendering to concrete/limited pixels and than scaling this image up.
 
Exactly that's the classic way to do it and I don't think there's another way around it.

I start to understand this 3d math a bit actually. Cerberus is a great teaching aid.
 
Back
Top Bottom