VisualARQ 3.10 - Release Candidate 2 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.10 is scheduled for official release on Wednesday, June 3th, 2026
This release fixes most of the problems and crashes reported by users. Please report any problems or suggestions here or email us at visualarq@asuni.com.
List of changes since RC1:
Fixed Errors (18)
Attributes:
15656: Wrong Section hatch color in wall layer
Block:
15645: The Purge command removes block definitions that are used by VisualARQ styles
Crash:
15671: Crash after updating a section view
15660: Crash after baking objects from a worksession file
15644: Crash when using coma for decimals in door or window sizes
Grasshopper: Components:
15662: Preview bug in old Grasshopper file with VisualARQ Objects
Grasshopper: Style:
15649: Solid of subtraction is not visible in VisualARQ objects created as Grasshopper Styles
IFC:
15661: Crash opening an IFC2x3 file with the V4 Engine
15659: Names in guides are not preserved in IFC files
15653: VisualARQ gets stuck at opening this IFC4 file
15376: Custom parameters are not detected in V4 Engine
14815: Crash after opening an IFC file
Interferences:
15650: 2D curves in VisualARQ objects are not subtracted with the vaSubtractSolids command
Level:
15647: Tooltips for the “Level Manager”
Object: Guide:
15614: Control points are not editable in jagged section guides
Parameter:
15665: Parameter filters are not saved
Print: Hidden Vector:
15499: Dimension texts are not printed with the proper alignment
Solid Modifiers:
15648: Handle component from Furniture object is not subtracted
Hi @Toni_Osterlund given the opportunity, may I ask you to elaborate on what workflow you actually follow in terms of “connection between Worksessioned VA-objects” ? Of course only if you might want to share this info. I am used to work with Worksession but everytime I regret it, and I am keeping this only to attach .3dms for read purposes such as survey not to expect interactions between elements. Maybe I am missing something valuable here.
Hi @GabrielB
it’s complex question, but I’ll try to explain as briefly and clearly as I can.
This is generally how I work as well. On large models, I try to find good break points, where I can save separate sections as separate files. And there is no “big” interaction between them, mainly only checking that there are no collisions.
Through worksession I also create facade elevations and some installation floor plans on top a separate file. This keeps the main file lighter, and as an added VisualARQ extra the generated lines do not reside in the original layers anymore, as they are through worksession. This way, keeping the 2D-file separate, I do not have to take care of the Layer visibility of the model when exporting or printing the drawings.
Through worksession, and now getting to the gist of my grievance with RC2, I create fabrication documentation/data/drawings. This involved taking vaBeam objects from their 3D-position and orienting them to a more sound XY-position. Again, I do not want to do it in the main file, but in a separate file. Here, for instance, the nested results of the main model, via script via Worksession.
Thank you for the info and your answer Toni. It seems very well structured as a workflow logic, given the fact the 2D elements mess up the entire .3dm functionality in terms of speed of viewport actions, layer states etc.
I may try to investigate how a vaplan and vasection (I suppose you mean those when talking about sections and elevations, right?) can be created in separate files and get attached through worksession, in a more automated way, which would be a game-changer for the workflows we follow. Maybe you already do this - in an automated way - but I’ll try to check this. I am curious how you deal with updating the drawings being in separate files.
The fabrication/documentation etc drawings, seems to be a very nice way of working - splitting from the actual working file. Very interesting. I usually separate the entire drawings, but not working with worksession for this. I’ll try to undestand the logic more.
Even though I am working with VA long time, still we do not produce good quality drawings for both vaplans and hidden mode viewports drawings options. I’ll investigate your logic and how Layout logic can be integrated in it.
Yes, I mean those. The process is super simple, the vaSections just need to be in the active file, they do not work through worksession. There’s no automation, update is easy: Open 2D-file, worksession model (check proper layer combo), update sectionViews. Maybe you refer to automation in a sense that they would be real-time refreshed, which they are not. But _vaUpdate before printing does the trick for me.
I tried something similiar, some time ago - in saving the vaplanview / vasectionview as blocks (as they are) and inserting them into a different file, for example a 2d drawing file - but unfortunately when you open the blocks, they are blank - as they look for they 3d - pendant, silly enough right when you open these inserted blocks, the right lineworks flash for a second and then vanish.
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.10 is scheduled for official release on
Wednesday, June 3th, 2026
