DrawMeshFalseColors v6 bug

,

Hi @jeff, could you please run one of the two python scripts i uploaded in post 27 and 29 and check if you see something in the rendered display at all using V6 ? In V5 both scripts show the cube array in any displaymode, in V6 it fails in rendered display over here.

_
c.

Seems to work…but the ground plane also seems to be interfering with most of it… If you turn the ground plane off, then everything draws… It also looks like there some kind of mis-calculated scene bounding box, which is impacting the near and far clipping planes.

-Jeff

It doesn’t look like your script is calculating the scene bounding box correctly… It needs to be the accumulation (Union) of all meshes and their bounding box. So either you’re not doing that, or I’m missing something.

-J

@jeff comment 52 has the code that produced those screenshots. (And yes I consider DrawMeshFalseColors a request to draw an unlit mesh. :slight_smile:)

As an aside, technically the two compute-normal lines in that code are not needed, but I presume this is because Mesh.CreateFromBox() computes them automatically.

Hi @jeff, it was indeed the groundplane.

_
c.

HI @Jeff, V5 does not do this so i would say this is a V6 bug. Btw. my bounding box is calculated correctly in both scripts.

_
c.

Hi Clement,

V5 doesn’t have the ground plane ON by default… My guess is that if you turn the GP on in V5, and then run your script, you’ll see similar behavior.

-J

@jeff, so would you say that behaviour with the display conduit and the groundplane is desired ? I think not. You may add this line to one of the above example scripts under PostDrawObjects to see the bounding box my conduit uses:

e.Display.DrawBox(self.BBox, Color.Red, 2)

Even if i inflate this bounding box by 10000 units, the mesh boxes are not drawn properly. The clipping applied by Rhino when the groundplane is ON is wrong. Below shows what happens if i turn it ON, red is my Bbox.

ClippingGroundplane
_
c.

Clement,

I’m not saying that nothing is wrong… I’m only answering your questions or replying to your statements.

The scene bounding box is obviously not getting calculated correctly…whether it’s something you’re doing or something the pipeline is not doing is the real question. Your script may be doing everything correctly…but that doesn’t mean Rhino is…

The ground plane is a tricky feature…it’s more than just drawing a plane, because in order to see as much of the “ground” as possible, it means the near and far clipping planes need to be set to very small and very large values respectively… But doing that means that you’ll immediately lose all of the resolution in the depth buffer and everything in between will look wrong. So the planes need to only pay attention to objects in the scene, and then, only those that you’re able to see given the current camera… Then the rest of the ground plane needs to be drawn without affecting the depth buffer.

As far as I can tell, the objects in your script are not properly being applied to the overall scene bounding box. Try placing a “real” object out at a far distance, beyond all of your boxes… My guess is that everything will display correctly…that’s because Rhino knows about the “real” object, and sets the clipping planes accordingly… If that works, then that tells me that something is either broken with the scripting calc bounding box mechanism, or it’s being applied at the wrong time or place.

I’ll try to dig further into this later this week, but I can’t do it right now… @stevebaer might know why the scripting aspect of CalcBoundingBox could be failing, but as of right now, I have no idea what that would be.

-J

Hi @jeff, i think you nailed it. When the groundplane is turned ON, it does not include the boundingbox of a running conduit but only the bounding box of the objects in the document. If the document is empty, the boundingbox is calculated to small.

_
c.

Hi Steve,

Has this been fixed yet? I see no new options in the SDK for turning off lighting when calling DrawMeshFalseColors. I hate to repeat myself, but the unlit version should be the default behavior in Rhino 6 (as it was in Rhino 5). Any idea who asked for this in the first place? At any rate, it’s really wreaking havoc on data display in our simulation software, and there’s little I can do on my end to work around it.

Thanks,

Jon

I thought @jeff had fixed this, but I haven’t really been tracking too close. It may be in the latest service release candidate that we put out today.

YES! Just updated to 6.9 and falsecolors look great again. :slight_smile: Thanks @stevebaer and @jeff!

@steve @jeff i thought i won’t put new topic since this is kinda related - is there a way to get per vertex colored wireframe in display conduit override?

Not without some work. What would this look like?

– Dale

@dale well this should basicaly look like line gradient from pt A with color A to pt b with color B - this isn’t crucial it is rather fancy thing i would use it to color mesh with underlaying texture like im coloring mesh calculated on fly:

We do have an OpenGL component for grasshopper that would allow for this, but nothing in our core SDK.

@stevebaer GH is not my case at all. Decide on your own guys for me it would be pretty useful but this time as i said it isn’t crucial thing - i think. However this is very crucial for me - GetMeshes after modifiers like rounded edges or displacement?

Hi @Dale, @Alain,

i see that the fix you provided to Mesh.Append() for Rhino 6.8 did not make it into RhinoScript syntax for python rs.JoinMeshes() method yet. It still uses this code and appends meshes one by one which is extremely slow:

meshes = [rhutil.coercemesh(id,True) for id in object_ids]
joined_mesh = Rhino.Geometry.Mesh()
for mesh in meshes: joined_mesh.Append(mesh)
rc = scriptcontext.doc.Objects.AddMesh(joined_mesh)

_
c.

Got it, thanks.

https://mcneel.myjetbrains.com/youtrack/issue/RH-49382

– Dale