Viewports need to be linkable to DL cameras

[Andy Broomell 1,026]

One of the main issues with RW Cameras: currently there is no way to link a viewport to a Design Layer camera.

 

WHAT CURRENTLY HAPPENS:

You place a RW camera on a design layer and adjust it to the preferred POV. If you have the camera Activated when you create a Sheet Layer viewport, the camera is removed from the Design Layer and becomes embedded in the new viewport. If you don’t have the camera Activated, the RW Camera remains on the Design Layer and the viewport is created with the same POV (but with no embedded camera).

 

IN EITHER CASE, the viewport’s POV is never linked to a camera on the Design Layer. This is currently impossible.

 

 

Examples of why this doesn’t work in actual workflows:

 

SCENARIO 1: MULTIPLE VIEWPORTS WITH SAME POV

Let’s say you have a set design and you create a viewport to render the design. You then duplicate this viewport 15 more times to show different design variations via class visibilities and class overrides. Perhaps each viewport shows different textures or furniture options or lighting. Or perhaps it's a theatrical play with different scenes.

 

Then for whatever reason the POV for these renders needs to change (which is not uncommon). There is no easy way to change the POV once and have all 16 viewports match. The only way to do this currently is very manual: First you adjust the POV for one viewport, then you move all of the existing viewports off to side so that you can duplicate this viewport 15 times like you did before and place each one where it goes, then you re-apply all of the class overrides by using the eyedropper tool and sampling from the old viewports, then you delete the old viewports, then you update all the new ones and hope you didn't mess something up. (I should note that all my rendering viewports are on one sheet layer in my workflow).

 

This is a VERY tedious process, and especially annoying when the POV keeps on changing.

 

 

THE PROPOSED SOLUTION:

You place a RW camera on a Design Layer and adjust it to the preferred POV. When you create a viewport there should be the following options:

1. Leave camera on the Design Layer and LINK the viewport’s POV to this camera.
2. Leave camera on the Design Layer and create a duplicate camera to be embedded into the viewport.
3. Embed existing camera in the viewport (just like the current functionality).

 

The key here is option 1. This leaves the camera right where it is in the Design Layer, and would allow you to have multiple viewports linked to this one camera. In the scenario above, when you want to change the POV for all of your renderings, you simply move the camera’s position in the Design Layer and then update all of your existing viewports. Done.

 

 

SCENARIO 2: THE ENTIRE SET CHANGES POSITION.

Let’s say you have a design for an outdoor music concert stage and you’ve set up 8 renderings showing the stage from different points of view in the audience. Now for whatever reason the entire stage is changing position on the site and needs to rotate to the left. You need the renderings to following along with the new position. While you're not completely screwed, the current way of dealing with a rotation like this is quite laborious (which I won’t type out here). It’s possible, but realistically takes about 20 minutes to change all the viewports and make sure you haven’t messed anything up.

 

With the proposed functionality, since the cameras still live on the Design Layer, you'd simply rotate the camaras along with the other geometry, then update your viewports. Nice and simple.

 

 

SCENARIO 3: CAMERA PLOT

In general it would just be nice to be able see the points of view for your renderings while working in a design layer. Say for example you’re creating a camera plot for a tv show and want to see the camera positions for all the shots simultaneously, and you want to be able to move them around and have the linked viewports adjust accordingly. This would be possible with this new functionality: what you see in your Design Layers will always match what you get in your Sheet Layers.

 

 

(All of the above scenarios have arisen for me in the last few months, and each time I quickly realize the shortcomings of the camera tool.)

 

 

 

 

ADDITIONAL CONSIDERATIONS:

• The OIP for a viewport would indicate that the viewport is linked to a Design Layer camera, and it would display the camera name. There would be a button for a pop-up that would allow you to choose a different camera to link the viewport to. There would also be a button to unlink the viewport from the DL camera (leaving you with the same POV but no longer connected to anything). Existing viewports that are currently unlinked should be linkable to an existing camera via the viewport's OIP.

 

• If you double click a viewport with a linked camera and choose Edit Camera, there would be a pop-up warning you that the viewport's camera is a Design Layer camera, and adjusting it will also affect other viewports linked to the same camera. There would be a secondary option to “create a duplicate camera" so that the changes you make only apply to the one viewport, leaving the original camera intact.

 

• The OIP for a DL Camera with linked viewports would indicate what viewports are linked to it. This dialogue box would list all linked viewports, with an "unlink" button next to each one and a button to "Navigate to Viewport". When you try to adjust the camera, VW would warn you that the adjustments will affect all linked viewports. If you try to delete the camera, VW will warn you that all linked viewports will then become independent unlinked viewports.

 

• As suggested elsewhere on these forums, another functionality that would be nice (and tie in well to the above considerations) is the ability to lock the POSITION of a RW camera, but have it still be selectable. Currently if you Lock a camera, you can’t even activate it to see its POV. And there’s no other way to prevent accidental changes to the camera (especially because if you have the camera Active and use the flyover tool, you’re actually moving the camera, which often trips up novice users).

 

