VisualARQ 3.8 - Release Candidate 4 is now available for download.
NOTE: This is a release candidate (RC), meaning it is not the final version but has undergone internal testing and is considered stable enough for end-user testing. VisualARQ 3.8 is scheduled for official release on Wednesday, February 4th, 2026
This release fixes most of the problems and crashes reported by users. Please report any problems or suggestionas here or email us at visualarq@asuni.com.
Here is the list of changes:
Fixed Errors (2)
Grasshopper: Components:
15469: Crash after referencing a building in Grasshopper
Object: Plan View:
15439: Guides in hidden layers are showing in Plan Views
With every release, I’m hoping to read about improvements to georeferencing. I normally model close to the origin, but am typically expected to provide ifc models in a Gauss-Krüger or Lambert coordinate system, where coordinates are hundreds or even thousands of kilometers from the origin. In my opinion, it would make sense to set this location in IfcProject or IfcSite.
When setting ModelBasePoint to something like 3500000,5000000 in the Rhino model, this offset gets exported correctly by VisualArq in IfcProject (so all geometry should be translated by this amount, which is what I want). But then at the same time, VisualArq applies the inverse to IfcSite. As a result, my design will appear exactly where I modeled it (close to the origin) instead of on the intended location.
As combining models from different design parties is one of the main reasons to work with ifc files, I am quite puzzled that I would have to manually edit ifc files in a text editor in order to get the georeferencing right. Is there perhaps some other possible workflow that I am missing? Is there a way to switch off the inverse transformation that is applied to IfcSite?
Hi @pistepilvi excuse the late reply.
VisualARQ still doesn’t take into account the ModelBasePoint when you export a model to IFC. It takes the World Origin of Coordinates instead. We plan to fix this in one of the upcoming updates.
Why don’t you use the EarthAnchorPoint command to georeference your model?. Changing the ModelBasePoint into long distances may cause having models with the geometry too far from each other and get display and model precision issues.
Thank you for your answer. When setting the ModelBasePoint in Rhino, VisualARQ exports this offset twice: positively in IFCGEOMETRICREPRESENTATIONCONTEXT and negatively in IFCSITE, resulting in an offset of zero. I would like to only have the positive offset in IFCSITE. Personally I would prefer not to use ModelBasePoint at all and instead to numerically set the x and y offset somewhere in VisualARQ (properties/GUI/export dialog/…) without relying on any Rhino settings.
I tried setting EarthAnchorPoint values and the resulting latitude and longitude seem to be exported fine. However, I have never encountered a client providing or expecting models in WGS84. I am also not aware of any ifc viewer that would attempt to automatically convert lat-long values into arbitrary target projections and would be very hesitant to rely on it.
For our infrastructure projects, the client typically defines which coordinate system needs to be used. This makes sense, as they will have to combine models from multiple parties. Within the coordinate system, either the client or we define a local reference point close to the site. Within the coordinate system, this reference point tends to have extremely large coordinates (let’s say 3.500.000,5.000.000,0 m), but in our Rhino model, this point will be at the origin (0,0,0). When exporting an ifc file, we use our local Rhino coordinates to export the geometry, but we need to specify in the ifc file that the origin of our site is actually located at 3500000,5000000,0. The IFC file format has a very convenient way to specify this (adding an IFCLOCALPLACEMENT to the IFCSITE) and VisualARQ already writes an IFCLOCALPLACEMENT in every single ifc file it exports. All I need is a way to tell VisualARQ which coordinate to write in the file.
NOTE: This is a release candidate (RC), meaning it is not the final version but has undergone internal testing and is considered stable enough for end-user testing. VisualARQ 3.8 is scheduled for official release on
Wednesday, February 4th, 2026
