View Depth Override - Alcune considerazioni

Update

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:

Hi Ning,

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 scratch.

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 get :)

I hope this helped you in a better understanding of what's behind the code.

Cheers

-Paolo

If you are happy with my code you can show me some gratitude paying what you want on PayPal:

puntorevit@gmail.com