What causes this herringbone / woodgrain effect

[JST]

Ok, this is TOO ODD.....

I opened the small part this morning. It looked bad, with all the edges visible again. But the part was where it was when it looked good last night. Then I moved the "extra" part closer in again, AND THE EDGES THAT WERE VISIBLE MOSTLY WENT AWAY.

Something is WAY wrong here. I'm going back to legacy graphics until this is sorted out.

 

[DavidJ]

JST, did you save the assembly after things displayed OK ? I'm not accusing - just asking.

I was having this issue all the time with this assembly, until I tried the 'isometric view trick' mentioned above. Then I saved the file. Now it opens with correct display every time.

 

[JST]

JST, did you save the assembly after things displayed OK ? I'm not accusing - just asking.

I was having this issue all the time with this assembly, until I tried the 'isometric view trick' mentioned above. Then I saved the file. Now it opens with correct display every time.

Between the original post about moving the part away and having it work, and the next about it needing to be moved BACK to look right, I did of course save the part, in the condition (part moved away) that made it display correctly.

It has been saved since, and now looks OK, except for the residual bits of the edges. Was like that when I looked at it just now ( I have not switched back to Legacy yet)

Is that what you were looking for?

I do not recall whether I saved the BIG file, I think so. EDIT, I just checked, and I did save it, it still looks bad with anything under about 2cm thick showing "all edges" despite the fact that I set it to "visible only".

Now, when I move the extra part back to where the view was all messed up, it does not get that bad, but as the part is moved around, jaggies and (I think) transparency dance around all over the model, parts seem to disappear at random. It is very strange.

So I DELETED the extra part. Now a similar "dancing" is going on as I turn the model around in the view. But the weird transparency of everything is gone. However, the visibility of edges that should not be visible now moves around with the viiew. Some parts show it in a particular position, and other IDENTICAL parts do not. Which shows changes as the orientation is changed. The white rack that I showed that on is a very good indicator.

Also, triangular sections change to transparent, and back to color as the view is changed. I have seen that before, and not just with 20072, all the 2019 at least have done that, IIRC.

I did NOT do the "isometric view" thing with either of them. I do not use the ribbon, do not have all the toolbars set yet after the new version (it did not import my settings), I do not have the display as was shown, and did not see the view thing on the menus, or I would have tried it.

 

[JST]

Well, using the isometric view did seem to fix much of it. The transparency problem is not entirely fixed, but the other stuff seems to be.

No amount of zoom-in will fix the transparency and extra edges of the white rack frame in the big model. It is apparently a function of the percentage of the entire model size that the piece is. If too small, even if "too small" is an inch thick, then the part is treated as if it were transparent, and all edges are seen.

That seems to be a separate issue from some of the other stuff, tiger stripes and jaggies. It must be related to the way thin things get transparent when zoomed out.

 

[Nick952]

Just had time to try this on my desktop PC (as in my signature) and can confirm the herringbone effect is present with my setup.
However selecting any view, not just Isometric, works on my system.

 

[JST]

So, now, I open upo the big model, and it appears that the transparency issues went away, along with the tiger stripes and jaggies.

I had opened and closed it several times before (not saving), and each time the white stand had transparency issues where every edge was seen. Now for no apparent reason, all of a sudden it is looking like what it is supposed to look like.

I have absolutely no clue.... nothing was changed, and the file has been opened before and closed w/o changes, while the problem was active. I had to check the version to be sure that an auto-update had not occurred. Nope, still 20072

I mean.... I guess I am happy now, but it would be nice to know what in the blinking backside of heck is going on.

 

[JST]

So...... Is there any resolution on this?

Any clue on the what / why/ how of it?

Or is it "resolved" because there are actions that "seem to" make it go away?

At least they "eventually" make it go away, since I did not see the final changes immediately, it took several opening and closing sequences before all the effects disappeared. And time will tell as to whether they will "stay" gone.

If it is any help, the large model that did it for me was one that was originally created several versions ago. It has been worked on under all of the ones that came out since it was started. That means it may be a real hash of different models and parts within it, although I presume they get updated when opened with a new version.

The first version of the model was created with whatever was the current version in July of 2014. Yeah, almost exactly 100 years from WW1, maybe that jinxed it......

 

[DavidJ]

I'm sure Max will post when this has been bottomed. Investigation is ongoing.

One cause which has come to light for hidden lines to be visible when they shouldn't be, is the inclusion within an assembly of an imported part having such issues itself. The problem can then affect the display of the whole assembly. Put simply - a part which imports with display 'problems' which are not fatal, can affect the display of an assembly it is used in. Exactly why/how this happens hasn't been determined yet.

This particular issue can be resolved by suppressing or removing the 'problem' part. Hopefully a re-import with different import options can result in a part that doesn't have the problems, and can then be used successfully in the assembly.

 

[JST]

OK.

I would like to point out that the suggested cause (defective parts) is probably NOT the case for at least the large model I presented, and I believe not for the smaller one that was posted here. In neither case was any component part changed in any way during the time that the display changed from bad to proper. Not on my system, anyway, cannot swear to others'.

The SAME set of component parts simply changed from having transparency issues to displaying perfectly.

As mentioned, the change was not immediate. The jaggies and stripes went away immediately when the isometric view was selected. However, the transparency issues persisted through several openings and closings of the models. The large model took perhaps 6 or 8 open/close cycles before it suddenly was good.

