Allow multiple cameras to be active at once, properly send camera id when communicating

Feature requests
#1

1 The default behavior of cameras is for the most recent camera to be active only. All other cameras will not send messages to the render script. This is interesting, but not ideal, especially for split screen situations. It would be better for us to be able to have many cameras sending information at once, and then allow us to select which camera’s data in the render script to use based on the ID.

2 Currently cameras are not sending their ID properly along with their messages.The message.id from camera messages is always hash: [game] no matter the id of the parent GO.

3 A method of more direct access to camera data without waiting on message passing.

1 Like
#2

I agree with the complaints you have about the camera. As has been mentioned elsewhere on the forum the camera component didn’t get the love it deserved when it was created a long time ago. We should at some point look at the known issues with the camera and try to fix them.

In the meantime I gave it a shot and implemented a camera example using a game object instead. It works in much the same way as the camera component, but it’s implemented as a game object with a script. Add the camera.go to a collection and possibly also child it to a game object and let the script work its magic. The script does what the camera component does, with the difference that the view and projection matrix are created in Lua using the vmath functions. The script sends the set_view_projection message with the same keys as the normal camera component, with the difference that the id corresponds to the id of the camera game object.

In the same example I also added a custom render script that splits the screen in as many slices as there are active cameras.

See it in action here: http://britzl.github.io/publicexamples/camera/index.html

1 Like
#3

What do you mean by this? Having a camera module with functions to get active cameras, views and projections?

#4

I suppose you want to have access to camera data outside of the render script? Do you have some usecases for this?

#5

This is super useful!

My concern with 3 was more that from other people it seems apparent that camera data can be laggy if it’s not attached directly to a game object that is in movement. There may be situations where you want a camera, or GO simulating a camera to be relative to a GO, but not have its transforms actually modified by it.

#6

Getting position of the camera is possible without message passing game with go.get_position, or am I misunderstanding the use case?

#7

I mean the view / projection information passed to the render script. I think that using GO based cameras for sending the raw messages to the render script is enough. But I’m not sure as I’m partially going off an assumption of what was causing lag without directly parenting. If new position is set and message is sent at the same time that may be all that’s needed to avoid lag even when not directly parenting for transforms.