I’m getting weird rendering artefacts in both the viewport display and when exporting views to 2D jpg files. It may be because of the model (which is about 89.5MB) which has a few high-facet imported components (furniture mostly) but nothing that my brand-new-bought-it-to-handle-large-files Mac Studio should have any issues with. Other files are not showing the same issue. Anyone?
Can you share the model?
Do you see those artifacts if you send to LayOut and export to JPG from LO?
I occasionally get the black cuts / model view - but it goes away as soon as I orbit or start another command (Mac Studio M2 Max).
Thanks a million @bmike - same result when exporting viewports from Layout.
Here is a link to the file in Trimble Connect: SketchUp or do I need to upload the file itself?
You need to upload the file… here if its smaller than ~16mb or use DropBox or WeTransfer or similar.
Are you using classic or new graphics engine?
https://www.dropbox.com/t/VLzs2wFVblm1TuNB
New Graphics engine
This is what I see when I orbit around a bit to get close to the same view you show. This is on my PC. Makes me wonder if this is a graphics issue on your machine.
Thanks @DaveR - I’m starting to feel like Mac’s are not feeling the love from Trimble what with Scan Essentials not being available and now this. I will try and copy the layers one by one to a new file and see if it is an issue with the entities within the model as other models (although smaller) are not exhibiting the same issues.
1 Like
Presumably you mean groups and componets?
You could just use Save as … And give the file a new name. Then perhaps delete the more complex objects in your model.
Before you do that, switch the camera to Perspective and zoom in a little to make sure the camera isn’t located at a huge distance from the model. When it’s in Parallel Projection the camera distance isn’t neccessarily what it looks like.
You could use Statistics Probe from Sketchucation to look at the “heaviest” objects in the model and deal with them first. May or may not help but …
BTW, it would be a good idea to clean up the model. Fix incorrect tag usage.
And merge the duplicate materials.
@DaveR - you are officially the GOAT. It was simply a case of switching from parallel view to perspective view and then back again. Problem sorted!
Thanks a million also for the clean up tips - I try to keep everything as simple as possible but using models form the Warehouse does not always make this easy.
I will definitely look at the tools you suggest although it would be great if there was a workflow or guide to keeping models lean…?
Excellent!
Thank you!
That it gets fixed by going to and from perspective is curious, I may log a bug report about that.
For the question of Mac getting any love, a lot of us use Macs, and all of the live modeling streams are on Mac. Hopefully we don’t have too many Mac specific issues.
Dave may have already gone through perspective before his screenshot. Here’s a recording of my work PC followed by my work Mac. You can see both have the artifacts.
1 Like
Weird - at first I saw the artifacts…
I noticed you had some overlapping geometry and thought we were seeing strange z-fighting.
But then I closed and re-opened and switched to perspective…
and when I switched back it was gone. Definitely a glitch somewhere with the processing of AO.
So @colin - definitely looks like a bug.
I think someone had a Ruby that can tell the camera position even in a parallel view. My guess is that zooming and orbiting around has moved the camera somewhere near the Moon and that switching to Perspective and back resets it. I don’t know if the change made some releases ago that reduced the clipping issues with Parallel Projection is a factor in this.
2 Likes
Thanks @colin - I take it all back! My words were poorly chosen and came at the end of a long day! The fact that Sketchup is available for Mac at all is already a massive gift. A long time ago I worked in environments that were either Microstation or Autodesk based and being able to switch to a Mac environement with Sketchup has been a life-changing and bank balance rescuing experience. Thanks for the input and the rapid feedback.
Thanks @bmike for taking the time to look into it and the feedback - very much appreciated!
I did log bug SKOR-21050 for this to be looked at.
1 Like
What is strange is that in the current project on my desk with much more going on - no amount of parallel to perspective switching can trigger the bug, but when I open @Ryanvr file it glitches in that file only…
1 Like
I found a command that tells the camera position. When I open the model it gives me this:
I don’t know the units it reports in but the Z coordinate is in millions
3 Likes
To reinforce what has already been pointed out, here are the properties of the camera in that scene both as saved in the model scene and after I orbited to approximately match your image (the reports were generated by a Ruby snippet I wrote):
properties of scene camera:
description = “”
parallel projection with height = 1324.2077813752257
eye = (-6.940119 m, 17.970978 m, 76010.350471 m)
direction = (0, 0, -1)
target = (-6.940119 m, 17.970978 m, 0.723934 m)
up = (-0.707107, 0.707107, 0)
axes: x = (0.707107, 0.707107, 0)
y = (-0.707107, 0.707107, 0)
z = (0, 0, -1)
After orbiting to approximate your image:
properties of current camera:
description = “”
parallel projection with height = 344.7483624869074
eye = (5979.720838 m, -61351.093795 m, 44472.643262 m)
direction = (-0.0787554, 0.80722, -0.584973)
target = (-6.446939 m, 5.37928 m, 9.03642 m)
up = (-0.0568025, 0.582209, 0.811053)
axes: x = (0.995274, 0.0971027, -1.38778e-17)
y = (-0.0568025, 0.582209, 0.811053)
z = (-0.0787554, 0.80722, -0.584973)
The important thing to look at is the eye position of the camera. In the scene, the x and y components are reasonable, but it has a z component of about 76km! When you orbit the view (imagine the camera moving around on a sphere), that huge z bleeds over into the x and y, causing them to become very large as well. The renderer isn’t handling that large offset well, especially with ambient occlusion turned on. With a bit more orbiting I can make it look even worse:
The source of the problem is that in parallel projection, the viewed size (zoom) of the model is determined by a scaling factor, not by the distance of the camera from the model. During model edits in parallel, it is easy to cause the camera to move farther and farther away from the model but with no visible effect on the view!
Zoom in perspective projection is determined by distance of the camera from the model. When you shift from parallel to perspective, SketchUp has to regenerate the camera and by attempting to keep the visible scale consistent, it must repair that huge distance. That’s why flipping back and forth between the projections repairs the problem.
The same kinds of issues can occur if the model is located a huge distance from the origin or contains huge or very distant objects. In those cases, flipping the projection won’t fix anything, and may cause the model to vanish.
Edit: These are among the reasons why you should never present 3D views in parallel projection, particularly while editing a model. Save it for traditional orthographic views in documentation.
4 Likes
The camera position seems to be the important bit. If you do a position camera, zoom extents, orbit, you can fix the issue without going in and out of perspective.
I will add a note to the bug report.
1 Like