It sure looks like the Floor.MovePoint code is rounding input numbers…
Well - I’ll be.
Floor.Move.Point is rounding input. That’s not good.
Banging my head against the wall for an hour on that.
Ok - so we do it the hard way.
It is shown as 100 but it may not be. Use Math.Round with Digits and as Digits input 10 or more.
No - it is screwed.
The 100 is spot on. I’ve looked at it in C# and Revi tLookup.
Here I add 0.166 to one point and move it up 0.000000000000001
Just jumps to a perfectly even 100.
Here I add 0.001 to the 100.1666 and it jumps back to 100.001
Clearly the node is truncating the 100.16666 to 100.
Just did a test on a variety of values. It isn’t doing a round - it is just discarding the decimal. Doing a flatten. 100.916666 and add 0.001 - returns 100.001.
Do after Point.Z a Math.Round with digits. You haven’t done, I said.
You said, I did.
And as you can see - it is rounding. Just like I said. If VisualStudio is telling me it is reset to 100.000000000000000 - then it is 100.
The node is hosed - it rounds.
Go try it yourself if you don’t believe me.
It is not about believing or not. Some nodes no like that and some don’t. In your Screenshots I could not see it.
I am using mac at home so I can’t test it. I cold do it via Python but maybe on Tuesday…
Yes - I can to it via the API. Works fine there.
The node doesn’t do what it needs to do.
I can’t even get this node to move anything, let alone incorrectly, but I did notice that it’s expecting a single point and a single offset. You can see by your output structure that it’s attempting to move each point by each offset individually (55*55=3025). Might be related, might not. Either way, I’d recommend specifying list levels to get the output you’re looking for.
No - the node takes a list just fine. You just need the same number of elements in each list. So in this instance the site surface is repeated in the list the same number of times as the number of points.
And they move just fine. But there are small inaccuracies that are introduced in the end result.
Test doing it in feet and see if there is a rounding issue still. If not, it’s a unit conversion issue in the node - I’ve seen these before with custom nodes before when a small value is converted and lost in the process due to place limits. It would also be one to raise via github also if it turns out to be a bug within an ootb node.
The Offset value is with respect to the floor’s origin, not it’s current point locations. You’re not moving the points up by 0.001, you’re moving them to 0.001. If your floor is drawn at a 100’ elevation, then an offset of 0.001’ would set them to 100.001’. This is why you’re seeing “rounding”. You’re using values way beyond the precision of Revit, so 0.00000000001 gets rounded to 0.
2 Likes
The API offset is relative to the object. True.
But for this node - it moves the point relative to their current location. If it is at 100 and you apply an offset of 100 it will have a Z of 200, unlike the API.
You’ll see in this image I previously posted, point 54 is at 100.166. I add 0.001 to all the points and they all move to 100.001. Including point 54 which should read 100.167.
I can do the exact same thing with the API - and it works perfectly. Point 54 reads out 100.166766666667 just as it should.
Yes - if things were just off by - 0.00000000001, that would be floating point rounding. But in a file I was testing, I was seeing discrepancies of half a foot in the end result. Otherwise I wouldn’t have noticed an error. That can’t be simple floating point errors.
I’ve at this point, tried it on several floor slabs in several different files and I’m getting very inconsistent results. So I’m not sure what is going on and haven’t been able to find what the issue might be.
For now, using the API works consistently and perfectly fine on all the files and test slabs.
It moves the offset relative to the element’s local origin.
That’s because your floor’s origin is at 100’. So offsetting the floor points by 100’ is still 100’ above the origin, which ends up being 200’. I don’t understand how this is different from the API though. You’re saying the API adds onto the existing elevation which would still be 200’.
This is exactly my point. Your floor’s origin is 100’, so when you set the offset to 0.001 the new location is 100.001’. If your floor was drawn at 0’ then the new location would be 0.001’.
1 Like
I think I’ve tracked down the issue.
The node is ignoring 0. Which means you can’t reset the slab points to a flat slab with this node alone.
here’s a simple move +100. Works as expected.
Now to reset with 0.
Note points remain at 200.
Now to input 0.001.
Everything moves to 100.001 as expected.
I think this combined with other things I was doing was giving the appearance of rounding.
But the API does take a 0 just fine.
So with just the nodes, you would have to copy out the points, reset the shape, re-enable the ShapeEditor and copy the points back in. But that has resulted in some odd things as well and seems to be a issue open in GitHub #1789. (I’m in R2020 as the military is way behind in versions.)
The API take 0 as an input just fine and does what is expected.
def floorMovePoints(myFloor, myOffset):
TransactionManager.Instance.EnsureInTransaction(doc)
slabeditor = SlabShapeEditor
mySlabs = []
myCoord = []
for myFloor in mySelection:
if myFloor.SlabShapeEditor.IsEnabled:
mySlabs.append(myFloor)
vertexArray = myFloor.SlabShapeEditor.SlabShapeVertices
for vertex in vertexArray:
myCoord.append(vertex.Position)
slabeditor.ModifySubElement(myFloor.SlabShapeEditor, vertex, myOffset)
TransactionManager.Instance.TransactionTaskDone()
return mySlabs