Problem with ApplyMeshInstanceChanges and linked blocks

Hi,

when I double click a block element that consists out of two cuboids and move one of them to modify the block I run into this problem:

  • 2 cuboids (mesh defs X & Y and mesh instances x & y) exist in a linked block
  • I double click the linked block
  • 2 mesh defs. are created (A & B)
  • 2 mesh instances are created (a & b)
  • I move one cuboid (X,x) around and confirm the operation
  • 4 mesh defs are reported as added or changed (A, B, X, Y) two of them are reported as deleted at the same time (X, Y)
  • 4 mesh instances are reported as added or changes (a,b,x,y) two of them are reported as deleted (x,y)

In all of your examples and the RhinoCycles renderer you remove the elements that are added and deleted at the same time from the “deleted” elements but here it seems to differ from the usual way of handling things.

What is the correct approach to work with the API in this scenario? Currently, I end up with 4 cuboids instead of 2.

I do see irregularities here, I’ll investigate closer before I can say how this is supposed to work.

There are already problems just in Rendered mode.

  1. Add a box
  2. Switch to Rendered mode
  3. Set material to By Parent
  4. Create a block of the box
  5. Set block instance to a different layer with a simple material (i.e. red plaster)
  6. Set block instance material to Layer Material
  7. Double-click block instance, or with it selected use _BlockEdit
  8. Select box and move it a bit
  9. Confirm by clicking OK in the BlockEdit dialog
  10. Move block instance

After the last step you’ll see that the block instance material gets reverted to Default material from Layer material.

I’ve logged this as https://mcneel.myjetbrains.com/youtrack/issue/RH-47128

Thanks for logging the issue. I’m curious what causes this and initially assumed that the error lies somewhere on my end.

I heard that there is some event problem in the core somewhere. I’m waiting for @andy to let me know what YT issue it is, so I can add any further findings.

Hello @nathanletwory, did you hear anything new yet?

We are currently restructuring our plugin for Rhino6 to support more of your features like the edge softening and decals etc. The change queue is perfect for what we’re doing and the linked-block support is currently the last “roadblock”.

There seems to be a good idea of what the bug is. The YT item I reported is linked to a related item, that just might fix most if not all of the seen block trouble.

Great, thank you! Is there a rough estimate on when this is going to be released?

If the bug gets fixed in the next two weeks it’d appear in 6SR8 release candidate when 6SR7 is released near the end of this month. If not then possibly sometime August.

That is of course if all schedules hold.

Perfect. I’d also be very happy to test these changes if a preview/beta is available at some point prior to the offical release. Thanks again.

@nathanletwory sorry for warming up a 2 week old thread but I’ve checked the issue that you opened up for this case and judging by the comment that the developer provided he was unable to reproduce it.
Obviously, I haven’t got the user rights to add comments to the issue so could you please add my “repro case description” to the existing issue? Maybe it’ll help.

I know this might not seem like a huge issue but we simply cannot use the new changequeue-based implementation until the problem with linked blocks is resolved and this is blocking support for several Rhino features on our end.

Thank you.

@ParanoidAndroid I am out on vacation until mid-August. Maybe @andy can move the necessary information around.

Note that recreating the changequeue (for Raytraced toggling to other mode, then back to Raytraced) should give you a scene representation that doesn’t have the multiple defs.

Thanks for the reply, enjoy your vacation. :slight_smile:

@ParanoidAndroid I’m not sure what information I should be moving into the bug. I don’t see a “repro case description” anywhere.

  • Andy

At the beginning of the thread:

When I double click a block element that consists out of two cuboids and move one of them to modify the block I run into this problem:

  • 2 cuboids (mesh defs X & Y and mesh instances x & y) exist in a linked block
  • I double click the linked block
  • 2 mesh defs. are created (A & B)
  • 2 mesh instances are created (a & b)
  • I move one cuboid (X,x) around and confirm the operation
  • 4 mesh defs are reported as added or changed (A, B, X, Y) two of them are reported as deleted at the same time (X, Y)
  • 4 mesh instances are reported as added or changes (a,b,x,y) two of them are reported as deleted (x,y)

In all of your examples and the RhinoCycles renderer you remove the elements that are added and deleted at the same time from the “deleted” elements but here it seems to differ from the usual way of handling things.

This is an additonal (different) repro-case for the behaviour that Nathan has already reported but your collegue was unable to reproduce.

Done…although those steps are in the original thread, so it’s likely the dev looked at those too. Just for kicks, I added a reminder in the bug.

You should be able to add comments BTW - if you create a YT account.

Thanks!