ChangeQueue.MeshInstance GroupId/MeshIndex problems in v8

Rhino Developer
, , ,
1

In ApplyMeshInstanceChanges when running in v8, MeshInstance.GroupId seems always to be UInt32.MaxValue, and MeshInstance.MeshIndex seems always to be 0.

I have used GroupId/MeshIndex in v6 & v7 for identifying when separate meshes given to the ChangeQueue are part of the same logical mesh (e.g. 6 faces given for what the user sees as a box extrusion, and what I must export as a single mesh), and implementing sub-object materials.

Though the various IDs on MeshInstance are documented, it is not clear what the documentation actually means. i.e. what is a MeshInstance ancestry, and what do the various RootId/ParentId/GroupId/MeshId properties actually represent, so I do not know if I might be able to use some combination of them in lieu of GroupId/MeshIndex, or whether it is an oversight that GroupId/MeshIndex are not being set as before.

MeshInstance docs

Below are the results of printing the values of these properties in v7 and v8, for a file containing a box extrusion with sub-object material assigned to the top face.

RootId/ParentId are not present when running in v6, and in v7 the RootId matches the MeshId, and is the same for all faces, with GroupId also being the same for all faces, while the ParentId is just Guid.Empty. MeshIndex returns indexes 0-5 as expected for each face.

In v8, RootId remains consistent for all faces of the box, and matches the RootId from v7, but MeshId is different for each face, GroupId returns UInt32.MaxValue for all faces (not just for one box, but for every mesh in the model, apparently), and MeshIndex returns 0 for all faces (also for every mesh in the model).

box extrusion in v7:

-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    1262210833
InstanceId: 614957360
MeshId:     962f5b09-f369-4a1b-851f-1450bfe74192
MaterialId: 140370497
MeshIndex:  2
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    1262210833
InstanceId: 2619074133
MeshId:     962f5b09-f369-4a1b-851f-1450bfe74192
MaterialId: 140370497
MeshIndex:  3
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    1262210833
InstanceId: 3111172489
MeshId:     962f5b09-f369-4a1b-851f-1450bfe74192
MaterialId: 2921531358
MeshIndex:  5
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    1262210833
InstanceId: 30203628
MeshId:     962f5b09-f369-4a1b-851f-1450bfe74192
MaterialId: 140370497
MeshIndex:  4
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    1262210833
InstanceId: 2393786811
MeshId:     962f5b09-f369-4a1b-851f-1450bfe74192
MaterialId: 140370497
MeshIndex:  0
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    1262210833
InstanceId: 907161310
MeshId:     962f5b09-f369-4a1b-851f-1450bfe74192
MaterialId: 140370497
MeshIndex:  1

box extrusion in v8:

-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    4294967295
InstanceId: 238399426
MeshId:     39e4820c-d421-49b1-b334-b3cac4b722c4
MaterialId: 3482931093
MeshIndex:  0
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    4294967295
InstanceId: 2333606099
MeshId:     d9d4faf1-5cf7-472f-89bd-2d5e7026a329
MaterialId: 3482931093
MeshIndex:  0
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    4294967295
InstanceId: 2422992428
MeshId:     98a57787-91ee-41a4-b75f-2b4da5b93f5b
MaterialId: 3482931093
MeshIndex:  0
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    4294967295
InstanceId: 2111537023
MeshId:     41bb8a9e-c43a-4c0c-8d2a-c6a2b3fb539f
MaterialId: 3482931093
MeshIndex:  0
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    4294967295
InstanceId: 3767030726
MeshId:     8b35d795-f07a-4147-a750-f5be4023f84c
MaterialId: 3482931093
MeshIndex:  0
-----------------------------------------
RootId:     962f5b09-f369-4a1b-851f-1450bfe74192
ParentId:   00000000-0000-0000-0000-000000000000
GroupId:    4294967295
InstanceId: 3995626916
MeshId:     e9240e45-5ec8-4dc5-aa96-5c4314fdacd4
MaterialId: 628958114
MeshIndex:  0
3

JD - I’m on the road at the moment. I’ll take a look when I get back.

Andy

1 Like
4

Logged as RH-70636 Group/Mesh ID behaviour changed from Rhino 7

1 Like
5

JD

Yes - the behaviour has changed in V8. Mesh groups are deprecated and not actually used.

  • Andy
6

Thanks Andy. Could you please write a little bit about how InstanceId, MeshId, ParentId and RootId relate to each other, and what the docs mean by a “Mesh Intance ancestry”?

1 Like
7

Instance ancestry refers to block instances and definitions. The ancestry is essentially a list of IDs that specify which block instance the mesh is part of. Because this is recursive (block instances can be inside blocks), the list runs from the MeshId (which is the actual real object), up through the parent (which is going to be the UUID of a CRhinoInstanceObject) up to the top-most instance object that’s actually in the document object list.

So a mesh instance has a parent - which is the immediate instance of a block that it’s part of. And the Root is the top level instance.

The data is typically used to figure out the “By Parent” attributes of the mesh.

1 Like
8

Is it possible to get the full ancestry list in the ChangeQueue for a given MeshInstance in v7?

9

No - sorry, it’s not. That’s an oversight in V7. It will be possible in V8.

10

Thanks Andy, that helps – I had not known how much some of this was referring to concepts invented for ChangeQueue, and how much it referred to actual traditional Rhino objects.

11

this new way is quite a step back if your renderer cares about objects being represented how the user regards them – for multi-material objects, we are now getting all the faces separately, and then getting instances of them separately as well, and this does not work in some renderers (many?) the same as a single object with multiple materials (typical example would be something like assigning frosted glass material to the edges of a glass table); and even if not, the user does not want to see that once they get the model exported from rhino

so I have to merge meshes belonging to the same object, and then when asked to create instances of them, categorize by instance definition & by the objects within them, to decide which merged/reconstituted meshes actually to instance, so I need a lot of structure built in memory just to be able to do this mapping; then it is a bit more fun again, when deleting instances, since I just get a list of hashes, which bear no relation to my actual instances, so yet more bookkeeping (I assume I will always get the full list of hashes for instances of the faces of an object, but what if the user deletes just one face?), all amounting to a lot of code running all the time, looking through structures mirroring the structure of the whole model, only because rhino is now handing us “exploded” meshes/instances when the objects have multi materials

imo it would be better to have the single mesh, along with its material, and optionally-populated list of materials & their indexes for each instance, to override the main material

anyway, just reporting since you should know how things look from a different point of view