Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by Stéphane

  1. 2 hours ago, line-weight said:

    Right, so it looks like it's yet another dysfunctional tool, and a problem that has persisted through at least 4 releases of VW?


    After having done several tests, I would share your conclusion. It is dysfunctional. 


    - doesn't work if your roof has a hole in it 

    - doesn't work if one roof face is flat 

    - doesn't work if the intersection is not perpendicular to the roof edge 



    • Like 1
  2. Might have found the beginning of an explanation... It doesn't work properly when you connect a flat roof (0.0000000°) with a tilted roof. When I fake the flat roof (0.00000001°), it works better. I say "better" because there is still something weird happening but I cannot exclude it's a design issue. @line-weight, does your issue (the post you linked) involve a flat roof ? 



  3. Thank you very much, @line-weight, for you quick answer. 


    I have already tested this combine/connect tool, but it wasn't satisfactory. Is it the same problem you mentioned in your unanswered post ? 


    Dual Object Connect join them vertically, as shown below. This is precisely what I don't want because it generates a "gap" resulting in an none-continuous component. 




    Dual Object Combine give me an error and doesn't do anything. Theoretically, is it this mode I should use for my purpose ? Do you believe it could be a geometry issue ? 


  4. Hello, 


    I have two roof faces - highlighted in orange. I want them to intersect on my red intersection line as shown below. In other words, I want my edges A and B to be tilted - not vertical. Is there a way to do this ? The goal is to have nice continuous components in Section VP.


    I would appreciate your advices.  





  5. In order to not let this topic fall in the oblivion pit (because I really need an answer), let me relaunch this topic with related questions : 

    - How do you manage lineweight in section VP in your practice ? Do you set your class with its section attributes (typically thick lines) or its beyond section attributes (thin lines) ?

    - In my first post, did I expose my issue clearly enough ? Do you need further explication in order to answer ?  

  6. Hello, 


    I'm working on my workflow and there are still little things that I don't understand... 


    A cut wall takes its component attributes and a wall beyond the section line takes its wall attributes. Somehow, this logic doesn't work on slabs. Why ? Am I missing something ? Is it a bug ? Is it as it should be ?  


    My general problem is the following : 

    Objects that are beyond section line need to have thin lines (0.05-0.10)

    Objects that are cut by the section line need heavier lines (0.18-0.25) 

    Important objects (like structures) that are cut by the section line need even heavier lines (0.35-0.50) 


    I haven't found yet the way to do it ! How to achieve this ? This is something I need to produce proper architectural plans. 


    A workaround I am still using is to set a class attribute for Object Beyond Section Line in Advanced Properties. Issue with this workaround : 

    - Surface Hatch will have the same color as other objects beyond section line (but it is a no go because I want my surface hatch to be colored and other objects to be black)



    Please see below a commented screenshot to illustrate my issues... 



    I would appreciate your help and/or advice on best practice. 



  7. 32 minutes ago, bcd said:

    It looks like you're viewing a Section Viewport with the Advanced Properties>Attributes>Line Style set to something other than 'Use Original'


    That was it ! Well done @bcd

    For Objects Beyond Section Plane in Advanced Properties>Attributes, I used "Use Class". 


    But I have now another issue...


    My class attributes are set to have their section style. So I need the "Use Class" option in order to lighten the line weight of objects that are beyond my section plane. This is a super nice way to have an accurate control of section line weight class by class. If I choose "Use Original"  for Objects Beyond Section Plane, off course they will appear too thick. So here is my question : What is the best practice ? 


    I find the other options not very handy to control section line weight. 

    I know there is the option "Create Structural and Nonstructural Groups" but that get me two line weight. I need at least three different section line weight. One for structural elements. One for non-structural elements. And one for small or thin elements, like frames/glass/tiles. Plus, it removes the components hatches, if Im not doing it wrong. 


    Ok, there might be a huge translation issue, since I'm using the French version. Sorry for that, I should have checked this before. 

    In my version, I have three Foreground render options : 


    - "Sans" : None 

    - "Lignes visibles uniquement" : literally "Visible lines only" which must have been badly translated since it is actually "Hidden lines" in your version. 

    - "Lignes cachées en pointillé" : literally "Dashed hidden lines". 

    In other words when you spoke about "Hidden lines" I thought you were speaking about "Dashed hidden lines" and when I spoke about "Lines" I actually wanted to speak about "Hidden Line". 


    So, now we know that we speak about "Hidden lines".... 


    To clarify and to answer to @Tom W. and @markdd

    "Hidden lines" can be used as foreground or background render. Of course, when no foreground render is used, then I use "Hidden lines" as a background render. In both cases, my surface hatch is black. Why ? 


    Please, see below a screenshot. 






  9. 1 minute ago, markdd said:

    Surface Hatches can only be seen in Hidden Line render style. When you say "Line", do you mean "Wireframe"?


    No, Surface hatches can also be seen in Line render style. When I say "Line", I don't say "Hidden line" which is another Foreground option. 

  10. To elaborate a bit


    There are two types of hatches

    - Regular hatches 

    - Surface hatches that are regular hatches associated to a texture 


    In my VP I have only a Foreground render which is "Line". No background render. 

    In it, my regular hatches are fine and colored, but my surface hatches are always black. The textures itselves don't show up which is the normal behavior.

  11. I believe surfaces hatches associated to a texture are generated in "Line" and "Hidden Line". So it must not depend to the background render you are using. 

    My other hatches show up fine (for instance the ones I am using for my slabs and walls). 

  12. On 6/19/2018 at 5:14 PM, PVA - Jim said:

    You MIGHT be able to get proper results if your base attribute colors on the tubes are the only thing controlling color. 


    Had a similar issue than @Anthony Neary, and this was the correct solution for me. Thank you.  



    On 6/19/2018 at 5:14 PM, PVA - Jim said:

    I normally recommend controlling the glow's color via the Glow shader itself directly, and leaving the base Color shader of the texture set to pure white or a warm/cool white instead. This means creating and applying more than one Glow texture, but I find it's much better at giving me control over the end result. 


    This works as well but in my case I preferred to assigned a color to each light individually, precisely because I don't want 300 glow textures. 

  13. I have done this morning additional tests, following your suggestions. 

    For some reasons, I can now export to a readable IFC from my original file again, which includes DLVPs. The only thing I did in between was hiding more layers and class. I haven't even restarted my computer or VectorWorks. I guess that an objet in one of the hidden class is corrupted OR too many informations needed to be exported. I don't know for sure. 



    2 hours ago, _c_ said:

    if I understand correctly what you did, you are exporting one building pro design layer. You assemble the buildings using one singular DLVP pro building, am I right?


    Yes, this is correct. To be slightly more accurate, the right side building is made out of 2 DLVPs : 1 DLVP for stories 1 to 4, another DLVP for story 5 (as shown in one of post above). As you can see on the pictures below, it works in IFC2X3. Surprisingly. 



    2 hours ago, _c_ said:

    About IFC 4: VW is certified for IFC 4 export, import isn't there yet. 

    More here:


    Depending on how strict your exchange requirements are, you might be better off with IFC 2x3 and since we cannot import properly what others send us, I definitely suggest you to agree upon IFC 2x3.


    Very interesting informations. I will bookmark the link. Thank you very much. 



    14 hours ago, zoomer said:

    I think it is best to check the IFC files in Solibri or similar,

    to exclude what is an VW IFC export error from VW or Revit

    import issues.


    Thank you for your suggestion, it helped me to understand the issue. I downloaded Solibri today (yes, I'm new to BIM). And here are the results :  



    1. IFC2X3 



    2. IFC4



    Important note : Last layer of Building n°1 (left), Building n°2 (mid) and Building n°3 (right) are made out of DLVPs. Several conclusions : 


    - DLVPs are actually IFC friendly, but only in version 2X3. DLVPs won't work properly in IFC4. The building you see on the foreground, is actually my Building n°2 but positioned on its source (Building n°2 is a DLVP from this foreground building). This confirms my previous theory. 


    - VW still has export issues in IFC4 (see ramp issue and DLVPs already mentioned) 


    - It seems possible to use multistories DLVPs. There is at least no graphical bugs. I guess the issue will be that my Building n°3 will be considered of having only two stories (one made out of 4 stacked slabs). But since we are drawing in BIM level 1, it's not really an issue for us. Or I don't see it yet 🙂 I believe, as @_c_ suggested it, it would be more adequate to map only one story per DLVP to do things properly. 



    Two good news : 


    - I can now send an IFC file to my engineer 

    - My engineer won't kill me 



    Thank you very much for your precious help ! The BIM shower is a bit cold but it will be ok. 

    • Like 1
  14. Progress has been made, thank to your dedication, thank you. 


    So, DLVPs from Building n°3 have been erased and replaced by regular copie/paste in place. Now it works. Conclusion : Issue comes from DLVPs. 





    I recap here my questions : 


    - How to properly set the DLVPs in order to be exported in IFC ? For some reasons, my DLVPs stay at their source position (Building n°1) in my IFC file instead of forming my Building n°3 (like in my VW file). See my posts above. @shorter @_c_


    - My test file (which consist of erasing most of my drawing) can export an IFC file and read it back, but my original cannot. Why ? Is it linked to this DLVP issue ? Is it simply because the file was too heavy (is it why @shorter you suggested to export the buildings one by one) ? Could it be that some objects are too complex (likes 3d trees) ? 


    - About the weird ramp issue, your intuition, @zoomer was correct. Well done. It is an IFC4 issue. If exported in IFC2X3 this problem doesn't occur anymore. 


    Little by little, with all of you, I start to see the light at the end of tunnel. Thank you. 

  15. @shorter, I'm sorry but I'm not sure to fully understand. I gladly admit that I am still a bit new to VW. 


    What is true space ? 


    I can say that the Z lvl setting of DLVPs is not very intuitive. If I set it to 0 or to its absolute correct Z coordinate (Z value in the IOP), then it moves completely off. I have to graphically set it back in place, but then the Z coordinate has a strange value (or negative either very high).


    Layer 4: altitude 59680 cm (above sea) (this value is set in my layer organisation window)

    Layer 1: altitude 58810 cm (above sea) (this value is set in my layer organisation window)

    my DLVP comes from Layer 1 but need to go above layer 4. What should be its Z value (in layer organisation window and in IOP) ?  0, 58810 + 1160 (equivalent to 4 stories times 4), 1160, or something else ? 


    Anyway, this is for the Z issue. How to explain the X and Y offset ? Why in my IFC file, the VLPDs stay at its orignal position ? 



  16. I believe I owe you at least some screenshots to help you understand my issue... 


    1. VWX file




    2. IFC file




    By the way, why is my ramp (dark blue object) rotated on the Y axis in my IFC file ? (The civil engineer will kill me)



  • Create New...