Hello, I have a problem with the latest release: the only way to place doors is to insert them 1 by 1. For some reason, when copying the copy doesn’t cut through the curtain wall or wall
a quick update. I verified again and the problem seems limited to curtain walls
even stranger, when working with referenced blocks, door openings on curtain walls that are solved in the original file, dont get recalculated… It used not to be the case.
@XDGA, @federico.pedrini I haven’t been able to reproduce what you are describing here. What VisualARQ and Rhino versions do you have? See below my tests with VA 2.8.5. and Rhino 6.
Please share the files you are experiencing these issues with.
Thanks,
currently using va 2.8.5.14344 and rhino 6 sr29 (6.29.20238.11501). I have a file but it is confidential, what email is best to send it to?
Please send it to visualarq@asuni.com. If you prefer, you can just send a small version of the file, that contains the necessary geometry and information to reproduce this behavior.
Thanks,
I think the problem is related to the use of supports rather than mullions.
Got the file, thanks! I could reproduce the problem (only the one when copying or moving the door), but not when inserting it, which works well on my end.
After moving the door vertically, if you move it a little bit inside the curtain wall, the opening is generated. But we will take a look at this anyway since the opening should be created at once.
Ok, Thanks. I didn’t try that: normally I have the habit of working mostly with numeric gizmo offsets for regular iterations of the same element.
Now, if you try to insert this drawing as a block and have many instances of the same, you will see that these doors will come in as not solved
Hi @XDGA,
I’ve been checking the issue, and the problem is that there is a bug in the code that computes the curtain wall’s thickness (some sub-components are not taken into account), so when you move the door if it isn’t very close to the path surface (path curve extruded vertically), no interference is found.
We’ll try to fix this issue for VisualARQ 2.9, which should be published in two weeks.
Enric
Thanks for the explanation. I think the other problem is slightly different and maybe not entirely related. I think it has to do with the files being in blocks and probably the amount of computation it requires to solve all VA elements and display properties. The fact is that working with blocks linked to external files (as you guys also suggest) is a much more efficient workflow…
@federico.pedrini we have fixed this issue in VisualARQ 2.9 version. VisualARQ 2.9 - Version 2.9 released (for Rhino 5, 6 and 7)
2 Likes