Hey,
Test_Steckdose.gh (10.8 KB)
before i dive into creating my own styles in Grasshopper i wanted to test the styles and i don’t get them running.
Do i really need for each item 1 component?
It only displays the first item of the List.
I am trying to find the best worklow and was thinking its best to internalise everything in Grasshopper-Script and not work with Blocks& Representation in native Visual arq to be more flexible.
PS.: I am quite advanced in GH. Visual ARQ is new to me!
Hi @mi.land if you need to internalize more than one object for the Grasshopper Styles, you need to do it in a Data component, (VisualARQ Styles doesn’t support lists in Geometry Input params right now).
Hey @fsalla thanks for your support!
A)Is there any pro or contra of internalising most stuff.
B) Would you suggest to use blocks with native visual arq whenever possible?
C) Or is a combination of blocks and gh the way to go?
What runs the most stable?
My Startpoint:
I work mostly on interior stuff, and would like to use the styles for furniture. I have all the blocks and 2D representations as blocks already organised. I was hoping Visual Arq could save me the time of my existing workflow:
Using drawingplane on the house/walls (with production ready 3d-Blocks, ignore these) and paste suiting 2D-Blocks that are visually easier to read, into the drawing. So i was semi dynamic. Annoying with changes but acceptable.
So my thought was:
I could make my production ready Blocks, (partly parametric or not) and connect the 2D-Styles i already have.
If my Blocks have all kind of information, like Name of Block, Position (AttributeUserText) and all geometry has also a name and Attributes.
Is there a risk of loosing the Information on the way.
When i move from Drafting to Production, can i retriev my Block + Information from the va_furniture.
Maybe even with a single gh.-definition
I started trying but the same named and almost same looking componetens of native rhinoGH and vaGH are very difficult to keep track of.
I might be affraid that i loose my attached Data since va blocks are geometry-based only and my worklfow is object-based.
It would be alright for me to use the va_components with lost information if i can bake them to the Block/Geometrie later again with a work around.
Hi @mi.land combining VisualARQ objects from blocks and Grasshopper Styles is totally fine. But the user texts or custom parameters assigned to these blocks won’t be readable in the VisualARQ object created from them, since you will only see the metadata assigned directly to the VisualARQ object, not to the block or the individual pieces of the block.
Hmm long question short answer.
I was hoping to be connect Drafting & Production since i have medium small Projects 
To small for real BIM to repetitive for manually only.
Cleaning up your Block-Components in GH and synchronising them with Rhino8 Components and go more Object orientated would be a game changer.
Thanks for your time.
Hi @mi.land excuse for the short answer.
There are methods to transfer the information stored in blocks to the VisualARQ objects that are using them, using Grasshopper.
Here you have an example of how to transfer the area and volume of VisualARQ wall layers to the wall object (since wall layer dimensions or parameters can’t be quantified or listed): https://www.food4rhino.com/en/resource/wall-layer-area-and-volume
But perhaps you can describe your case to better understand which is the information you want to preserve, and how to use it.
@fsalla thanks for your effort, here is mine 
Maybe you find time to check the gh. file and check the workflow i used, feel free to point to possible flaws!
Fully dynamic electrical Sockets (3D- Design Jung LS 990) in 1 VAStyle.
Would be nice to use 1 Element for 2D/3D and fine enough for 3rd-party rendering.
Tests will show if it is to detailed to get unstable in VA.
I used a workaround for the text. I dont get your text-params as output to be honest. Symbol is too similar to .gh native too…
Text entity and the RH8-GH Model-Object and Model-Blockdefinition as well as native BlockInstance would be perfect as readable output! More synchronisation less vaObjects
GH-Script:
2026-02-06_VA_ESocket.gh (89.7 KB)
Hi @mi.land, The native Text Entity component might not be compatible with the Grasshopper Styles right now. So you should use the Create Text component instead (under the VisualARQ tab > D.Generics), and a Text param (Params > Geometry > Text) as output component to store the text to display in the GH Style.
Once we make the GH native Text components totally compatible with VisualARQ we may get rid of ours (which we still need to maintain, since VisualARQ 3 works in Rhino 7).
Another option you can consider is to use the VisualARQ’s Tag (vaTag), to display certain parameter of these Elements, rather than including the text in the Grasshopper definition that drives that style.
Hi @mi.land I’m checking the compatibility of the Text Entity component in Grasshopper Styles, and it works. The main requirement to get the text as a text in the output component is to use a Text param, as mentioned before.
