I am getting a different result with 2018 than I was with 2017 and previous versions of Revit.
Dim oBBoxCropView As DB.BoundingBoxXYZ
' do some stuff to create required bounding box.
Dim V3D As View3D
V3D.CropBox = oBBoxCropView
The code for creating the bounding box results in an identical BoundingBox, but when applied to the view crop box, results in a very large max and min extent.
Has anyone else experienced this?
?oBBoxCropView
{Autodesk.Revit.DB.BoundingBoxXYZ}
Max: {(43.355956267, 0.075662107, -0.100000000)}
Min: {(21.252267057, -21.180810247, -1000.000000000)}
?V3D.CropBox
{Autodesk.Revit.DB.BoundingBoxXYZ}
Max: {(43.355956267, 0.075662107, -0.100000000)}
Min: {(21.252267057, -21.180810247, -1000.000000000)}
But with Revit 2018, using the same values for oBBoxCropView results in an invalid cropbox for the view.
?V3D.CropBox
{Autodesk.Revit.DB.BoundingBoxXYZ}
Max: {(-1000000000000000019884624838656.000000000, -1000000000000000019884624838656.000000000, -0.100000000)}
Min: {(1000000000000000019884624838656.000000000, 1000000000000000019884624838656.000000000, -0.120000000)}
Solved! Go to Solution.
Solved by CaptainDan. Go to Solution.
I have also had this problem in Revit 2018. One of our addins crops a 3D view to the extents of a section box, which has worked in all prior versions of Revit until now (2018). The crop seems to be off by a variable amount depending on the location of the section box but it's not particularly consistent. It tends to be off by about 10 feet or so in X and Y directions...
Hi Peter,
After further investigation I've found that if I ensure that the new bounding box I assign to the View3D's cropbox has the same transform assigned to it as the original crop box then the crop is correct. In prior versions of Revit the Min and Max coordinates would stay the same after assignment to the CropBox property. However in Revit 2018 it appears that if the bounding box's Transform does not match the View3D's crop box, then Revit transforms the Min and Max values upon assignment to the CropBox property. Hard to tell if this was a silent fix to incorrect behaviour in prior versions or if it's a bug in Revit 2018....
Hi @PeterLMann, @CaptainDan,
Have you tried to put a doc.regenerate at points in your code? Especially if you've just recreated the view.
There are a growing number of cases where a regen is required. A frustrating change, if that's what's going on.
Dear Peter,
Thank you for your report and sorry to hear the bad news.
Could you please provide a minimal reproducible case for me to pass on to the development team for further analysis?
http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b
In order for the development team to reproduce and analyse the issue, a minimal sample model and a macro or two demonstrating the problem wiold be optimal.
You say that a call to regenerate makes Revit crash sooner; that sounds like a different issue. In the first, you say that the crop box settings differ. Can you please include a separate macro to also demonstrate that crash?
Thank you!
Best regards,
Jeremy
Dear Peter,
I see the following file attached to the ADN case 13049014 [Setting CropBox for a 3D view with Revit 2018]:
It includes some VB code.
However, I see no reference whatsoever to anything related to the Revit API.
Are you sure you attached the right file?
Best regards,
Jeremy
Dear Peter,
Thank you for the reproducible sample.
I logged the issue REVIT-115510 [different result setting CropBox for a 3D view with Revit 2018 -- 13049014] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.
You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.
This issue is important to me. What can I do to help?
This issue needs to be assessed by our engineering team, and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:
This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.
Cheers,
Jeremy
Dear Peter,
Thank you for your update and business case.
I added them to the issue REVIT-115510 [different result setting CropBox for a 3D view with Revit 2018 -- 13049014] to make the development team aware of its importance.
Cheers,
Jeremy
Dear Peter,
Thank you for your patience.
The development team are analysing your issue REVIT-115510 [different result setting CropBox for a 3D view with Revit 2018 -- 13049014] and say so far:
I hope we can find a workaround or advice for Peter regarding what setting produces the effect he wants, and perhaps we need to add some API coverage for different scenarios.
We will need to assess this issue.
Can you provide more detailed information on the difference in behaviour between 2017 and 2018 that I can pass on to them to clarify the problem?
Remember that the development team does not have an add-in development environment at hand, or RevitLookup installed.
Maybe your macro could include a couple of lines of code to print out the problematic values and ensure that they are not overlooked.
Thank you!
Cheers,
Jeremy
Jeremy,
Section Box in Revit 2018 is indeed not working. I am having the same experience as fellas above. Code that used to work just fine in 2017 is not working in 2018. There are no errors or warnings, so I am not really sure what the issues are. My section box values look ok when I am debugging, transactions all complete, but when I open the view created, section box is off in space, even though its BoundingBox min and max would indicate that it's located properly. It's all very strange behavior.
Ps. It is a business loss for us, just like for people above. We have 100s of users not being able to use our plug-in anymore.
Dear Konrad,
Thank you for your note and sorry for the inconvenience.
The development team are aware and have addressed the issue, with the db entry number REVIT-116470.
It will appear in some update release. Unfortunately I cannot say for sure exactly when yet.
Cheers,
Jeremy
Jeremy,
Do we have an update on the fix release for the 3D crop box as yet?
We use the CodeBook software here at NBBJ as as Peter refers to utilise this to automate 3D views onto 1000's of sheets per project increasing our efficiency 10 fold, without this working correctly we have to manually create each 3D view onto each sheet increasing time and affecting revenue/profit margins.
This feature is a big part in our delivery to clients, so not only does this affect our internal workload, if we have to retract on our delivery process/promise on projects across both the UK and US this will have an adverse affect on client relationship and future projects.
Any update would be appreciated.
Dave Lewis, NBBJ Architects
Hi people,
Just thought I'd check in to see if anyone else tried the workaround (that worked for me at least) for this bug?
What I originally did (and what worked in prior versions) was create a new BoundingBoxXYZ, set the min and max appropriately and assign this to the CropBox of the section.
In Revit 2018, after playing around with the same code I found that as long I additionally set the transform of this new BoundingBoxXYZ to be the same transform that the original CropBox has, then the Min and Max don't change and appear correct. I haven't had any issues since this workaround and the tool that uses this code has been in use for some time now in our workflows without issue. Is everyone sure they're setting the Transform property appropriately?