Bug 1:
Please see the below image. For any geometry linked as a worksession file VisualArq section’s clipping fails. The cyan cube is a brep cube inside the current active file, the red cube is linked from a worksession file. This is specific to VA sections. Rhino clipping planes work fine. The bug exists for any type of geometry (brep, subd, mesh). This one is a real problem for us, since we cannot produce drawing output in a project where we have a team collaborating via worksessions. Linked blocks are not an option for us.
Screenshot in file1, with cyan cube:
Bug 2:
When sections from a work session linked file are shown in the model, text scaling of the section name is off. The text that is hardly visible when in file1 (section in file), is displayed scaled up when in file2 (section linked via worksession).
Screenshot in file2, with red cube:
Wish 1:
Please make sections from worksession linked files available in the file they are linked in to. We have a master model where all sections of the project are defined. The master model is mostly a setup file. It links together different files from different team members. All linked files should have access to the sections from the master model, but should not be able to modify them. Functionality should be identical to how worksession linked layers work. They could display grayed in the Sections Panel and should provide the ability to be toggled on/off.
Wish 2:
An option to double click on the section geometry in the viewport to toggle it on/off.
Wish 3:
When a section is selected in the viewport, it should also be selected in the “Section Panel”.
Thanks for fixing the bugs and considering the wishes.
VisualARQ doesn’t handle well Rhino worksessions yet, but we are working to have this feature available in future versions. Maybe you can try this workflow.
I have already added your wishes about section selection. About activating section by double-clicking them, double-click is currently reserved to edit objects, but you can activate them by double-clicking them in the Section Manager.
no worries regarding the late reply. I am glad you are looking into this.
Unfortunately linked blocks are not an option for. We need the flat hierarchy and flexibility of worksessions.
I wanted to make another point for worksessions. In most simple architectural projects, we have at least 20-30 drawings. With this number of drawings that are based on VA sections, the BIM model becomes unusably slow. Worksessions with shared sections would solve any speed issues, since we could make several dedicated section/drawing files, where we only link the main model and then place sections in those dedicated drawing files. This would be a very scalable system. Similar to how BricsCAD BIM is doing it.
@alfmelbev I wanted to give feedback on the workflow with linked and embedded blocks and conclude, that it is not doing what we need and in general, I think it is a very flawed workflow:
Since blocks have to be linked and embedded the file size of the master file blows up to be unusable.
When updating linked blocks we consistently get block conflicts and material conflicts (Vray). Selecting a wrong option here once, messes up the complete block structure and can lead to older blocks overwriting newer. This risk is an absolute no-go when working with a team of a few people.
Sections and levels cannot be managed in a consistent manner. They have to be duplicated in between files and get easily out of sync.
IfcSite_Name etc. information has to be copied during files (error prone).
Since the blocks are linked and embedded all the layers from the other files display top hierarchy and are very hard to handle.
Lots (hundreds) of “ERROR No geometry found for block definition” error start popping up in the file we link the blocks into.
VA style properties are not transferred from the linked file to the parent file.
Thus, please please please, make sections in worksession working correctly a high priority item on your bugtracker.
For anybody reading this. Don’t go through the hassle of using linked and embedded blocks to fix section display. It is unmanageable in the above mentioned areas.
Yes, we know worksession is a powerful feature and we are working to have it available. I told you about this other workflow just in case it could be useful for you in the meantime. Maybe we will have worksessions in VisualARQ 3, but I cannot assure you for now. We know many people is waiting for this feature and we will work to have it available as soon as possible.
Wow! This ist really great news, @enric ! Amazing!
Does that also change anything for un-embedded linked blocks?
Anyway, I’m really looking forward to this, as missing worksessions were a bit of a showstopper for us as well - for the same reasons @silvano mentioned.
Very good news, thanks!!
Some time ago you mentioned that support for worksessions is difficult because you need to attach data to the objects used by VA tools, and this is not possible when objects are in worksessions, since they cannot be modified. Obviously you found a solution. Some caching mechanism?
Anyway, it’s a big step forward!
Honestly, I don’t remember what I said, but 2 weeks ago, I wanted to try to implement the worksessions in VisualARQ in a simple way. Surprisingly, it was much easier than expected. I have to admit that this is because McNeel has provided Rhino with a great C++ SDK that allows us, developers, to access the core of Rhino.
In our case, the biggest problem is that while Rhino is based on a single document architecture (even when there are several files open in a worksession), VisualARQ uses multiple documents in memory (one for each file). I won’t go into which implementation is better (each has its advantages and drawbacks), but synchronizing data between two different architectures is sometimes complicated.
I still have to solve some problems: for example, if a section view is created in a document, now the objects of the other documents will be shown as well, with their section attributes (this is by far the most frequent request related to worksessions), but the problem is that the annotation styles, line types, fonts, that are in one document but not in the other, are not seen in the document where the section is created. The solution will be to copy these styles or to look for a patch.
“Linked blocks” will be our next target, probably for VisualARQ 3. In principle, this is much more complicated than the worksessions because, in this case, the objects are inserted inside another document. Although there are several files on disk, in memory, everything works as if there was only one document.
Hello!
Any ETA for v2.12? These section hatches would be quite desirable.
Do you have a solution for this already?
I just checked what Rhino does with Annotation Styles from worksessions. They are temporarily loaded, cannot be used directly in the active model, and disappear again when the worksession is detached.
Maybe it works simply like this: VA Plan and Section views will display the worksession objects with their styles as defined in the other file. If the worksession is detached, the VA plan and section views become automatically updated, and the worksession objects in them disappear.
If the worksession objects should not disappear in plan views after their file is detached, their styles would indeed have to be copied over. This would be against the existing logic of Rhino worksessions, no?
(But then, Materials from worksessions ‘stick’, even when their scene is detached)
Another important topic:
Do you plan to make automatic wall joins work across worksessions?
Like a wall is in file A, a floating window in file B, and worksessioned together, the window will correctly cut into the wall.
Regarding this, I still hope very much that you at some point introduce some mechanism like ‘join groups’ (only VA objects that share some index are joined - see ArchiCAD), to make it possible to keep design options on the same position, and provide an easy way of keeping objects from joining.
Please keep this in mind when designing the worksession join logic.
Sorry, there is no planned release date. My estimate is 2 months from now. I hope it could be sooner.
No, I don’t have a solution.
This is not possible. Objects in one document cannot use symbols (layers, annotation styles, materials, etc) from any other document, even if the other document is attached using a worksession. So there are only two options:
Import annotation styles used by any object visible in the plan view (create a duplicate in the active document)
Explode texts into curves and hatches. This is much simpler, but the visual output is not as nice.
No, objects that are in different documents won’t interfere between them (walls won’t be joined, windows won’t make holes on walls, etc). Take into account that objects that are in a non-active document cannot be modified and their geometry should not be affected by any other document.
I’d vote for option 1. I assume, when the plan view block is exploded, the text will remain ‘real’ text, which is desirable.
Also, as mentioned, materials are also just copied over into the active scene from worksessions, and remain there. So why not annotation styles, too.
Allright, understood.
At the time being this is even usable as a workaround to keep ‘design options’ unjoined - by saving them to different files.
@fsalla I get the following crash with worksessions and VisualArq 2.12:
Empty File → Worksession → Attach (file with existing VA model) → Crash with message below
Hi @silvano, thanks to report this.
Can you share the file you are trying to attach? (or send it to visualarq@asuni.com). I also may need the Empty file. Is it a VisualARQ template?
Unfortunately, with the crashdumpfile.3dm attached we can’t figure out what’s happened.
What Rhino version do you have?
Hi @fsalla , Can you please let me know when a fix is available?
I am getting similar crashes in v2.12 Build 15409, but only on large files (Worksession has 2 attached files around 50-90mb each); everything seemed to work well in my smaller test worksession (2-4mb in size) but I notice that either Rhino crashes or VisualARQ never completes it “Upgrading document…” task
