Endless glitches. This software is junk, how are they actually charging money for a “pro” version of this?
Ztill Z-fighting? People who invest money in a product, usually go a bit further then repeating the same thing over and over. If you have time and you value it, invest some time in the basics instead of throwing it away.
Two things: saving to a L:Drive (server/usb?) causes problems, depending on the file size and autosave-settings.
HD Internal cards are known to have issues with OpenGL, yiu need a dedicated graphic card for using SketchUp.
1 Like
Something so simple should not occur in a program like this. Why have they not resolved it?
Same file exception BS happens whether it’s a USB drive or just my C drive.
1 Like
Z-fighting, the thing we tried to help you with over 6 months ago, is your creation. It was explained to you then. You haven’t changed your workflow. That’s not a problem SketchUp can fix. You need to fix that but apparently you’d rather complain than fix it.
2 Likes
Z-fighting is not something that should be happening at all, regardless of how people are using the program. It’s a glitch that would be simple for them to fix, but it remains, years later.
Your profile indicates that you are a SketchUp Make user, not a SketchUp Pro user. Forgive me for asking, but what is your monetary investment in SketchUp that’s at stake here? Just curious.
For what it’s worth, I’ve been a SketchUp Pro user for a few years and am generally quite happy with the reliability and general quality of the software (speaking as a software engineer for the past 37 years).
4 Likes
As I understand it, Z-fighting stems from an inability of OpenGL to determine what should be displayed when two faces occupy the same space. Can you suggest a change to the modeling function of SketchUp that would either:
- eliminate the possibility of user creation of competing faces or
- resolve the ambiguity such that OpenGL can know definitively which face to display?
All without forcing a complete redesign of the internals of SketchUp?
If so, then please make your pitch to directly to Trimble.
Perhaps someone not willing to adjust their work flow when it comes to Z-fighting should go after the OpenGL Consortium. Maybe they will listen !!!
4 Likes
I’m on a 300 euro laptop without a dedicated graphics card, never had these problems…
Just do it the right way!
1 Like
Z-fighting is great because it lets you know when two faces are on the same plane. It should never be removed because how useful it is.
Z-fighting doesn’t seem to be your problem though. It seems to be a problem with overlapping faces in the same drawing context. This is not a Z-fighting issue (rendering) but a problem in the underlying geometry. In some rare cases SketchUp fails to properly create faces and create this overlapping ones. I would erase the outer face and try to re-create it by drawing edges between the outer edges of the inside faces and the outer loop of the outer face. The risk of SketchUp producing overlapping faces can also be reduced by using several groups and components, rather than having all geometry in the same drawing context.
5 Likes
A20022970,
Yes, the software should never crash just because the user does something the software allows.
The geometric construct of co-planer planes exists in many places, it is a mathematical construct in origin, that shows up in the computer. Two other examples are In 2D drawings and diagrams in a word processing document. In programs like MS Word and Power Point, there is an order characteristic provided for document items, and functions like bring forward or send backward to change the order.
It is the software programs job to determine the order that co-planer objects are displayed and printed in the 2D world. This is very serious for programs like Word. And depending on the drawing program, and its promised functionality, it may be an important problem. or an irritating functional shortfall to work around. Or as eneroth3 indicated, it may provide a useful by product. In this case, since SketchUp does not provide an order function (which could be an interesting challenge for a 3D program, but certainly not impossible), the best hope is; it does not crash, and to make the some use of the behavior.
It is not the job of graphics systems like OpenGL to determine the drawing order of co-planer objects. Only the user interacting the drawing program human interface would provide the knowledge of the proper order.
If only drawing one 3D solid object, co-planer is an error in the solid. However in a drawing with more than one solid, co-planer is not unusual. But in SketchUp these solids need to each be their own group (or component) otherwise SketchUp will try to merge the objects.
Sometimes if I feel I need to have things co-planer-ish, I will offset the planes and leave a small gap between them for display purposes. This does not work for drawing real (solid) objects though.
But the software should not crash, and should not rely on some other system to determine the drawing order.
All the best,
Charles Sloane
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.