I am reading blocks from the rhino document, modify them and write them back to rhino using elefront and human.
however, although the names of the blocks that are written from GH to Rhino are identical to the ones that are initially read from Rhino, I end up with more and more blocks piling up in the BlockManager.
so they are not “replaced” but saved under a version with an higher number appended to the end.
how can this be avoided, or do you know a way to delete the blocks from within GH after their content has been read into GH?
I found this, but my scripting is not at a level that I could pack it into a GH node…
maybe someone has clue, would be great
cheers,
Daniel
it is quite hard to explain… I will post the definition here once I have time to go into the details.
basically it can happen that I read in instances of the same block, that upon output need to have a unique block name because they hold other values. that leads to a kind of cross referencing of the block names and the total block count…
I am working on a definition for automatically updating height marks, depending on a variable ±0.00
the block consists of the mark and the number (text object).
the tip of the mark is the basepoint, which I use to read the location in space.
you can copy an existing block, and move it to the point you want to measure. when you update the definition the text object will update to the correct height.
good foresight
In the end I dropped the text tag inside the block… it was a bit tricky to get the text aligned because it needs different positioning for the 4 types of marks.
So I added a noprint layer for holding the points that position the text.
seems quite robust and fast now.
but I noticed that the elefront plugin does not filter points that come from exploded blocks.
it can only filter referenced points, so I am using a quick&dirty way for now to get that done.