Position Camera bug in 2022

Doesn’t that by definition break Position Camera?

3 Likes

But what is essential here is that Position Camera work as it did in 2021. That is, things in front of the camera in parallel projection mode are visible and things behind the camera are not. Greater control of how things are depicted that are hidden behind visible geometry or are behind the camera would be welcome and useful features. But they are not essential.


Keith

Oh, one other reason I rejected using auto-invisible-layer is that it doesn’t address the problem of object (groups/components) visibility. My understanding was that it only deals with tags (layers). What I need is something that can keep a new object(s) from being turned on in all scenes. Creating a new tag to cover every new object or combination of objects just to keep them invisible in old scenes could make a mess of the tagging structure.

I also use this technic, and I check now, not work :frowning: MacBook

I understand, I was offering that as a tool specifically for managing visibility in scenes, not for the larger topic of your thread. I do not use position camera in PP the way you do and don’t have too much problem using multiple section cuts, especially when included inside groups, but I do understand your method and see how this change affects you.

Much of my design work involves moving or transforming objects which are capable of existing in many different states so my files often have many scenes and carefully constructed tag structures to manage visibly of all objects. Auto invisible Layer had been an important part of my work flow for a while, I guess 5 years or so? It has not been updated (still calls them Layers) but it works reliably and does an important job for me. When I need to add a fresh object to an existing file with many scenes I generally want one of two options: either to associate the new object with an existing tag so it conforms to the visibility states already set in all scenes. Or to assign that object a new tag that is off by default in all scenes, then add it specifically to the one or few scenes I want to see it in. If you are controlling visibility by hiding objects and recording their hidden state in scenes then this is much more difficult process to manage.

I thought I remembered something like this… I have not tested this, use at your own risk but it appears to do what you want, hide objects in multiple scenes. Using tags I think is ultimately more efficient. Good luck.

Sad to see this functionality disappear! I’m new to Mac, came to it with a recent job change. The technique of using clipping planes was discussed at the 2018 Basecamp - I think in the Nick Sonder presentation.

It was a pain creating interior elevations without it, as each room has 4+ elevations, and a typical 3 bed / 2 bath house would have a minimum of 12 section cuts, closely located together, just for the kitchen (no island) and baths.

@keithd - I believe you can assign section cuts to specific tags (layers) and turn them off, which may help you recreate what you lost.

Then, in the scenes panel, select the individual scene. Turn off those section tags(layers) you aren’t using. Expand to see what items are saved with the scene, and tick off then back on the visible tags checkbox.

Also, with tag grouping now available, you could group all the tags together and turn them all off at once. Just a thought, I won’t be trying this until later this week.

Maybe @JustinTSE can confirm a couple of these work arounds, he’s one of the best in the SU biz about helping others.

Shawn

1 Like
2 Likes

This is the second attempt to make the clipping more user friendly for beginners to cope with (first one was in release 2020.1 that changed the way it was dealing wih the camera position in parallel view, instead of enlarging the image, it now repositions the camera)
The first didn’t had that much impact for more experienced user’s that learned how to deal with clipping, though.
Now, the impact is much larger and resulting in a feature no longer working as it supposed to.

If you are on Windows, you can open up the Ruby console [menu] Extensions > Developer > Ruby Console and type Sketchup.send_action(10624)
This will pop up a ‘blender-like’ panel with positions and properties of the camera:

all in inches, btw.
If you force the ‘Near’ to somewhere around 386, it kind of works the way it used to be, but then you have to reset it back (Un-Force) to be able to model and it wouldn’t have impact on saving scenes, since the ‘forcing’ isn’t a propertie that get’s saved.

So, the developers might consider a more professional way to deal with it by giving the user a more user friendly way to deal with the Sketchup.send_action(10624) (for both OS’s, off course) or just have a Preference setting to deal with the new ‘improvement’

2 Likes

I wonder if this is an unfortunate case of people using a bug as a feature. Once the bug is fixed the ‘feature’ goes away.

2 Likes

It’s not, they change the workings but do not provide an alternative. Position camera should do what it’s suppose to do, IMO.

A while ago, they fixed a bug in Generate Report (which really was a bug) that broke some workflows for some of us.
But that resulted in a working and better Generate Report along the way.

What will happen if they decide to fix some bugs in Dynamic Components?
That would break some workflows of major clients:)

Or change the way ‘explode’ works…

I don’t disagree Jack, but I’m just saying that the particular action that people found useful may not have been a deliberate feature, simply a happy accident.

2 Likes

I don’t know the internal workings, but I’m having a hard time conceptually with orthographic projections having any camera location at all. Conical (perspective view) projections have a camera or eye point location, and rays are traced converging to that point through a picture plane. Orthographic projections have a picture plane, but no eye point, and rays are traced perpendicular to the plane, not converging to a point. What does “camera location” even mean to orthographic view?

It is the location of the picture plane, at least in the older version, just like for perspective views. Now the picture plane is always moved back so that the whole model “fits”.

Attached is a project that used the Position Camera in Parallel Projection allowing the shadows from the storefront and Logo to be visible. See ‘ELEV Back’ (no clipping now). It was a nice use of the Picture Plane.
Century City.skp (1.3 MB)

  • Can we set our own Clipping Plane in Foreground and Background like Justin showed from Blender? Can this be combined with Section Planes to knock out backgrounds like a white out plane?

That would make sense for orthographic, but for perspective, the picture plane must be anywhere but through the camera location. What determines where the clipping plane is when you set the camera position for perspective views?

I would guess that the clipping plane is, again, at the camera picture plane. I don’t know how it relates to that clipping appears sometimes in perspective views, too.

I’m sure it’s been said before, but this is an example of why it’s a good idea to keep previous versions.

1 Like

What “bug” are you referring to? There was no bug in Position Camera in Sketchup 2021. People relied on Position Camera doing what it should do, i.e., show things in front of the camera position (camera sensor plane) and not things behind it.

The “bug” that was fixed was the automatic setting of the 3D front clipping plane getting in people’s way. But in trying to fix that “bug” a new bug was introduced into the heretofore bug-free Position Camera tool.

So people were not “using a bug as a feature.” They were using a correctly functioning Position Camera tool. Now they have to live with the newly-introduced bug in that tool.


Keith

2 Likes

Previous versions isn’t a solution. When an architect creates a set of plans those documents have to survive for years. And be in working condition (alterable) for years. For longer than she can rely on an old version of the application remaining viable.


Keith

1 Like

It means the location of the plane of the camera sensor. Why is that harder to conceptualize than camera or eye point location?


Keith