I know this was a long post, but I think this is one of the most important changes VW could make in order to improve the rendering workflow. It would also be immensely helpful in the TV/film/theatre industries.

 

I'd love to hear other people's thoughts!

 

Edited November 12, 2018 by Andy Broomell

[Kevin McAllister 1,147]

Yes please. For storyboard or scene by scene drawings I often have 10+ viewports with the same camera view. I wish the camera information for them could all be updated at once.

 

Kevin

[grant_PD 245]

Yes.  I believe I asked for this in another thread.  When one pulls down the "View" picker in the OIP of the viewport, all of your cameras should be listed there.  That way the camera is NOT embedded into the viewport, which I have never understood the reasoning for.  The camera remains an independent object, and you can activate it as Andy wants to show different layer/class overrides, you can move scenery around, you can move the camera around.  

 

[markdd 699]

Its surprising that Design Layer Camera views weren't implemented from the moment we had the ability to embed cameras into Viewports. It seems such an intuitive thing to want to do. It's been wished for for a long time now but never as well articulated as Andy has above.

 

As a stopgap the "Other" check box in the viewports section of the Eyedropper tool will copy a camera view from one viewport to another, but it also brings some of the Advanced properties with it so you would need to be careful when using it.. 

[line-weight 727]

I've just come to this after adding to a thread I started a year and a bit ago, where I expressed similar frustrations but not in such a clear way @Andy Broomell has done in his OP above. Pretty much completely agree with all of his suggestions. I hope people at VW are reading them. He's doing your work for you.

 

