Hi there,
Just starting to test out VA 3 beta and it seems like we should be able to easily assign objects to levels but its not very clear how to go about doing that. (I see the “new features” page on the VA 3 website shows this as a new feature). I figured it would be as simple as having the objects selected and right clicking on a level → “assign to level” or something like this.
For example, I have a wall on Level 1 (wall style has a height of 8’). When I change the height of Level 1 to 12’, the wall height remains the same (8’). Isn’t there a way to attach the objects to the levels, as you would typically see in Revit? (I see the “constraints” tab at the top and I have the appropriate boxes checked for objects to link with levels, but it doesn’t seem to do anything)
@fsalla
Hi @martin88smith in VisualARQ 3, objects are not really attached to levels. There is no property that tells you to which level an object belongs or that you can use to move it from one level to another (although this is something we could implement).
You can move objects up and down freely, from one level to another, with no need to change any property of that object or parameter.
Currently, when you enable the Constraints icon in the Level Manager for a particular level, that level checks the objects sitting on that level (or situated between its elevation and the elevation of the upper level), and moves them according to the new elevation.
If an object (like a wall), ends at that level elevation, it will update its height to adjust to the new level’s elevation.
I’ve recorded a video-tutorial for the new features of the Level Manager, if it helps: https://youtu.be/tiFcS3u7-fI?si=IHeTGqbT3REXuY7h
Thanks for the reply. I saw the video tutorial before, it was helpful, thank you. I just assumed this feature would “stick” objects to the level above when drawing walls, etc., as the objects “top constraint.” I guess I will have to keep playing around with it.
From what we can tell looking at the IFC export, VA obviously is working with some sort of linking of objects to levels. It just is quite a mess and there is no implemented way to control this within Rhino. And that is (yet another) fundamental flaw of this once promissing attempt on BIM modelling.
I am leaving asside some other flaws regarding IFC (like exporting some elements as random shapes, etc.). VA even after all these years of development unfortunatelly remains to be a tool (maybe) for some conceptual sketching or students.
UX and overall workflow is a pain, plenty of glitches and unresolved issues, disappearing elements, etc… Pitty, this did not work out - VA was once a promissing tool.
Hi @davouch,
VisualARQ objects and Rhino geometry is exported to IFC in the level where they are located. That’s calculated automatically so there is no need to specify each object in which Building or Level it is located. When an object is larger than a level height (for example a wall that goes from the ground floor to the second floor) then VisualARQ checks for the location of its path curve or base point to export it to a level or another. If you have some examples where this doesn’t work, please send them over so we can address them accordingly.
Can you provide more details about these issues? that way we can figure out what’s happening and fix any possible errors.
Can you develop this a bit more? that way we can better understand your point of view and improve the program accordingly.
Again, we need specific files and cases to fix any possible issues or to understand what’s going wrong.
Are you using already VisualARQ 3 or is this feedback based on VisualARQ2?
Thanks!
How about this?
All openings (partially - see bellow) unassigned to levels…
…while some of them somewhat work:
I surely can. And trying hard to hold on to what remains of the naive altruist parts of me maybe I will. To do so though, I will have to find a gap in my schedule to spend even more time nobody pays me for to help you improve fundamental flaws of a software you ask me to pay you for…
I understand, that there are limitations to a SW development. Versions, milestones. Nothing gets done at once. On the other hand, you (plural, as in Asuni) should understand, that the app design stage never ends and is no job for users to keep it up to the highest possible standards of usability (among others).
I understand, and am trying to provide a feedback once in a while.
You should understand though, that for us (users) to provide you with a reasonable feedback on mysterious things happening in your app (we pay for) and to follow it up once posted is a hugely time consuming process. And even with that left aside, there is still a semi functional / glitching app on our side the whole time…
We probably can consent on a fact, this is not an open source project. Yet, in some specific ways, it somewhat feels like one for years…
Hi David,
The ifcOpeningElement and ifcWindow are different IFC entity types. It looks like that Autodesk viewer is not assigning the ifcOpeningElement to the corresponding level. If you take any Revit model exported to IFC and open it with this viewer, you will see the same problem. Find attached a sample IFC model exported from Revit:
07-Modern_House.zip (632.1 KB)
Can you share the original 3dm file and the generated IFC you are opening in the Autodesk Viewer?
I’ve tried to export a simple model with the default Toilet sink from VisualARQ, and it looks fine:
I totally understand. We don’t like users “waste” their time reporting or debugging errors. But most of the times that’s the only way we can figure out about errors that are file specific or that were not detected before. We hope to return that time and effort with a better SW solution for our users.
OK, I can confirm this.
The inconsistency applies to some other viewers too (not only Autodesk).
E.g. BIMvision seems to be correct on this one, and VA is admittably innocent here.
garden house.zip (1.4 MB)
Thanks for the file! This issue seems to happen with the Toilett element in a millimeter template document. We will fix it in future updates.
I totally understand. We don’t like users “waste” their time reporting or debugging errors. But most of the times that’s the only way we can figure out about errors that are file specific or that were not detected before. We hope to return that time and effort with a better SW solution for our users.
In the product design/ development world, you would typically find users to test out a new update, new features, and definitely a new version of VisualArq before releasing it for public use. I’m not sure if you’re doing this but it seems from user responses on here that user testing has not been executed enough before releasing the VA3 beta. This is a risky strategy because a lot of people will get discouraged from all the bugs and issues and decide not to use your software moving forward. There is a lot to love with VisualArq and I really enjoy playing around with all the features. The concept of having BIM right within Rhino is an amazing idea but no doubt difficult to pull off. Thank you for all your hard work and effort and for listening to users on here - your free source of user testing and feedback 
EDIT: I know McNeel releases betas as well - their “WIP” versions of Rhino. But they have a large company that is well known by now and people rely on their development team to figure it out. If you’re looking to bring on a lot of new users to your software I think a lot of the kinks should be figured out up front rather than letting users figure them out for you.
@martin88smith Thanks for your comments! The VisualARQ 3 Beta versions are meant to be used this way. The feedback and bugs reported by our users during that Beta stage of VisualARQ 3 are key to ensuring a stable and reliable version when we publish VisualARQ 3.
