CameraViewport is cloned from Sys

POPs
1

I’m not sure if this is really relevant so much as we are testing POP issues here but the CameraViewport COMP from the palette in build 2023.31533 is cloned from Sys so whenever you restart your file it’ll revert back unless you de-clone it.

2

Hi @Ennui

What do you mean it reverts back ?

This is purposedly cloned from /sys.

Just gave it a test and the transform you leave it in when saving does load as expect after a restart.

3

@JetXS Thats true but if you edit it in any way it will revert. Add a TOP after the render, save your toe, reload and the TOP should be gone because it was a clone and it’s re-cloned from Sys.

Edit: Also a little tiny RFE here. Can the render TOP by default have it’s lights scoped as * …/…/* rather than just * ?

4

Ah - I thought you were referring to the camera transform.

For changes to the render pipeline, I think the take here is to use the parameters of the COMP.

image

But I’ll let @robmc jump in and give his input.

Best,
Michel

5

Those parameters make sense but I still think thats a pretty bad workflow. By all means copy it from Sys but have enable cloning turned off and then allow people to re-clone if they want. Having COMPs cloned from Sys is a nightmare for anyone who’s starting out, goes in and edits things and then opens their file 5 hours later to realise all their work is gone. Especially when some COMPs aren’t cloned and can be edited as expected.

6

Thanks for the feedback on cloning and the suggestion about the Render TOP.

The idea behind making it a clone was that the majority of users, especially new ones, should not really be making changes inside the comp and so it was better to prioritize updates over customization.

As Michel pointed out, in theory the Panel and Render parameters should be used to point to external versions in your network that can be customized further.

That said, the cloning system does have it shortcomings and I can see how users could lose work by accident. We are working on a few things internally to improve cloning so we will keep these suggestions in mind as we move forward.

7

Hmm some more thoughts on this…

  1. If you update a project which uses a palette component which has fundamentally changed in a later build and it breaks your project. This cloning idea really relies on some kind of versioning for legacy projects.
  2. If somebody goes in and edits the component it could automatically set itself to de-clone or warn the user.
  3. The biggest problem with the palette at the moment is consistency across components. If one is cloned by default they probably all should be.

I’ll end that here though since it’s not really an alpha issue

1 Like
8

As robmc says, some components will never be edited by 98% of users and it is best that they be continuously cloned. In the upcoming cloning system, it’s more apparent from the outside and inside that a component is cloned. We’ve also talked numerous times about a toggle to make a component un-enterable unless you declare yourself a power user (preference) and don’t want barriers, or you manually turn toggle off.

3 Likes