1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

YET AGAIN we have transparent parts for no reason

Discussion in 'General Discussion' started by JST, Jun 30, 2020 at 9:49 AM.

  1. JST

    JST Alibre Super User

    NOT a new file, it is one that has been in progress for some considerable time. These parts were fine before, no transparency issues whatsoever. Today, I open up several files, and there are parts showing through, even though the parts that are transparent are set to 100% opaque.

    This is now getting very old.... something is unstable, and while I am sure this will be blamed on me, or on the imported parts, I think it deserves a specific CAUSE being explained.

    Do I REALLY need to supply files yet again?

    The parts that show through are usually imported files, STEP files.

    I do not understand how an imported part gets to over-ride parameters on other parts and cause them to become become transparent. Bigseb has mentioned issues importing parts, and it appears that he is correct, something is not right with the part importing.

    That business of how one part gets to over-ride another's parameters seems to be the point here. If one part is set to be opaque, it seems as if that should be absolute.

    In this particular case, everything is generally to the same scale, so it is not, or should not be, a matter of the "zoom out problem" where the scale is such that the distance between parts passes the threshold at which Alibre recognizes one part as being "behind" another.

    Yes, of course I HAVE closed Alibre and re-opened. Nothing changed.

    transparency problem 6_30_2020.png
     
    Last edited: Jun 30, 2020 at 10:00 AM
  2. Hunter

    Hunter Senior Member

    That is odd... I have the same graphics card, share the files please and I can have a look this side
     
  3. DavidJ

    DavidJ Alibre Super User Staff Member

    'in progress for a considerable time' - does that span more than one build of AD ?

    If you want a cause to be explained, yes it would be helpful if you provide the files. If they aren't too large to do so - provide them as separate files, rather than a package, so that they don't go though the extra actions of packing and un-packing. If too big for that, then a package is better than nothing.

    Does the issue persist if you delete the items that aren't directly involved in the visual problem?

    You've made a number of assertions about what you believe to be happening, do you have any evidence to support those over other potential explanations? Anything that points towards one thing, or away from another is potentially helpful in the analysis.
     
  4. Max

    Max Administrator Staff Member

    Without looking at your files, the problem feels like the Z-buffer is getting thrown off. Basically that lets the software know what's in front of other stuff, occluding it. When a difference in Z-buffers gets too tight, sometimes things don't occlude properly. If your imported file has screwy geometry, for example some errant edge way off screen, it will affect the scene itself, not just the part, because it throws off the Z-buffer of the scene as a whole. The scene means "everything you see". That is one possible reason, and I'm not sure if that is what's happening without seeing your files.

    But fundamentally your attribution of some file "overwriting" the parameters of other files is incorrect. This can be demonstrated by opening up some other file by itself and noting that it appears correct - its parameters are not overridden or overwritten. Whatever is happening it is causing an issue in the display pipeline as a whole, potentially visually affecting more parts than just the errant part when the conflicting part is in a scene. One such reason this could happen is errant geometry screwing with the Z-Buffer.

    I will say that while we occasionally see this issue in Support, it really is quite rare. You seem to have this issue all the time. I don't know if this is due to the place where you typically get your imported files or some other reason. I'm not saying it is your fault, however I am saying this "widespread" issue seems to be isolated primarily to you, your workflow, your STEP sourcing, or your machine. Which it is, I have no idea.
     
  5. simonb65

    simonb65 Alibre Super User

    @JST , to rule thing in/out and to try pinpoint a rendering operation that exacerbates the issue (and possibly give the Alibre team some things to go on as to the root cause), when you have the image you posted, try turning on/off anything that is related to the quality and type of rendering, i.e. ambient occlusion, change the projection, change the smoothing/facet, etc. If just one of those changes the rendered image, then it may help the dev to try and figure out the link/relationship and if it is an Alibre internal issue, may help narrow down the issue. There is no blame when trying to help debug issues, everything helps!

    Also, try moving one part of the assembly away from the main body. It was shown in the herringbone rendering issues that the overall bounds of the model had an influence (for whatever reason) on how it was being rendered, maybe that was influencing some kind of borderline z-order/depth calc as @Max suggests!

    You also didn't say if this was seen in Legacy or HOOPS mode or both.

    I've personally seen and posted on the surface highlight rendering (left in your image), but I haven't seen transparencies yet! I'll update with a link if I find it so you can see if the things I did to influence it do the same for you.

    Link: https://www.alibreforum.com/forum/i...-when-adding-part-precise-section-view.21563/
     
  6. JST

    JST Alibre Super User

    "Turning on and off XXXXX". When it is OK one day, then goofy the next, with NO CHANGES made.... well....... That seems not to be a matter of the settings, does it?

    Makes me wonder about the idea of it being parts as well.... since they were not changed. It seems as if the parts not changing would suggest that whatever they were, they should still be.

    I totally "get it" about the scene size. Mentioned that. Judging by the extent of the base planes, they are in no way out of scale with the parts/assembly. I assume that means the scene is not out of scale. Related to "z-fighting"?

    Yes, model has been through 3 versions of AD at least.

    Hoops is all I use. In the past some of these were visible in both. In this case, if I use legacy, I get an HRESULT error ((0xc0000005) Exception from HRESULT: 0xC0000005), and the model will not be shown, the workspace is blank. Going back to HOOPS, it comes up fine.

    In Legacy, the parts are all shown in the design explorer, and they seem to "work", I can select a sectioned view, it just does not actually get shown. And closing, I am asked if I want to save it. So the file is there, it just cannot be seen.

    Going back to Hoops, it is perfectly OK.

    All the parts that are seen through other parts are ones that came in as STEP files. Something may be amiss there in the importing system, as Bigseb has mentioned as well.

    The fact that it is persistent through shutdowns and restarts of the software and the machine suggests that it is some sort of actual change to the file. I did not make the change, or at least the change was not visible when last worked on, and it is visible and persistent now..... Hmmmmm.

    Hey, I'll go away and not bother you with things. If you are saying it is at this end, that's fine. No idea HOW that could be, but we'll see if anyone else comes up with them. In the past, it has NOT been "just me", as with the tiger stripes.

    Bigseb is noticing some oddities a few of which I have seen as well...... Hmmmmm

    But, I'll not mention these things again unless it/they show up elsewhere, and I happen to see the mention.
     
    Last edited: Jul 1, 2020 at 12:29 AM
  7. Max

    Max Administrator Staff Member

    If that is reproducible, giving us those files would be an excellent start.

    Not saying it's just you. We have seen occasional issues as I indicated above. However the frequency with which you see these things on a broad array of models is highly unusual and I daresay unique. Why that is, I do not know. Wish I did.

    That said, the only thing we can do is get your files and analyze them. Then, we can report the issue to HOOPS and they hopefully can reproduce it. Then, they decide whether to fix it or not, given their other priorities and how common the issue is, etc. That is the general process for display pipeline issues.
     
    Last edited: Jul 1, 2020 at 3:52 AM
  8. bigseb

    bigseb Alibre Super User

    I have a relatively short list of issues. Some of them are 10+year old problems that just don't seem to get fixed while others are new problems that I have encountered since the upgrade to the new graphics pipeline. For the most part Alibre behaves, I just tend to not post the success stories.

    Since I follow a set methodology when designing a part and it works fine 99% of the time then that 1% when it doesn't work must be a glitch in the software. I hate going back and fixing models that shouldn't need fixing (hence my posts) but 1% failure rate ain't too bad.

    My 2p
     
  9. JST

    JST Alibre Super User

    You already have the files in package form. They are the same files as for the weird replacement of parts issue. Ticket for that was entered, and David J has replied.

    Those files are slightly different from the ones I showed, in that the goofy parts were not corrected in what is with the ticket, but the issue of transparancy is the same for those and the others.

    And, yes, in each case, ALL the parts appear to be listed at 100% opaque. Most of the parts that become partly visible are imported parts, but all are now Alibre parts by virtue of being imported as STEP and saved.

    Some of the imported parts are themselves also partly transparent, although they are shown in color properties as 100% opaque.

    Native Alibre parts become partly transparent TO some imported parts, the imported ones show through. It is as if the imported parts are affecting the native ones, although the scene does not appear to be large based on the base plane sizes as shown.
     
    Last edited: Jul 1, 2020 at 2:47 PM
  10. DavidJ

    DavidJ Alibre Super User Staff Member

    I've gone back to the 'goofy parts replacement' files.

    I'm unable to re-produce this visual problem - we need more information to identify differences between systems/settings that might be a factor. Or the package/un-package process has removed the issue...
     
  11. HaroldL

    HaroldL Alibre Super User

    Would just the transfer of files somehow affect the results seen or not seen on a different computer?
    When Alibre first came out Customer Support included "Alibre Assistant for realtime expert guidance as you work". Now we have Zoom, Google Duo, Skype and GoToMeeting. Why not use one of them to start a session between JST and Support so the issue can be seen first hand on JST's computer.
     
    simonb65 likes this.
  12. JST

    JST Alibre Super User

    I specifically looked for it on the sent file. It's there.

    it's not an issue for me if it is not for Alibre, so you just forget about it. If it is a problem, it will likely get fixed when a bunch of the others get fixed.
     
  13. DavidJ

    DavidJ Alibre Super User Staff Member

    That isn't helping us to locate the issue...
     
    simonb65 likes this.
  14. DavidJ

    DavidJ Alibre Super User Staff Member

    Harold, support can and does run screen share sessions with users from time to time. Screen share applications themselves can affect the display.

    Nobody is doubting what JST is seeing, the images he has posted are clear enough. We need to identify what's different in Alibre settings/profile or on his computer that allows this to happen.
     
  15. JST

    JST Alibre Super User

    I'm the only one with the problem, so I do not propose to waste everyone's time with it. There are "bigger fish to fry".
     
  16. DavidJ

    DavidJ Alibre Super User Staff Member

    OK - but if you change your mind, get back to us. If it can happen on one system, it can potentially happen on others - it would be good to find the cause if we can.
     
    simonb65 likes this.
  17. JST

    JST Alibre Super User

    You got in before I was able to finish getting files and pics.

    The attached shows a version of the issue. In teh closeup, you can see the edges visibly go back into the material a distance. Those parts are native Alibre parts. The imported screws also show the issue.

    This is not as gross an issue as in some other cases, but I wanted one that showed the effect with a native file.

    This is a section, and maybe that affects the result, but it is not only sections that show it. You can see it elsewhere, such as with the setscrews on the "nose", where the first thread under the surface is visible through the solid material.



    Floating reamer holder overall.png

    Floating reamer holder detail.png

    Floating reamer holder detail of screw.png
     

    Attached Files:

    Last edited: Jul 3, 2020 at 10:11 AM
  18. DavidJ

    DavidJ Alibre Super User Staff Member

    Could you send your user.NET.profile to support ?

    So far I haven't been able to reproduce those 'tails' - if I can substitute your profile, that should confirm if Alibre settings are playing a role here or not.
     
  19. JST

    JST Alibre Super User

    Sent that, and the other things you requested.
     
  20. bigseb

    bigseb Alibre Super User

    In that second and third pic, I get those occasionally too. Usually I just ignore them. Don't know what causes it or what makes them go away. Don't recall it being as bad as in the first pic at the beginning of the thread but those 'tails' yeah I have that. I always just ignored it.
     

Share This Page