At no time were the subassemblies that showed the transparency issues even so much as opened by themselves, let alone edited or changed out for different ones. Since the large model had subassemblies moved around, it was, of course, saved repeatedly. I cannot rule out some sort of "automatic self healing" process that may have occurred when the model was saved.

The very same parts and assemblies that had the problems now display perfectly, with ambient occlusion on, etc. None of them were altered in any way between the "bad" display, and the "good" display.

 

[DavidJ]

Calm down - I only mentioned that it was one cause that had come to light, and I only referred to hidden lines showing when they shouldn't.

Great that you've checked and it doesn't apply in your case.

 

[JST]

Perfectly calm, just want to be totally clear about what the circumstances are, so there is no confusion and no blurred lines.

OK, the whole deal is becoming a bit irritating, I will admit that.

I would imagine, however, that it is becoming a bit MORE irritating for the development team. Been there, seen that, and threw away the t-shirt. It usually is better when as many facts as possible are nailed down tight, because that often is of a great help in identifying the source of the issue.

At the risk of telling grandma how to suck eggs, it might be wise to dig into some of the basic assumptions and math routines. There is a "constellation" of issues in the program, and it sure looks as if many things are potentially explainable, at least in part, by issues of rounding and significant digits.

 

[DavidJ]

An update on this - Development has found WHAT happened, but not WHY (i.e. not clear what triggered the problem). Selected text from the analysis is below

The assembly in question opens with a bad visual transform… which gets rectified if we switch to one of the standard views...

The best approach is to find the root cause that makes the transform bad. I recommend we mark this as a ‘data point’, try to find a reproducing case and watch out for such designs in future.

We would be very interested in any other examples of such behaviour - ESPECIALLY where it was noted what action triggered the onset of the issue.

 

[JST]

I have looked through old files, and have not found any others than ones that were already shown, or which got "fixed" somehow in the process of looking at them etc.

The known things:
First seen with the latest version using win10 PRO computer with far more than the minimum of everything. (per sig)
Happened in HOOPS mode, seemed to be OK in legacy
Nothing special was done to the files, they opened like that from the get go.
There were a total of a half dozen or so such files
All were created with an older version of Alibre, and had been worked on with other versions in between, modifying, adding parts, etc. Some had been worked n under XP, Win 7, and then were opened with the present computer
All were rather larger files, with dozens of subassemblies, and hundreds of parts, although some parts were re-used multiple times in the model.
At least several (possibly all) showed both the herringbone, AND jaggies, and had odd transparency issues as well where parts were partly or completely transparent, but should not have been.
At least several also showed the "all edges" option display on some parts even when the "visible edges" selection was made.

Interestingly, several files of similar size and complexity that were as old, or older, but had NOT BEEN worked on by any versions since about 2014, did NOT SHOW any of the problems.

 

[simonb65]

I have a theory that somehow some internal setting is making the display pipeline think the model is much, much smaller (like 3 orders of magnitude) than it is and as a result these weird display artifacts are showing up. Increasing the bounding box of the assembly seems to remedy the issue. It is indeed very strange and likely a HOOPS bug. We're following up with them.

There's a few ways to get somewhat similar behavior arbitrarily, for example offset 2 faces by .00001" and then zoom way out - the precision required at subpixel depths to figure out which face is in front of which face becomes a challenge - but doing that is somewhat arbitrary and not often an issue - figuring out how this got into this state will be the challenge. We've seen a total of 2 cases of this since shipping the last version, so it's not rampant. It also doesn't appear to be consistently reproducible by folks here, though I can reproduce it.

@Max , did you guys get any further in identifying the root of this issue?

I'm wondering if it is also causing the drawing issues that some are currently seeing with coloured faces int he v21 preview, and is it the thing that's causing cosmetic thread textures to not be rendered to the correct scale? They all seem like possible internal scaling going AWOL!

 

[JST]

I have a theory that somehow some internal setting is making the display pipeline think the model is much, much smaller (like 3 orders of magnitude) than it is and as a result these weird display artifacts are showing up. Increasing the bounding box of the assembly seems to remedy the issue. It is indeed very strange and likely a HOOPS bug. We're following up with them.

There's a few ways to get somewhat similar behavior arbitrarily, for example offset 2 faces by .00001" and then zoom way out - the precision required at subpixel depths to figure out which face is in front of which face becomes a challenge - but doing that is somewhat arbitrary and not often an issue - figuring out how this got into this state will be the challenge. We've seen a total of 2 cases of this since shipping the last version, so it's not rampant. It also doesn't appear to be consistently reproducible by folks here, though I can reproduce it.

That has some possibilities.

Here is another oddity, which is not always present, but can be. Note that this is a flat surface, but has holes etc, which seem to affect the pattern... the holes in the surface seem to have the "fractured" pattern centered on them.

Note also that the display is working right, the HOOPS shading is correct at this time.

.

 

[netcp]

If you open the affected part and do a „regenerate all“ instead the usual „dogbone down „
Turn the graphics in the assembly to normal?
In may case it do.

 

[JST]

View attachment 29829 With this particular issue, it seems to occur regardless of legacy or HOOPS.

It is odd because it occurs along lines between holes, it changes depending on view angle (but the "base lines between holes do not), and it can invert the dark and light areas depending on where the cursor is. The two below are inverted one vs the other.

But the sub assembly showing the issue does NOT show it when the exact same highlighting is done just on the subassembly itself. Even with the "mount tubes" subassembly attached it still does not show the issue. Only with the full model. And only on that particular part (back or front) even then.