Il grande Jeremy Tammik di The Building Coder
mi ha fatto l'onore di pubblicare sul suo blog il mio codice relativo al View Depth Override sia per viste 2D sia per viste 3D.
Nei commenti, un lettore di nome Ning, ha delle perplessità riguardo alle coordinate che ho utilizzato nel codice, questa la mia risposta nel tentativo di dipanare i suoi dubbi.
E' una breve storia (ancora non conclusa per altro) del processo che mi ha condotto a determinate scelte per impostare il codice, la scrivo in inglese (perdonate gli erroracci) ma se qualcuno non capisse posso tradurla in italiano nei commenti... ogni aiuto o suggerimento in tal senso è ben accetto!
Questo quanto chiede Ning:
"hi Paolo and Jeremy,
i'm trying to understand that 3DView Depth Override stuff, by using my own simplified code, works OK for plan / section / elevation views, but i have trouble to understand the coordinate system in terms of relationship between 3DView's Cropbox and Outline used in BoundingBoxIntersectsFilter, i assume the followings:
1) Boundingbox of 3DView's Cropbox is in coordinate system on top of the computer screen in which Z is perpendicular to the computer screen
2) Outline used in BoundingBoxIntersectsFilter is in Revit coordinate system
a bit description in your blog will be great, perhaps Jeremy can give a more technical detailed explanation in the future"
Questa la mia risposta:
sorry for the late reply, I'll
try to make myself clear about what you're asking.
When I tried to code this macro I was
at the beginning of my "API journey" and I'm sure I
wouldn't be making the same choices if I had to do it again from
You're assumptions are correct: View
BoundingBox has to be transformed into absolute coordinates to work
properly as an Outline.
All started with 2D views: view
coordinates are realtive to each view and there are three vectors
defining the space: the RightDirection (let's say local x axis), the
UpDirection (local y axis) and ViewDirection (local z axis, which is
orthogonal to the screen as you mentioned).
That said, I guess one can obtain the
Outline necessary to the BoundingBoxFilter from here, taking a
shortcut and simplyfing the code a bit, but still, you need to
convert from local to absolute coordinates to build a proper Outline.
This is also important to implement the
subfunction called "Integral", which collects all
ElementIds in a series of smaller BoundingBoxes (200 subdivisions for
each one of the three segments of the main BoundingBox), because in
case of views that are not parallel to the edges of the screen, a
single BoundingBox would generate errors in the selection.
When I began to study a macro for 3D
views I decided to restrict the code only for perspective views
because that made more sense to me; I tried to reuse as much as
possible the code I had for 2D views, but I took a different approach
to determine the Bounding Box: I choosed to consider the entire
Bounding Box of the model (this is the part where Jeremy's blog comes
in), then I rotated (it's better say projected, transformed) this overall BoundingBox "parellel" to the
perspective view (but keeping the top and the bottom faces parallel to the ground) and then execute the same code for 2D Views.
It's a work in progress though, I
couldn't find the Bounding Box of a perspective view as I did before
for a 2D view, and that's an issue still opened since I hadn't look
into it since I published the code. I'm open to all the help I can
I hope this helped you in a better understanding of what's behind the code.