DraftAngleAnalysis and transparency in Rhino6 not working

Hi Daan - sorry, as far as I can see the item is open but not yet fixed. I added a comment for the developer,

-Pascal

Thanks!

Pascal, thanks for your help for now but…

It’s really a shame that it takes so long, 4 months now. I payed a lot of money for the upgrade and can’t use it because functionality of the draftangleanalysis command changed without notification.

I hope that you can bump the developing team again. I understand that this bug is not the only problem and that (I think) i’m the only one experiencing this problem. But when a command functions in version 5, then it should be functioning in version 6.

Thank you in advance, sorry that i need to notify again.

Hi,

Do you have any sight on a solution?

Thanks, Daan

Hi Daan - I gave it another bump and it looks like Wim did as well…

-Pascal

Fixed.

Some things just take higher priority than others…this (IMO) was very low on the priority list… but since it seems to be so important in this one case, I went ahead and fixed it.

-J

I’d also like to point out something here… Just because V5 does something, doesn’t automatically mean it’s the defacto… I could argue for quite a while why analysis modes should override an object’s material completely instead of partially… There are all kinds of things that V6’s display does now that V5 doesn’t, and the parts that are different from V5 are not automatically considered “wrong”… I’m now waiting to hear how this latest fix has now broken the expectations of some other user…

Thanks,
-Jeff

Thanks Guys, now it works in the latest build available.
I’m glad that I can use Rhino 6 now.

@jeff , thanks for wending ahead the prioritylist!

Daan

@jeff In addition to the issue, the transparency on NURBS surface with analysis works fine, but with a unselected mesh with draft angle analysis, there’s again no transparency.

When the mesh is selected, then there is transparency on the mesh with analysis. Is there a possibility that this will also be fixed? Maybe the same issue? Thanks again.

@daan.eke I’m not seeing that here…the object(s) remain transparent during analysis, selected or not. What display mode are you using? Have you made any adjustments to your display mode(s)? If so, which settings?

I know it’s probably pretty simple to repeat there, but an example 3dm means we’re working with the exact same thing.

Thanks,
-J

@daan.eke Never mind… I’m seeing it now… It turns out the objects are transparent…but for some reason when it’s a “mesh” object, the order they get drawn in is wrong…which means any objects behind them will be occluded…ruining the “transparency” effect.

I’ll fix it.

Thanks,
-Jeff

Allright, looking forward for the new release. Thanks!

@jeff Sorry, i hope that I’m not irritating. Can you test one more thing? (I think also a draw-order issue).
When I have a _Picture with a patch surface with analysis laying above this picture, the controlpoints that are above the picture are not visible. This is only the case with the draftangle analysis active.

In the image you can spot the problem. Left no controlpoints, right controlpoints normal visible.

I hope that you can also fix this :slight_smile: Thanks in advance.

Hey @daan.eke, no worries…it looks to me like Rhino is the irritating one :slight_smile:

I haven’t tried this yet, but my guess is that this is exactly the same problem I mentioned above…something is causing analysis mode’d objects to get drawn out of order… I just need to find where and why. I haven’t yet, but it’s on my list (with a higher priority this time :wink: )

Thanks,
-Jeff

Hi Jeff,

Is there any sight on a solution for the problem as mentioned above?

Thank you,

Daan

I do not see this here, if I understand…


Wiggly surface is above/closer to the camera than the Picture object.

-Pascal

I know what he’s referring to… When looking up from underneath the picture object, the CPs of the analyzed surface are blocked by the picture…However, if you happen to be looking up through part of the analyzed surface, then CPs above the picture are then visible… Clearly the “Picture Frame” object behavior is causing this, since I don’t see the problem with just a texture mapped plane with SetObjectDisplayMode=Rendered…which is basically all _Picture is.

I’m looking at this now…will let you know when it’s fixed.

Thanks,
-Jeff

Yes…working on it now… However, if it’s really a show-stopper for you, a workaround is to simply stop using the _Picture command, and just draw a plane…set it to always “Rendered” using the SetObjectDisplayMode command, then assign a material to the plane using the desired texture you would have used as the _Picture command.

There is something very specific about how a _Picture object is being dealt with that is impacting the depth buffer tests at the wrong time… but as I mentioned, if you simply use a texture mapped plane and SetObjectDisplayMode=Rendered (which is pretty much what _Picture does), then the problem goes away.

So either use the workaround for now, or wait a day or so to pick up SR13 WIP.

Thanks,
-Jeff

Hi Jeff,

Thanks for your help in the mean time.

When I add a normal plane and set the texture, like you mentioned, the problem persists in the same way.
So that is not an option for me.

I’m hoping on a definitive solution, thanks.

Daan

.

Hmmm…well then maybe we’re talking about two different issues… The best way to make sure we’re looking at the exact same thing is to provide a 3dm file that demonstrates the problem, along with a screenshot that shows us what you’re seeing.

So to clarify the two problems you’re experiencing:

  1. Working with transparent materials, an unselected mesh object using DraftAngleAnalysis is rendered opaque, but selecting the mesh object renders it fine.
  2. Working with a Patch surface using DraftAngleAnalysis, when the surface is above a _Picture object, and the surface’s control points are ON, the control points are not visible when viewing them from underneath the _Picture object (i.e. you’re trying to look through the _Picture object, at the surface’s control points).

I can easily reproduce 1 and will fix that…but #2 seems to be questionable now… Is transparency involved in #2 as well? Please provide a simple example that is saved with the camera positioned correctly and display mode set, along with an explanation on which surface needs to have DraftAngleAnalysis…so that all I need to do is load the file, select that surface, run DraftAngleAnalysis, and turn its control points ON to see the problem (i.e. no view manipulation required)…as well as a screenshot of the problem so that we can see what you’re seeing.

Thanks,
-Jeff