I returned from my vacation and Buddhist retreat in France, on the Atlantic coast and in the countryside around Bordeaux.
I am going off on vacation again next week, though, in the French Jura, so this is just a short break in between vacations :-)
Here are my topics for this week:
Sasha Crotty and The Factory published an update to the Revit Public Roadmap – July 2019.
I urge you to check it out to see where Revit is headed.
If you wish to get involved, submit your own ideas and requests, please do so in the Revit Idea Station.
I recently implemented
a new external command CmdRebarCurves
in The Building Coder samples.
It was originally intended to be used to simplify and minimise models for Forge processing.
However, it seems that may no longer be required, since Michael @micbeale @wallabyway Beale lists some alternative options as well:
- Avoid Revit solids due to 'triangle explosion', i.e., too many triangles in SVF, making downstream processing extremely problematic and expensive.
- Jeremy looked into using the Revit API, prototyping a Revit API plugin solution to be piped through DA4R to extract the Revit primitive information about the rebar centre lines that can avoid the triangle explosion problem.
- We are now investigating a new 'rebar-lines' solution that includes enough meta-data information to avoid needing Jeremy's add-in.
The latter is the winning solution, since it avoids the triangle explosion, because rebar-lines use low bytes compared to the heavily tessellated rebar-solids, and we can create 'unit-mesh' cylinder primitives during Forge processing, thus outputting highly optimised rebar solids in a future updated Forge Viewer.
Therefore, I see no need to enhance the current CmdRebarCurves implementation at this point.
I still hope that it will remain useful in its current state for answering questions such as the following one from
the Revit API discussion forum thread
on getting rebar centreline curves using GetCenterlineCurves:
Question: I am using the Revit 2019 API and I want to get the centre line curve of the first and the last rebars in a rebar set. I tried using the following method:
Rebar.GetCenterlineCurves(
bool adjustForSelfIntersection,
bool suppressHooks,
bool suppressBendRadius,
MultiplanarOption multiplanarOption,
int barPositionIndex);
However, it seems that the parameter barPositionIndex has no effect at all.
No matter what valid position index of the rebar set I input, the curve list I receive is the curves of the first bar – the same as the result of calling RebarShapeDriveAccessor.ComputeDrivingCurve.
How is this possible? Is there anything I missed in the document?
P.S. I found another way to achieve what I want by translating the first rebar curves along the direction of rebar set.
Answer: Congratulations on solving the problem as described in your post scriptum.
Take a look at the
new external command CmdRebarCurves
in The Building Coder samples.
It seems to be using the very same approach you describe.
Manuel Solís López of SOFiSTiK AG explains:
Rebar.GetCenterlineCurves(... , i ) will return the curves of the Rebar at the i-th position.
However, You must distinguish three different cases, depending on the DistributionType:
Uniform – The rebar curves will be equal at all valid positions.VaryingLength – According to the rebar constraints, the rebar curves may vary along the distribution path. For example, a set of straight rebar in a triangular slab.IsRebarFreeForm() == true – The Rebar curves of FreeFormRebar at each position will be defined by the given constraints, but also by the specific RebarUpdateServer to which the Rebar is subscribed, for instance using SurfaceDistribution or AlignedDistribution.The Rebar curves at each i-th position could vary or not, but in case of non-FreeFormRebar (Rebar.IsRebarFreeForm() == false), you would have to apply the corresponding Transformation in order to obtain the actual location in 3D Space:
Rebar.GetShapeDrivenAccessor()
.GetBarPositionTransform(i);
Many thanks to Manuel for his helpful explanation!
The Visual Studio Revit add-in wizards provide Visual Studio templates for generating C# and VB .NET Revit add-ins. They enable the instantaneous automatic generation, installation and debugging of a new Revit add-in skeleton with one single click.
The current version of the wizards now includes a built-in zip utility.
It was added by Brandon @ProjectBarks Barker in his pull request #9 providing Visual Studio version support and an integrated zip utility.
The most up-to-date version today is VisualStudioRevitAddinWizard release 2020.0.0.1.
Many thanks to Brandon for this useful contribution!
In another case, an add-in developer wishes to create a section view with a top view direction:
SectionView to create a top viewQuestion: When passing the BoundingBoxXYZ parameter, what is the requirement for the corresponding base(i) vector?
What is the specific logic?
I tried it myself, and it seems that the logic of BoundingBoxXYZ is different when generating an inside view and generating a top view.
Do any special rules apply when using the ViewSection creation methods to generate a top view, i.e., view direction equal to (0,0,-1)?
Answer: Looking at the Revit API documentation, the ViewSection class covers sections, details, elevations, and callouts, all in their reference and non-reference variations. Its creation methods can be used to specify the view direction:
In the last of these, CreateSection, the notes explain:
Create a section whose view volume corresponds geometrically with the specified sectionBox. The view direction of the resulting section will be sectionBox.Transform.BasisZ and the up direction will be sectionBox.Transform.BasisY. The right-hand direction will be computed so that (right, up, view direction) form a left handed coordinate system. The resulting view will be cropped, and far clipping will be active. The crop region will correspond to the projections of BoundingBoxXYZ.Min and BoundingBoxXYZ.Max onto the view's cut plane. The far clip distance will be equal to the difference of the z-coordinates of BoundingBoxXYZ.Min and BoundingBoxXYZ.Max. The new section ViewSection will receive a unique view name.
The development team clarifies:
For most section views, the UI does not allow this, and therefore the API does not do so either.
Sections created in elevation views must be vertical.
For instance, ViewSection.CreateSection restricts the view direction to be horizontal, i.e., the view plane to be vertical.
However, ViewSection.CreateDetail has no restrictions on the view direction and can therefore be used to create a section view parallel to a plan view.
So, you should be able to use a detail view to achieve what you require.
Forge Design Automation for Revit or DA4R supports RVT file processing, but not RFA.
This begs the question:
Question: I came across an AU class recording showing a customer with WS Atkins & Partners demoing their Revit IO apps.
One thing it showed was extracting Revit families using Revit IO and displaying them on the web using the Forge derivative service and viewer.
However, I don’t believe the derivative service supports the RFA file type.
Do you know how they managed to show 3D models of Revit families on the web?
Answer: The workaround is to place a family instance in an empty project and have it translated.
So, the source files are actually RVT, not RFA.
Many add-in make use of the Windows TEMP system variable to define a path for outputting a temporary file.
Revit 2020 apparently alters the value of that variable, affecting the add-in behaviour as well.
I ran into this issue myself, prompting me to discover the StackOverflow discussion
on Path.GetTempPath method returning UserTempPath with GUID added in Revit 2020.
The answers there explain:
Apparently, Revit changes the temp path for the scope of the application.
I chose the easy solution in my add-in, using a constant "C:/tmp" instead.
Other possible solutions include:
Environment.GetFolderPath(
Environment.SpecialFolder.ApplicationData )
+ @"\AppData\Local\Temp\"
Path.Combine(
System.Environment.GetEnvironmentVariable(
"LOCALAPPDATA" ),
"Temp")
Let us round this off with an interesting little mathematical non-Revit-API observation:
I ran across several neat demonstrations of an ancient and well-known multiplication method previously unknown to me, lattice multiplication, e.g. this three-minute video on multiplying numbers by drawing lines: