Jump to content

Search the Community

Showing results for tags 'level types'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements
    • Announcements
    • News You Need
    • Job Board
  • Feedback
    • Roadmap
    • Wishlist - Feature and Content Requests
    • Known Issues
    • Wishes Granted / Issues Resolved
    • Forum Feedback
  • General
    • Troubleshooting
    • General Discussion
    • Architecture
    • Site Design
    • Entertainment
    • Vision and Previsualization
    • Braceworks
    • ConnectCAD
    • Energos
    • Rendering
    • Workflows
    • Buying and Selling Vectorworks Licenses
    • Hardware
  • Customization
    • AI Visualizer
    • Marionette
    • Vectorscript
    • Python Scripting
    • SDK
    • 3rd Party Services, Products and Events
    • Data Tags
  • Solids Modeling and 3D Printing
    • Subdivision
    • Solids Modeling
    • 3D Printing
  • Vectorworks in Action
  • Archive
    • Resource Sharing
    • Machine Design

Calendars

  • Training Events
  • Coffee Breaks
  • Essentials Seminars
  • Webinars
  • Community Groups

Categories

  • Knowledgebase
    • Tech Bulletins
    • Troubleshooting
    • Workflows
    • How To
    • FAQs

Categories

  • Marionette - Objects
  • Marionette - Networks
  • Marionette - Nodes
  • Marionette - Menu Commands

Product Groups

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Occupation


Homepage


Hobbies


Location


Skype

Found 4 results

  1. Wish: I'd like support for split levels built directly into the Stories feature. Reason: For projects with split levels (floors on the same storey with different heights) we currently have to create multiple Level Types (e.g. FFL-0, FFL-200, FFL-300) to deal with each split level (and the same goes for projects files with multiple buildings at different heights). This adds an enormous amount of complexity to an already complex feature. I don't think Level Types is the right place to provide this capability. It means that any standard Level Types one would typically have in a model (e.g. FFL) need to be multiplied by the number of split levels you have (e.g. FFL-0, FFL-200, FFL-300), creating unnecessary complexity and management overhead. If we want to control top and bottom bindings by Wall Style it then means multiplying all our Wall Styles so they can bind to the relevant Level Types (FFL-0, FFL-200, FFL-300) and then you have the issue of visually identifying these different Wall Styles to make sure they don't end up being used on the wrong split level. And/or it means we can't copy a wall across from one part of the building to another without being forced to redefine the top and bottom bindings to suit that level Possible Solution: Story Groups Each group of storeys could have its own elevations defined independently of other storeys - Story Group 0: Story-0-0, Story-1-0, Story-2-0 - Story Group 200: Story-0-200 Story-1-200, Story-2-200 - Story Group 300: Story-0-300, Story-1-300, Story-2-300 That would allow us to maintain standard Level Types (e.g. FFL-0) that would work across Story Groups (e.g. FFL-0 would be the same definition across split levels, and the Story Group would control any elevation height difference between split levels.) Which means we could have Wall Styles with top and bottom bindings defined by Level Type that work across split levels. And/or we could copy a wall from one split level to another and not be forced to redefine the top and bottom bindings Result: The result, when dealing with split levels, would mean less Level Types, less Wall Styles and less manual manipulation of top and bottom bindings.
  2. We'd like to be able to replace Level Types with a new or existing Level Type when deleting one—as we can with Classes, etc.—and for objects currently using those Level Types to then use the new Level Type.
  3. <sigh> I've just wasted four hours I didn't really have manually transferring levels across from my model file to a (Layer Import) Workgroup Referenced file. Half of which was spent trying to figure out why some walls weren't showing, only to finally clock that I had spelt one of the levels slightly wrong when transferring it. Please stop putting us through this special kind of hell ❤️🙏🏼
  4. I find there's a balance to be found between the number of Levels in a model and just offsetting from existing Levels. I'm curious to know if anybody has settled on a set of rules or principles for setting up additional Levels vs using offsets? The current file I'm working, for instance, has the following levels.
×
×
  • Create New...