0 thickness layers are useful in order to control paints and other ~0 thickness elements for calculations, BOQ etc.
I believe solving Z-index of 0 thickness elements is in the right direction - even though I’ve not tested in external real time renderers.
Walls by default have higher priority than slabs in intersections.
BUT as you can see the 0 thickness slab layer does not respect this priority and the interference function is not working well.
0 thickness layers should either be kept as function and must be working well or should be removed entirely in order VA users know what strategy they should follow - for example giving a minimum thickness such as 1 mm, which is way too problematic for snapping reasons or should have finish material attached to the substrate-insul layer with the normal thickness such as 10cm.
I am now in front of another desicion - in terms of strategy - should I change ALL va styles on by one, in order to remove the 0 thickness layers, and point the layer below to the desired material and abandon the optimal strategy
OR
keep it as it is with the hope that it is something that can be fixed by VA def team soon, like 5-6 days tops, for the upcoming submission we have next week?
Those decisions and back & forth actions, keep us away from being productive IMO. This topic has been discussed in the past - I think i had post something about it, if i am not wrong about it.
Do you have an estimation on when is it going to be fixed? Or 0-thickness is something you might drop in the future?
of course I could change the slab-boundary, but then I were about to loose connectivity and updatability with the grid-guides. Guides is the only way to have a fully parametric model, which is another discussion. But I am not willing to fix all slabs because of the 0-thickness-bug.
Bugs at z-indexing while in realistic mode for wall-0-thickness-layers too. Part of the wall has the right 0-thickness-layer material and other part the substrate’s material
Hi @GabrielB can you attach a sample file so we can better understand these issues? if you can just provide a file with the involved geometry only, it would be a great help.
Fi @fsalla this morning I changed all VA-wall-slab styles in order not to use 0-thickness layers. I’ll see if any backup has those 0-thickness layers otherwise I will re-insert those 0-thickness layers at my spare time, and I will send it to you by e-mail.
Zero thickness layers is a bad idea, they introduce Z fighting a 3D rendering and floating point precision issue, although i have used them too to hide in hidden mode sections the vertical lines between walls and concrete columns, since my wall styles do not have plaster layers and VA does not yet have LOD capabilities.
hi @fsalla . As i had mentioned, unfortunately no backup was kept with those z-index errors. The question is: Is VisualArq supposed to handle correctly the z-index-fighting issues presented in the screenshots and for this reason the 0-thickness is something that is implemented in the plugin?
Revit handles 0-thickness membranes correctly - even though not tested in the past with external renderers and also provides the ability to override wall finish paints with the paint tool.
For that reason, I believe keeping 0-thickness layers is in the right way, even though technically - development wise it can be way too tricky - but in real world, paint is a minimum ~0 thickness, and if someone should differentiate paint finishes from room to room, can lead to creating a large number of wall styles, with fake minimum thickness of 1mm and that would lead to fake wall styles such as: 125mm partition is consisted in real life of 2x12,5 + 75 + 2x12,5 when is should be transformed to 12,4+12,5+75+12,5+12,4 which is automation wise a disaster.
My question to fellow VA users is: how do you deal with Construction Document-detailing stages and especially with finish paints and materials?
My question to VA dev team is: how should users deal with CD stages and especially with finish paints and materials? Which would be your suggestion on this?
In continuation with the above, overriding certain aspects of wall-slab styles maybe is something that VA team should investigate. In order to avoid multiple styles creation for reasons such as paint.
For example as a workaround we’ve developed part of a workflow: selecting a wall, deconstructing programmatically the exterior and interior layers, assigning materials to the exact faces of the exterior and interior layers’ breps, joining the faces back to brep, assign the brep to a desired layer and via API make the wall layer hidden in order to take over with the created brep. A big effort for such a simple need and of course I am dealing with bugs and lags on this.
Agreed on this. Would love to be able to assign multiple materials to a same style somehow. Like being able to see each of the components and change the material ‘by object’ to those components. It could be a similar approach to how you can offset the top and bottom of each material layer.
And then having a shortcut tool that is just a way to quickly paint the object you click on. Similar to how ‘extract surface’ works.
Often in the case of interior walls, I am often only interested in the color on one side of the wall if it shows up in a rendering. So the material is set to ‘by parent’ and then the entire wall takes the same material, even if it isn’t actually correct on the other side.
Otherwise I may extract the surface on one side, apply the material, and then move it out 1/32" or so to avoid z fighting, then put that surface on a layer that is hidden in the plan so there is no mix-up on dimensioning.
We plan to improve this in VisualARQ 4, so you will be able to assign a material to a face of a wall by object without having to create new wall styles or wall layers of 0 thickness.
