Generating Excavated Block-field Help

Hey everyone,

I’m currently in the middle of a ‘virtual field season’ with the American Excavations Samothrace. I’ve been using rhino for a long time, but I’m very rusty with GH.

In our database we have the find spots and general dimensions of the nearly 1800 blocks that belong to the ancient Stoa on Samothrace. I’ve rigged up a component to plot the coordinates of the find spots in relation to the excavated foundations. I have also added a component that builds the blocks corresponding to their find spots.

I’ve attached a screenshot of the 622 wall blocks (not including architrave, frieze, or cornice.) What I’d like to do is add a random rotation to each block in x,y,z to make a visualization imagining the wall as it would have looked recently collapsed.

This is well beyond my skill set, and I am wondering if any GH experts out there have suggestions. Should I try to do something like this Kangaroo? I don’t want any of the block geometries to intersect.

I’d then like to add these ‘fallen’ blocks back to my ghosted reconstruction model.

Thanks in advance!

This is very easy(?) or very tricky since is related with some sort of “collapse aesthetics” (so to speak).

I mean that is more than possible to get a random rotation that points to bananas rather than ruined parts of buildings.

So the ideal/pro solution is NOT to rely on random rots … but to deal with the collection interactively on a per module basis (including clash checks and/or some help from K2 to speed things up - since K2 can handle collisions and gravity). Or … well … you can attempt to deal with each module solely via K2 (not recommended mind). Anyway I could provide in depth explanation on that if required.

Plus: you should create “variants” of solutions (i.e. manage a history of your actions/results) and being able to pick the collection(s) that “look” more realistic. Obviously is pointless to teach a computer what is a “realistic” ruined building.

This interactive (+ K2) procedure is easy with code (C#) and rather impossible via components.

As I said: very easy (most unlikely) or tricky (if you are not familiar with coding).

That said Daniel includes some examples on collisions/gravity on each K2 update/upgrade … but this case begs for more.

BTW:

Practice is closed (and sealed) for the summer but I found in some pathetic laptop a simple collision example by Daniel for K2 242 (Note: I don’t work with R6/7 so the latest K2 builds are not available).

Daniel treats Breps as Meshes for more than obvious reasons. As you can see this approach MAY be used (in tandem with some interactive re-placement) in order to approximate some realistic result … blah, blah.

rigid_mesh_collision.3dm (1.4 MB) rigid_mesh_collision.gh (17.4 KB)

And these have some fun:

solidParticleCollide.gh (15.5 KB)
floorcollide.gh (8.4 KB)

Ah, thank you so much for your response, and for sharing these examples! It might be that this is well above my coding experience, which is closer to none. But thank you for the suggestions and for sharing these. Maybe I’ll be able to approximate the effect I’m looking for with some hard work. In the end, I might just need to rely on drawing. Just for fun, I’ve attached a screenshot from the first plan made of the sanctuary on Samothrace by french engineers in 1866 who came back after the discovery of the Winged Victory. You can see that the chronicle the fallen wall blocks in the same general area (the blocks at the other end were dragged down the hill to construct a Byzantine fort)

Thanks again for your help!

Er … hmm … if you call this help then you are indeed very polite, he he.

But the truth is that this case (if you are after a pro level result) is not that simple. I estimate that requires about one weak (better safe than sorry) of coding for some acceptable and “realistic” result.

But the attached is a poor man’s solution (using K2): i.e. define some static footprints + some variable and let K2 relax the collection (NOTE: K2 is a kind of physics engine (so to speak) … so requires delicate inputs while depending on wrong ones MAY yield bananas).

Collide2d_shapes_V1.gh (28.9 KB)

Then you can do various things with the Breps (if you toggle solid to true) in order to mimic ancient stones/parts etc etc.

I hear you: what is that ugly thing?

Er … is an ugly thing I confess.

UPDATE: here’s another poor man’s solution (the part that “cuts” the random Breps in order to look “like” (kinda) stones is not included - notify if you want it).

CircleFill_OnBrep_V1.gh (151.8 KB) CircleFill_OnBrep_V1.3dm (127.5 KB)

Another far more elaborated way could be to use portions of your building(s), do a recursive trim (resulting random pieces with a vast variety of ways) and then let K2 to relax them on the ground (pieces shown in a layout for clarity):

For instance:

An then:

best

1 Like

Well … let the idiot (the computer) to do that part. The attached is the fastest way imaginable to “lay-out” random Brep pieces randomly on some floor. If you are OK with no clash checks (i.e. avoiding the very slow K2 collision part) I could write a rather simple C# (maybe with some custom Goals as well) that does it properly.

Have in mind that if you are after some renderings noboby could tell if the pieces are exactly on the ground (due to a classic K2 collision solution) and/or they yield some ccx events between them.

This - obviously - assumes that you have the pieces of your buildings (as explained above) on hand - “packed” in their original position (like the grey demo breps that are packed in a box).

Brep__Spread_Cheat_V1.3dm (1.2 MB)

Brep__Spread_Cheat_V1.gh (25.1 KB)

Tip: toggle the K2 Reset and see what happens (you can use some displacement and/or volumetric rendering for realistic results etc etc)