object listing post Separate

Next
 From:  James (JFH)
8219.1 
Hi Michael,

Is there a formula for the indexing of sub-objects after they have been exploded with "Edit/Separate".

Attached is a grid array indexed as descending rows, that has been "Edit/Join"ed then separated. The new indexing of objects does not appear to be totally arbitrary (at least at first). I have numbered the pre-joined sequence in BLACK & the post-separate in RED.

Would it be possible for a script to re-instate the original sequencing? My application is for addressing objects in node editor. I'm not asking for said script, only as to its feasibility.

Regards, James



Attachments:

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
8219.2 In reply to 8219.1 
Hi James, well one thing that's a little complex with it is that Separate can take in curves, faces or breps as input objects. For faces it will break the faces off of the brep but any faces that were touching each other remain in joined clumps.

So for example if you have a box and you select 2 adjacent faces and run Edit > Separate on it, it will break off those 2 as a joined surface, not as individual surfaces yet, but since it's now an independent brep and it's selected you can run Separate on that kind of selection to then break it into individual surfaces.

Do you care about that face sub-object selection behavior of separate or only the curve and brep behavior? The face selection part could get pretty complicated to document in the case where the faces from one brep form multiple disconnected chunks.

- Michael
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  James (JFH)
8219.3 In reply to 8219.2 
Hi Michael,

To better explain my query it might be instructive to show you what I am trying to achieve.
Attached is 2 nod files: I have separated the nodes into groups to make the wiring diagram more comprehensible. Here we are only concerned with the bottom dozen or so nodes that generate
faceted arrays for flows.

In the first node file "Loft>Separate>Offset.nod" there is the original "Loft" (Style:Straight) and "SeparateObj" and then a second array of surfaces that are an Offset of these. However this means the offset tessellation is no longer contiguous.

To ensure close packing of the outer base surfaces requires offsetting the loft prior to separating.
Unfortunately doing so results in the loss of sequential indexing leading to the undesirable result shown in the second image.

Despite the faces of the offset loft adjoining similar to those in the original loft; when they are separated they are indexed in a the manner shown in the image of my initial post.

James



Offset>Separate.jpg" />


Separate>Offset.jpg" />

EDITED: 14 May 2019 by JFH


  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
8219.4 In reply to 8219.3 
Hi James, I read your original question more carefully, and it looks like you want a separate followed by a join to have the same sub-object ordering as the original pre-separated object? Unfortunately I don't think there will be any reliable way to control that, the join process does not try to preserve ordering, it just combines faces into one brep and then goes through unjoined edges, comparing them to other unjoined edges, gluing them together if they are within tolerance. It's not surprising that some traces of the original order will remain but I don't think that it's going to be reliable.

One thing that might work for you though is to track things by setting object names on sub-objects. For example if you assign a unique object name to each edge of the original object, that name will come through the separate and rejoin process and so if the name was the index value in the original object you could recover the original index that way. I think that should work for both face and edge sub-objects.

- Michael
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  James (JFH)
8219.5 In reply to 8219.4 
Hi Michael,

I can understand why the ordering objects may not be preserved after joining and then separating. But in the instance of the node files attached to last email:
a lofted surface Loft/Style: Straight when separated breaks into an array of surfaces
that are indexed sequentially in rows as would be expected.

However applying an Offset to the lofted surface, prior to separating, will result in a disordered indexing of objects.

>>One thing that might work for you though is to track things by setting object names on sub-objects.<<

I can see how it might be possible automatically generate names for each new object after separation and catalogue them in order. Then if they become disordered by the application of joining & separating or offsetting, the original index could be reinstated as per object catalogue.

Anyway, thank you for responding to my query.

All the best with your work on V4. You seem to be edging ever closer

Regards James
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  James (JFH)
8219.6 In reply to 8219.4 
Hi Michael,

I manager to achieve the desired result by splitting array of facets into alternating rows (idxSelect), then joining (Join) each of the new arrays, bundling (bundleArray)& joining again (Join) then offsetting (Offset) and finally separating (separateObj).

It seems like a circuitous route but it ensures the original ordering is preserved.
It would not have occurred to me, had you not explained the operation of these processes.

So thank you, James




Attachments:

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
 From:  Michael Gibson
8219.7 In reply to 8219.6 
You're welcome James, your result is looking good!

- Michael
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged
 

Reply to All Reply to All