Confuse about what beginCamera() and endCamera() does

Beginner in processing and want to use camera function but unable to understand the use of beginCamera() and endCamera(). Can anybody give more information as the reference is also quite unclear?

Hi! I read the reference but it does sound very confusing even though I have basic understanding of transform matrices.

Basically in the rendering pipeline, you have 2 ways to move an object - either you move the model itself or move the camera. In this case, operations between begin/endCamera affect the camera matrix (camera position/rotation). But in the end, they are the same thing because all the matrices are multiplied to generate a single matrix. Nevertheless, the order is quite important, just like translate then rotate is different from rotate then translate.

And don’t worry if you don’t understand it - as the reference says, it’s not needed for most users.

If you want to do more “intuitive” operations on the camera, check out peasycam which supports mouse interaction and offers functions like lookAt a target point.


Hi @micuat, So what I understood is that beginCamera() and endCamera() are only there to help make code look clean as we perform translate function on an object or on-camera both are same though. So it actually helps to classify whether the operation is done on camera or object. Have I understood it correctly?

I think that’s the high level explanation. Note that it seems that the transform happened in begin/endCamera will be carried on to the next frame, so you need to initialize it every time with camera (if you want) - but the “regular” operation on the model matrix (translate / rotate etc) will be refreshed every frame.

But if you really want to work with camera in depth I’d recommend using peasycam above because it has better abstraction being object oriented - begin/endCamera is basically just a wrapper for “low level” opengl I guess, and again, you don’t really have to understand this for making amazing visuals :slight_smile:

Hi, @micuat. I see that beginCamera() is something that is not supported by p5.js right now. Is it something yet to be implemented as I suppose it can provide more control to users over the camera matrix. Is this could be a feature request what the community requires?

your questions are really spot on! A short answer is, processing and p5.js are different and it has to be discussed on github whether they implement it or not.

As written on the statement,

p5.js draws inspiration, wisdom, and guidance from its precursor Processing. However, it is a new interpretation, not an emulation or port. We don’t aim to match Processing’s set of functionality exactly, allowing ourselves space to deviate and grow in the context of the web.

basically you can think that processing and p5.js are two different things. They are not trying to match the exact same set of functions/APIs, and here comes another statement

p5.js will not add any new features except those that increase access.

so, it can be discussed if begin/endShape should be implemented or not, but the focus will be accessibility and bug fix (it seems once it was mentioned in the repository, though).

Regarding these points, my honest opinion is that I don’t care, and perhaps it may be even “misleading” to add these functions (but anyone can disagree, of course). I don’t know if it was clear in my previous posts, but these functions are from low-level opengl operations, and not the best way to abstract the camera model. Like peasycam/p5.Easycam, it is recommended to use higher level abstraction to manage a camera instead of using opengl camera matrix, simply because it’s confusing. A camera matrix is just a matrix of 16 values and does not have information on what rotation/translation have happened or what the camera is looking at. What I mean by abstraction is, API that allows you to set, for example, what the camera is looking at or around which object the camera is orbiting, etc, and the library will calculate the matrix for you. It’s not about competency of the programmer, but better abstraction makes less bugs and often you can come up with more interesting ideas.