How can VA Objects (ie. walls) be manipulated in Grasshopper and then refreshed in Rhino without rebaking (duplicating) them?
As we understand VisualARQ outputs objects as Geometry Cache of each instance, so the above should be possible.
Sample desires worflow (ie. for Pocket Windows):
Gather all windows, walls and windows with Va Geometry Pipeline
Filter/Select only sliding windows
Create wall solids for the pockets, with dimensions based on window/door properties.
Subtract each solid from the corresponding wall (wall host property)
Up to here the workflow is somewhat clear -
Refresh existing walls (adding the solid cuts) without creating new walls.
Any thoughts?
Can this be solved by creating a Door/Window Style through GH and exporting it somehow as a VA Style? What is the workflow for that?
Thank you in advance.
ps. We comprehend that this will work if we build the whole building through grasshopper, walls and opening included, but that is not a viable solution for most usage cases, other than full parametric builds.
I am sorry but I donât understand very well steps 3 and 4 of your workflow. What do you mean by âpocketsâ?
Anyway, I think what you need is to modify the wall geometry and then substitute this geometry in the Rhino viewport. You can update property and parameter values but not the geometry. If you need to âsubstituteâ the geometry maybe you can create it and delete the original geometry afterwards.
I am not sure if this would solve your issue because, as I say, I didnât understand very well steps 3 and 4 of your workflow. Anyway, if you want to create a style through a Grasshopper definition and import it to VisualARQ, you can do it with a Grasshopper Style: https://www.visualarq.com/learn/grasshopper-styles/
Pocket Windows are Windows that slide within Walls (within Pockets in the Walls), which are not currently available in VisualARQ (they should be added soon!). This could be created by boolean subtracting a solid to create the pocket.
A way for user to âinjectâ (like parametres) the grasshopper actions by modifying the wall definition before it is sent to rhino (adding the boolean in the process, and then Va would re-create the geometry).
So grasshopper would read the internal reference polyline of each wall (and not the wall as an object, to avoid circular references), recreate the wall, sent the data to VisualARQ, then VA would keep them as cached and use them even if grasshopper definition is closed, until it detects new changes in the GH definition.
We will check the links you provided to see if they help.
Unfortunately it is not possible to update the geometry of a wall from Grasshopper. The only way to do it is by creating the new objects with a Grasshopper definition and deleting the old ones.
I agree, there should be a way to create this pockets for Grasshopper styles as well. However, I think this should be done with a solid. If you define it with a curve as an opening, this opening would cut all the thickness of the wall so you would get two gaps instead of one gap and one pocket.
I have already added all these requests to the wishlist for future development.
That is why we suggest to add separate depth of cut (boolean solid extrusion depth), and offset to each curve. The Offsets and depths of cuts would be visible in the rhino va object properties panel for all curves, as it is now for the single curve (opening). The objective is for these parametres to be able to be adjusted on Style, but also overridden on Object Properties Level.
Thank you for adding it to the wishlist. Since pocket doors and windows are very often used, it is very, very much missed.
This is a very good idea. Grasshopper Style Wizard could have the ability to add any number of solids, and for each solid the boolean operation (Add, Subttract, etc,) would be selected.
This could offer many possibilities with a simpler backbone change.
What I want to do is have one opening cut two different walls. Iâm seeing a few situations with walls, floors and ceilings where I want the elements separated (for more control and independence between layers).
Why do you need to have two walls instead of one in this case? Please, could you send me some more information about it? Maybe we can improve something in walls so that you donât need to do this.
I was going to give a detailed answer but I realized I was hijacking the post. Perhaps I can post in more detail in the future, complete with pictures. But to be honest I am looking for something that even the most expensive BIM programs donât do well.
I will just mention something Revit does: It has a âvoidâ system. You create a void and it âcutsâ every element it touches. I believe you can override each elementâs ability to be affected by the void. Imagine having a 50 storey tower and realizing you need to create a new elevator shaft! This would also work great for components that have unique âvoidingâ requirements like a pocket door. You could have a Brep that acts like a void or something. For the pocket door the special void brep would need only cut itâs host. But for say, an elevator shaft, the brep would cut any VARQ object it touches (unless the objectâs âcan be cut with voidâ property is overriden).
Hello,
This concept has been invented by the ARC+ software developers, in some mid 90s, I think. I havenât used it for years, but the idea is to have a ânegativeâ solid, interacting with any other âpositiveâ ones. And it can be a parametric solid, of course. Some time ago I told Enric about this solution, well, without any further development
Cheers, Jaro
Alfonso,
Well, you cannot, at least you cannot the way we would like to.
Because we are talking about an automatic solution, when you have a style element, with some parameters, and the subtraction is a built-in option. This way a subtracted solid could also be a dynamic element.
The idea of a ânegativeâ or âvoidâ element could solve quite a lot of problems, especially when there are interacting different objects types.
Cheers, Jaro
Which features do you think we could add to this workflow so that you can use it in the way you need?
I think maybe you may need to tag any Rhino geometry as âvoidâ so that it is automatically subtracted to any VisualARQ object. Another posibility could be having the option to edit the geometry while it is being subtracted to a VisualARQ object (this way you wouldnât need to extract the geometry, edit it and subtract it again). What else do you think we could add to this workflow?
You can use a normal Door, Window or Opening. It will attach to one wall but Cut all Walls it touches if you make it tall enough. It will not cut Slabs though. Maybe that is the solution, to have an option on windows/openings: âInteract with Slabsâ, or âCut Slabsâ and so on.
Alfonso had the idea of allowing a Subtracting Solid in a Grasshopper style (discussed above). That will pretty much unleash possibilities and solve many issues. Just make sure this solid interacts with wals and slabs, and have switches to turn interaction on/off, per object type.
So, adding to the above wishlist:
In the grasshopper style add solid(s) options, choose type of boolean per solid (add, subtract, etc) plus choose affected object types per solid (walls, curtain walls, slabs, beams, etc.)
These options should be also present per rhino VA object, available in the edit va object properties panel, so the user can override the style defaults.
They could appear in the main properties panel or as parametres.
This is definitely a useful in many situations and allows for a lot of freedom. As others mentioned, some sort of âreal timeâ grasshopper solution would work well too.
Being able to cut objects with other visual ARQ objects would be very helpful as well. And in exactly the same away as the vaSubtractSolids command.
I mocked up a dropped ceiling:
Also, the floor finish is modelled extremely thin to hide the fact that itâs cutting into the wall:
One work around for either issue is simply to have multiple floor (slab) layers. As mentioned, this is something that Revit doesnât do well. And having freedom allows us to work around issues like these. To me thatâs the big flaw with Revit is that when it canât do something, you really have to scramble to model it the way you want.
With the floor/ceiling issue, I would probably copy the model, explode all the walls so that they are solids, do the vaSubtractSolids, and then copy my floor/Ceiling back into the original model.
Maybe an option, something like âthis layer is cut by other vaObjectsâ would work? Or some sort of hierarchy so objects donât overlap. For example, carpet would be automatically subtracted by a wall.
It would be cool but it also feels like a lot to ask for!!
A like this would also be very useful and that can be reflected in the documentation of sections or elevations, since this would allow it to be very flexible, which is the innate characteristic of visualarq
