Create floor through API with "holes" in footprint

1

Hello all,

I’m attempting to use this method to create a floor.

My desired floor is the area between the two outlines (same as if these lines were creating a floor footprint w/ the ui).

image
image.png1078×1102 5.56 KB

The arguments for the method calls for a “CurveArray”.

If I use the curves from either the outside or inside outline the floor is created correctly.
When I attempt to use all the lines in the CurveArray I get this error:
image

Here is my code:

image
image.png726×452 25.4 KB

Does anyone know of any solutions to achieve what I am attempting to do?

Thanks in advance!

2

Just discovered these two blogs:


Looking into them now, will update if I solve on my end.

3

The solution is creating a NewOpening object which Jeremy summarizes as:

  • There is no way to create an exact copy of a floor with holes using API as in the UI.
  • There is a workaround to create holes in the floor using openings instead.

Creating a NewOpening requires more than one transaction which makes it not possible to create the floor & the opening in one run of the Dynamo script with python nodes (please correct me if I’m wrong)

4

Use the Transaction.End and Transaction.Start nodes and you should be able too. Or if in Python you can use manual transactions similar to API. Should be possible for sure.

2 Likes
6

I did manage to get it to work. I don’t fully understand the order of transactions that occur through Dynamo, especially the ones executed in python nodes.

I was unable to have the transactions creating the floor & opening occur inside my python nodes. I tried several variations including seperate python nodes as well as using SubTransactions but I couldn’t get this to work.

Instead, I took your suggestion of using nodes and had success with this graph
image

Upon running, it appears that the transaction started by the nodes runs first as I see the floor placed in my model first, then all my other transactions (including the one for creating the NewOpening object) seem to occur and get placed in the model at the same time.

When using undo inside my model I notice that the floor created by the node transaction is a seperate undo as the others which are grouped in the same undo. Although this isn’t a technical way to explain as I don’t yet fully understand this area, I hope it helps someone who may encounter similar situations.

I may attempt to recreate my graph in the future with C# and I believe the transactions will be more straight forward in that approach.

1 Like
7

The Transaction.End and Start should be swapped in order, and the Start should feed into the Opening Python node. What your trying to do is End the transaction (regenerate) the floors, then Start a new one for the Opening.

1 Like
8

If one were to do something like this, would it be redundant?:

t = Transaction(doc)
t.Start()
# do stuff
t.Commit()
doc.Regenerate()
1 Like
9

Not redundant at all, this is how you would do it if you wanted to put it all in one Python script. You could even use sub-transactions under one actual transaction. One thing is that you may need to force close the standard Dynamo transaction to get this to work. That’s why I think the OTB End and Start are a safer option, but not the only one.