Camera has wrong zoom levels when explicitly set by Scene Actuator #31357

New Issue

Leonard Ritter · 2012-05-07T21:29:23+02:00

Leonard Ritter commented

2012-05-07 21:29:23 +02:00

Category: Logic

%%%Problem:

When a Scene actuator requests "Set Camera" explicitly, the view is changed to the new camera, but the zoom level depends on the previously active view: A.) If an orthogonal view has been previously selected, the zoom factor is too large - incorrect. B.) If the camera is the active view (Numpad 0), and the view is zoomed out, so that the passepartout is visible, the zoom factor is, again, too large, and restricted to the small view - incorrect. C.) If the camera is the active view, and the view is zoomed in, so that the passepartout is not visible at all, the zoom factor is 100% correct.

Expectation:

The zoom should always behave as in case C. I can see why case B is a feature, since that allows to see beyond the camera even when it is fully automated, but case A is terribly annoying. I always have to switch to the correct camera first and scroll in before I can run the game and view it the way it's supposed to be viewed.

To reproduce, perform following steps on attached example:

For all cases, perform following step first:

load camzoombug.blend. You can see that the cube is configured to set the camera explicitly. An isometric, orthogonal view is visible by default.

case A:

Press P to start the game engine.
Note that the camera is properly assigned, but the cube appears to occupy only ~1/5th of the screen. This is incorrect.

case B:

Press Numpad 0 to make the camera the active view. Using the mousewheel, scroll out until the passepartout is boldly visible.
Press P to start the game engine.
Note that the passepartout is still visible just as set up by you, even though the camera has been explicitly set again by the actuator.

case C:

Press Numpad 0. The camera is made the current view. It appears slightly zoomed in, so that the passepartout is not visible.
Press P to start the game engine.
Note that the camera is properly assigned, and the cube occupies about 1/3rd of the screen. This is correct.
%%%

**Category**: Logic %%%Problem: When a Scene actuator requests "Set Camera" explicitly, the view is changed to the new camera, but the zoom level depends on the previously active view: A.) If an orthogonal view has been previously selected, the zoom factor is too large - incorrect. B.) If the camera is the active view (Numpad 0), and the view is zoomed out, so that the passepartout is visible, the zoom factor is, again, too large, and restricted to the small view - incorrect. C.) If the camera is the active view, and the view is zoomed in, so that the passepartout is not visible at all, the zoom factor is 100% correct. Expectation: The zoom should always behave as in case C. I can see why case B is a feature, since that allows to see beyond the camera even when it is fully automated, but case A is terribly annoying. I always have to switch to the correct camera first and scroll in before I can run the game and view it the way it's supposed to be viewed. To reproduce, perform following steps on attached example: For all cases, perform following step first: 1. load camzoombug.blend. You can see that the cube is configured to set the camera explicitly. An isometric, orthogonal view is visible by default. case A: 1. Press P to start the game engine. 2. Note that the camera is properly assigned, but the cube appears to occupy only ~1/5th of the screen. This is incorrect. case B: 1. Press Numpad 0 to make the camera the active view. Using the mousewheel, scroll out until the passepartout is boldly visible. 2. Press P to start the game engine. 3. Note that the passepartout is still visible just as set up by you, even though the camera has been explicitly set again by the actuator. case C: 1. Press Numpad 0. The camera is made the current view. It appears slightly zoomed in, so that the passepartout is not visible. 2. Press P to start the game engine. 3. Note that the camera is properly assigned, and the cube occupies about 1/3rd of the screen. This is correct. %%%

Leonard Ritter commented

2012-05-07 21:29:23 +02:00

Changed status to: 'Open'

Leonard Ritter commented

2012-05-07 21:32:42 +02:00

%%%Encountered with Blender 2.63 for Linux-64, running on Ubuntu 12.04.%%%

Sergey Sharybin commented

2012-05-08 09:53:03 +02:00

%%%Michael, can you please look into this?%%%

Thomas Dinges commented

2012-06-11 12:10:37 +02:00

%%%Moved from Blender 2.6 Bug Tracker to Game Engine%%%

Dalai Felinto commented

2012-07-03 04:53:32 +02:00

%%%Hi Leonard, I'm not so sure this is a bug. The only thing missing in A is the passpartout.
As you can see in the new attached file - camzoombug_2.blend - the camera lens is correct in A, B or C.%%%

%%%Hi Leonard, I'm not so sure this is a bug. The only thing missing in A is the passpartout. As you can see in the new attached file - camzoombug_2.blend - the camera lens is correct in A, B or C.%%%

Leonard Ritter commented

2012-07-03 12:57:19 +02:00

%%%Your example is slightly different to mine. What I am bugged about is the different ways in which the camera is displayed when I enter the game at first. Unlike your example, camzoombug.blend sets the camera right away - but, as noted in case A, if the current 3D view is not set to the active camera, then not only is the passepartout missing (which is unnerving enough), the screen is also not to set to a size that makes sense.

This is incredibly unnerving in day to day use: whenever i make changes to a scene and i want to test it, i have to first manually select any camera before running the game, or else the zoom levels will be all wrong, even though I have programmatically selected a camera, and it is clear that I want to see the entire picture in frame, clipped, and scaled to a size that fits the frame. -- so it's always, move around ortho view, edit, hit numpad 0 for cam, hit P, then hit numpad 0 again to go back to ortho view - i can never just edit and P, i always have to do this little numpad 0 thing inbetween or else the view is messed up.