I find the way cameras work at the moment very confusing (with the result that I've generally simply avoided using them). Also, all of the scenarios outlined above are ones I regularly come across in an architectural context. By coincidence I made a few similar points in the thread I just updated ten minutes ago, here:

 

https://forum.vectorworks.net/index.php?/topic/47921-renderworks-cameras-horribly-confusing-and-what-is-the-point-of-them-at-all/

 

[Andy Broomell 1,026]

Now that 2019 is released and the Design Summit is over, I want to bump this topic in hopes that it's fully considered for VW2020. 😁

 

@Jim Wilson - has there been any internal discussion about improvements to the Camera tool? (I suppose you're probably not allowed to say, haha)

[PVA - Jim 2,382]

Lots of talks and this is very likely to be something we revamp, but if I had to guess, I would say it wasn't something in the cards for 2020. Lots of big rendering related news, but likely not this.

[Andy Broomell 1,026]

Interestingly, a small part of this wish was fulfilled in VW2020, but unfortunately not the most important thing.

 

Essentially you now get a pop-up asking if/how the camera should be embedded into the viewport, but currently there's no way to connect a viewport's Point of View to a Design Layer camera. So I'm bumping this topic for VW2021.

 

New pop-up:

 

 

This is the part from my original post that we need (#1):

On 7/9/2018 at 6:54 PM, Andy Broomell said:

When you create a viewport there should be the following options:

1. Leave camera on the Design Layer and LINK the viewport’s POV to this camera.
2. Leave camera on the Design Layer and create a duplicate camera to be embedded into the viewport.
3. Embed existing camera in the viewport (just like the current functionality).

 

Confusingly the new pop-up in 2020 also uses the word "linked"... It definitely got my hopes up when I first saw it. 😁

 

[EAlexander 258]

Oh God, yes please! 

[line-weight 727]

Yes, strange use of the term 'linked'. As if intentionally to confuse.

 

When they say 'linked' what they really mean is something like "settings embedded in", right?

[Andy Broomell 1,026]

Yes, I think the term "embedded" better describes how it works. Although, one of my students recently asked "So it's like the camera gets sucked into the viewport if it's selected?" I said "Absolutely," and now might start describing it that way to begin with 🤣

[Andy Broomell 1,026]

I just submitted a VE for this on JIRA... VE-101307

 

Of course I forgot I had typed up this thread in 2018 so I ended up retyping practically the same thing in JIRA. But here's the request as it was filed:

 

 

Quote

 

CURRENT FUNCTIONALITY

When you create a viewport with a camera selected, you can choose to move the camera and embed it within the viewport, or to leave the camera where it is on the Design Layer and create a viewport with no camera, or to duplicate the camera into the viewport while leaving a copy on the Design Layer.

None of the options allow for the most useful scenario: to leave the camera where it is on the Design Layer, and to create a viewport that LINKS to this Design Layer camera.

(Note that the word “link” is used in the existing pop-up, but it’s bit of a misnomer and what I’m suggesting is something different.)

 

DESIRED FUNCTIONALITY

We need to be able to leave a Camera on the Design Layer and LINK a viewport’s view to that camera (or multiple viewports to one camera). Changing a Design Layer camera would update all linked viewports accordingly.

 

REASON #1: DESIGN VARIATIONS FROM SAME POV

If you have multiple renderings of the same camera angle showing variations of a design, this is achieved with multiple viewports each with certain classes/layers visible. If you then need to change the point of view being shown, there’s currently no simple way to change the view of multiple viewports, since each would have its own independent embedded camera. The current process would involve changing the camera view of one viewport, duplicating that viewport multiple times, using the eyedropper tool to transfer visibilities and other per-viewport properties from the old viewports to the new ones, deleting the old viewports, then moving the new viewports into their proper places on the sheet. This process is very laborious and error-prone. Ideally a user could just alter the view of ONE camera object somewhere, and all viewports that are linked to that camera would update their point of view accordingly.

 

REASON #2: WHEN THE MODEL MOVES

Imagine you’re in the process of designing a set for a tv game show which has several video camera operators located on platforms throughout the set for different camera angles. You set up a RW Camera for each position, then create a viewport showing the view for each of these cameras. The next day, you learn the entire set needs to rotate 90° and move to the left 10 feet on the soundstage. When you reposition the set on the Design Layer, all of the viewports are now looking at the wrong points in space. The viewport “Cameras” cannot be rotated along with everything else, and this is very problematic.

Currently you’d have to re-create all of your viewports again from scratch; this is a pain because each might have different visibilities, render styles, data visualizations, etc. Ideally, viewport-defining cameras could stay among the model, meaning you could just select EVERYTHING, reposition as needed, then simply hit update on your viewports. 

 

REASON #3: SOURCES OF INFORMATION SHOULD STAY COHESIVE

A version or two ago Vectorworks added the pop-up that gives you the option to link, to not link, or to duplicate a camera when making a viewport. (Again, the word “link” as currently used is misleading/confusing). As it stands, let’s say you choose to duplicate the camera so that you still have one to interact with on your Design Layer. Well now there are two completely separate places where the view information is stored. It is quite easy in this scenario to accidentally change the camera in one spot and forget to change it in the other, which is quite frustrating. This needs to be unified and simplified. Duplication should be avoided at all costs.

 

REASON #4: SEEING & INTERACTING WITH CAMERAS WHILE DEVELOPING DESIGN

Assuming you avoid duplicating cameras since that’s error-prone, let’s say all of your cameras currently live within viewports, meaning there are no cameras in your Design Layer. This is problematic because now you can’t SEE where camera views are. When working on the model I want to see where my camera objects are because in the world of tv and film, everything is designed FOR camera views. Additionally, a director or lead designer might want to sit next to you and see in a groundplan all the camera positions, and they may want to adjust the positions or lenses on some of those cameras, all while you interactively edit things in the model on the fly. So we need to have the cameras remain on the Design Layer so they are collectively selectable and editable, all while still linking to your rendering viewports.

 

REASON #5: EXPORTING CAMERAS

We need cameras to stay on Design Layers for the purpose of exporting models to other programs like C4D, or exporting FBXs. As it stands the cameras end up within viewports so they aren’t exported.

 

 

Clearly this would need quite a bit planning regard UI/UX since this new feature would affect a number of different elements, but here are some initial thoughts regarding implementation:

 

INTERACTING WITH A CAMERA:

With a Camera selected: in addition to the existing View > Create Viewport command, there should be a button in the OIP that says “Create Linked Viewport” (very much like Create Section Viewport).

When you create a viewport, the pop-up would have the option to create a viewport that is:

1. “Linked to the Design Layer camera.” (new!)
2. “Embeds the camera into the viewport.” (to match existing functionality, if needed)
3. “Not linked to any camera.”

When you select a Design Layer camera that has viewports already linked to it, this needs to be visually clear somehow so that you’re aware that any changes made will alter existing viewports. Plus the OIP should have a dropdown or button that somehow indicates which viewports are being defined by the camera, with the option to unlink or navigate to any of them. I also imagine there’s functionality that would be added to the Visualization palette in this regard.

 

INTERACTING WITH A VIEWPORT:

This new functionality should be tied into the existing "View" dropdown. This dropdown should display the list of cameras that exist in the document so you can quickly choose one and the viewport switches to that view. There should also be an option to unlink the viewport from a design layer camera, making it independent. Or you could just switch to one of the standard views instead of the camera.

When you duplicate a viewport linked to a DL camera, the new viewport should also be linked to that same camera.

If you double click a viewport and choose to edit the Camera, it needs to be clear that you’re editing the Design Layer camera and that other viewports may also be affected.

 

 

Obviously there are a number of things that would have to be thought through, but in general this functionality would be a game changer and save huge amounts of time and headache. It would also be beneficial to every industry since cameras are used by everyone. This functionality has been requested a number of times on the forums over the years, and in my teaching and interacting with colleagues I've found that literally no one understands the current esoteric implementation of cameras and how they work with viewports. This would be a big step forward.

 

 

[grant_PD 245]

This doesn't have to be so complicated.  VW just needs to list the cameras in the dropdown of the OIP of the viewport where you pick your projection. I see no value in "linking" the camera to the viewport at all.  

[markdd 699]

Yes please. All of this makes perfect sense.

[line-weight 727]

Seeing as this was raised, and a wish filed, nearly four years ago (if not earlier) and nothing has been done about it, I don't have much hope for anything happening in the next four years.

 

As @grant_PD says - surely this does not need to be complicated?

 

Thank you nonetheless for taking the time to write it up again @Andy Broomell