Ping: "Custom Preview" still not working

For a demo project I need to put together a “dynamic model” in GH, but coloring (more than one color in Render mode) still doesn’t work (https://mcneel.myjetbrains.com/youtrack/issue/RH-63579).
And sometimes it shows (whatever color) while preview is disabled, and sometimes it doesn’t show at all, and…

Ping, ping.

Rhino 7 Render

Rhino 6 Render:

// Rolf

Rhino 7 latest (7.5.21096.11001, 2021-04-06)
Driver
image

1 Like

@nathanletwory, @DavidRutten; I just noticed that GH Custom Preview fails also for Display modes other than Render.

Apart from all Previews being the same, the below gif shows how some parts disappear when rotating the objects. This seems to happens for all display modes. This is getting serious… :wink:

You may want to add a link to this post to the existing Youtrack issue.

// Rolf

Hi Rolf -glad to see that I am not alone!! I had it working fine and then I updated to the latest service release of Rhino 7 last week, reminds me of why I hate updating anything! My shaded mode custom preview works fine, just not in rendered mode. Does anyone have any suggestions? I tried using new custom preview components in case they had changed, but no luck.
Thanks in advance,
Cary

1 Like

Avoid upgrading to R7 unless you enjoy beta testing and debugging?

Lol - thanks

Hi Rolf @RIL

This is now fixed in the latest 7.6.

-Jeff

1 Like

For reference here is the bug report: RH-63369 Display: Grasshopper preview in Rendered display mode.

I wish I had access to the sources so I could debug. :wink:

I don’t mind beta testing as long as the bugs are fixed. :slight_smile:

This will be just fine.

// Rolf

I have the latest R6 also on my machine, so I can do my recordings using that version if I want to. But Custom Preview had other issues in R6 (memory leaks etc).

But have faith - The mcneel guys will fix it, I’m sure. :sunglasses:

// Rolf

This problem was not fixed in the last release.

Just tested it again, and the crane goes bananas when rotated a little. All display modes affected (refresh gif above to watch it happen):

// Rolf


Edit: Ping, ping again, @nathanletwory , @pascal

The bug report I had linked was for the colors.

So R7/GH remains unusable for rotating objects until…? Back to R6 for this project.

(This is rotation via RotatePlane → X → Transform). If you already know about this problem, then ok, but if not, I might be able to make a small(er) example that fails, just let me know.

// Rolf

I don’t know if this particular one is known, but looks like missing update of bounding box.

Well, I don’t have access to the source code of your Preview Component so I can’t tell either

I’m not coding this in C#, yet.


Edit: Found the source of the problem

Hm, it seems I found the failing spot - It is the Transform component which fails to transform a (valid) input mesh, and so the output mesh is invalid (and thus not previewed correctly either).

Fig. The Transform component failing:

A stripped down example:
debug_crane_buggy_mesh_transform_00.gh (462.5 KB)

// Rolf

1 Like

I further tracked it down to the following:

The Brep->Mesh parameters outputs a valid mesh, but the Transform output mesh is corrupt failing on either DegenerateFaces or AlignVertices, or both.

When I fix either of the two problems the mesh goes “valid” again:

// Rolf

1 Like

The best performing workaround turned out to be to make a script component calling (only) the operation CullDegenerateFaces, like so:

  private void RunScript(List<System.Object> M, ref object M_fixed)
  {
    if (M == null) return;
    var objects = new System.Object[M.Count];
    var tol = RhinoDoc.ActiveDoc.ModelAbsoluteTolerance;
    Parallel.For(0, M.Count, i =>
    {
      objects[i] = M[i];
      // Try to fix only meshes
      if (M[i] is Mesh)
      {
        var mesh = (Mesh) M[i];
        mesh = mesh.DuplicateMesh();
        /*
        Attempts to remove degenerate faces from the mesh. Degenerate
        faces are faces that contains such a combination of indices,
        that their final shape collapsed in a line or point.
        */
        mesh.Faces.CullDegenerateFaces();
        /*
        The operation "AlignVertices" is way too slow for use
        for only fixing preview of bad meshing, so skip it as
        a workaround.
        */
        //mesh.Vertices.Align(tol * 100, null);
        objects[i] = mesh;
      }
    });
    M_fixed = objects; // output
  }

(Aligning vertices takes magnitudes longer time, so I skipped that for the WA).

// Rolf

Well…

and then …

Can you reproduce this with a simple box and a simple slider?
-wim

No. The slider isn’t connected (meaning, you could have cunningly just ignored it. It’s not involved.This was a HUGE definition, and some crap was accidently left behind when I tried to clean it up, for your convenience).

But the only param which wasn’t internalized (ops!)… is fixed. But s**t happens you know. New version attached below.

If the problem occurs for a simple box I don’t know. I also won’t try to find out in this particular case. For now I only care about reproducing what doesn’t work on this end. But you might try out all kinds of stuff if you find such tests being relevant for your product?

For your convenience I removed the slider, which wasn’t connected, and most important, I internalized the missing Brep:

debug_crane_preview_02.gh (2.3 MB)

// Rolf

1 Like

Frankly, I’m about 2000 threads and 5772 PM’s behind and most, if not all development of Grasshopper goes into Grasshopper 2 these days. If I ever get a few hours, I’ll try to wade through that file.
-wim

Sorry for doing the job for you about an ignored reported problem, in this thread, while doing a mistake (omission) when cleaning up a several hundred components big definition, for you convenience only.

I did this without anyone paying for it. No big deal, I did it gladly, but being snotty doesn’t pay off well to people trying to assist.

// Rolf

1 Like