I've attached screenshots to further illustrate the problem with my particular blend file:
during_editing.png: i'm editing my scene file - now before i test the scene i have to first hit numpad 0 to select any camera view
before_running.png: this is what it has to look like so i get a correct view when starting the game, so it looks like...
starting_from_camera.png: ... <- this; when i forget to select a camera view and stay in ortho, it looks like...
starting_from_ortho.png: ... <- THIS, which is terrible and doesn't help me at all; the zoom and fov levels are wrong.

the camzoombug.blend demonstrates exactly the same problem. it's not just the missing passepartout (which also sucks!) - it's also the wrong zoom level.

(Off-the-record: besides this camera bug, there are other things that make the edit-and-test cycle clumsy, such as the game always showing the currently active layers across all scenes; so I often have to go back and forth between scenes to select the layers i want actually to be active at runtime; having the wrong layers activated breaks the game. Also, for the release, the correct start-up scene has to be activated on save, or else the game will start with the wrong scene. I kind of fix these issues with a python script that loads my game blendfile, fixes all the layers, selects the correct active scene, and then saves to a final blend file, but I wish it were easier to prepare a file for deployment, by e.g. specifying a start-up scene for the blend file, or marking a set of scene layers as the default set-up when doing a release run.)
%%%

%%%Your example is slightly different to mine. What I am bugged about is the different ways in which the camera is displayed when I enter the game at first. Unlike your example, camzoombug.blend sets the camera right away - but, as noted in case A, if the current 3D view is not set to the active camera, then not only is the passepartout missing (which is unnerving enough), the screen is also not to set to a size that makes sense. This is incredibly unnerving in day to day use: whenever i make changes to a scene and i want to test it, i have to first manually select any camera before running the game, or else the zoom levels will be all wrong, even though I have programmatically selected a camera, and it is clear that I want to see the entire picture in frame, clipped, and scaled to a size that fits the frame. -- so it's always, move around ortho view, edit, hit numpad 0 for cam, hit P, then hit numpad 0 again to go back to ortho view - i can never just edit and P, i always have to do this little numpad 0 thing inbetween or else the view is messed up. I've attached screenshots to further illustrate the problem with my particular blend file: during_editing.png: i'm editing my scene file - now before i test the scene i have to first hit numpad 0 to select _any_ camera view before_running.png: this is what it has to look like so i get a correct view when starting the game, so it looks like... starting_from_camera.png: ... <- this; when i forget to select a camera view and _stay_ in ortho, it looks like... starting_from_ortho.png: ... <- THIS, which is terrible and doesn't help me at all; the zoom and fov levels are wrong. the camzoombug.blend demonstrates exactly the same problem. it's not just the missing passepartout (which also sucks!) - it's also the wrong zoom level. (Off-the-record: besides this camera bug, there are other things that make the edit-and-test cycle clumsy, such as the game always showing the currently active layers across all scenes; so I often have to go back and forth between scenes to select the layers i want actually to be active at runtime; having the wrong layers activated breaks the game. Also, for the release, the correct start-up scene has to be activated on save, or else the game will start with the wrong scene. I kind of fix these issues with a python script that loads my game blendfile, fixes all the layers, selects the correct active scene, and then saves to a final blend file, but I wish it were easier to prepare a file for deployment, by e.g. specifying a start-up scene for the blend file, or marking a set of scene layers as the default set-up when doing a release run.) %%%

Dalai Felinto commented

2012-07-03 21:34:42 +02:00

%%%Have you considered to have a Screen if only a 3dvew on it, no menus whatsoever and with the layers (and camera) 'locked'?
So all you need to preview is [Ctrl + ->] + P. That's how I use to work. This Screen not only will have the correct layers but the correct camera and scene.
(and if you need to isolate layers for some editing in a different screen you can do it by clicking the 'chain' icon on the right of the layers before changing them)

That may solve most of your workflow problems (considering the off-the-record ones)

You can even use the 'Run' button by the Player panel to launch the blenderplayer instead (then you have always the screensize of the actual game).%%%

%%%Have you considered to have a Screen if only a 3dvew on it, no menus whatsoever and with the layers (and camera) 'locked'? So all you need to preview is [Ctrl + ->] + P. That's how I use to work. This Screen not only will have the correct layers but the correct camera and scene. (and if you need to isolate layers for some editing in a different screen you can do it by clicking the 'chain' icon on the right of the layers before changing them) That may solve most of your workflow problems (considering the off-the-record ones) You can even use the 'Run' button by the Player panel to launch the blenderplayer instead (then you have always the screensize of the actual game).%%%

Leonard Ritter commented

2012-07-06 14:02:30 +02:00

%%%Running the external player from within Blender somehow messes up all the paths within the blend file on Linux, so I can't do that. But yes, I use switching screens a lot, but it always struck me as kind of unwieldy. I'll give it another shot.%%%

blender-admin commented

2015-10-27 11:10:12 +01:00

This issue was referenced by 13a4bcd148

This issue was referenced by 13a4bcd148bd7a32af8af626f42f7793aca7b7fe

Porteries Tristan commented

2015-10-27 11:16:22 +01:00

Changed status from 'Open' to: 'Resolved'

Porteries Tristan closed this issue

2015-10-27 11:16:22 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Camera has wrong zoom levels when explicitly set by Scene Actuator #31357