HebHeb

... and in a nutshell, this whole thread is exactly about that ;D It is not only the location and the nominal distance that matter, but also the projection / coordinate reference system behind the data. As far as I understand it, there is no single “best” system. Each system has its own advantages and disadvantages depending on the use case. In Germany, for example, even railway infrastructure uses dedicated local or project-related systems in addition to higher-level reference systems. Using Germany only as an example: the older Gauß-Krüger system and the now common official ETRS89 / UTM system are both conformal Transverse Mercator-based systems, but they behave differently. In Germany, Gauß-Krüger uses 3° strips and is true to scale on the central meridian, while UTM uses 6° zones and a central scale factor of 0.9996. So 100 m in the real world is not automatically 100.000 m as a 2D CAD distance. Very simplified, and looking only at projection effects, 100 m can be about 100.000 m on the GK central meridian and up to about 100.012 m near the strip edge, while in UTM it can be about 99.960 m on the central meridian and up to about 100.015 m near the zone edge. And if you compare a field-measured distance with a 2D CAD distance, height / ellipsoid reduction also comes into play. So yes, I am 100% on board with everyone here asking for better explanations, better workflows, and more clarity. But I also think it is in the nature of the topic that it is extremely complex and requires a certain amount of background knowledge if we want to keep enough flexibility in working with this kind of data. For me, the first step is therefore a basic understanding of surveying and geodesy. The second step is understanding what that actually means in the specific project context. And only then comes the third step: using a tool like Vectorworks to build a workflow that is practical and robust for your own project. And I think the main practical reason to really dig into this topic is if you want to use the newer WFS functionality in Vectorworks. If you are not working with that, then in my opinion a simple Cartesian user origin is usually perfectly fine. a graphic i like to show when teaching about this topic...

I am not 100% familiar with the exact English terminology, unfortunately, because I use the localized German version of Vectorworks. So it is not always easy for me to identify the precise English name of every Vectorworks-specific setting. What I mean is this: the file is georeferenced, meaning the blue origin is set based on an EPSG code and its related coordinates in Vectorworks. If one file contains this information, and the file you are copying objects from also contains the corresponding georeferencing information, then the objects can be transformed correctly according to the user coordinate system / EPSG code.

It depends 😄 If no GIS information has been applied beforehand, or if you are setting up your file initially, I would always choose the first option: “Do not transform.” If the Vectorworks GIS setup is already correct, then I would use either the second or third option when copying and pasting geometry from one file into another. As a landscape architect, I do not have a problem at all if architects work in their own “not real-world coordinated” file using pure XYZ vector geometry. But there should be at least one clearly defined reference point with known Cartesian coordinates that I can snap to. Also, the coordinates to snap on should be practical and reproducible, without endless decimal places. That part is always difficult to explain, but I think it is important: reference points should be numerically stable and reproducible, not based on floating values with never-ending digits. If I have that information, I can handle the building model, move it, and rotate it as needed. I was once taught by a professional surveyor that IFC and “real” georeferencing, in the sense of actually transforming geometry correctly into real-world coordinates, is something that is basically impossible and may never work perfectly. IFC is fundamentally XYZ vector geometry, and that is the core of the issue. On a smaller scale, such as for buildings, this is usually not a big problem. But for large-scale infrastructure projects like railway planning, I assume there are many more aspects that need to be understood and considered. And with the Vectorworks internal origin / blue-point origin and objects placed very far away, I sometimes feel that projects at that scale are not really what Vectorworks was originally made for anyway. As a landscape architect, I usually work on a survey that has already been transformed beforehand. That gives a very close match, but it will still never represent the real world with absolute perfection. The more I learned about this topic, the more confused I became, and the more I feel I may never fully understand it... But my main takeaway so far is: a vector is just XYZ, and a straight vector itself does not contain transformation logic. That said, I definitely understand the reason behind the Vectorworks GIS features. And since the last few updates, cross-referencing between Vectorworks files finally seems to work correctly. That was not really the case in the earlier stages, especially in Vectorworks 2024 and, if I remember correctly, the first updates of 2025. It also allows you to load WFS feature services directly into Vectorworks, which is a huge benefit. To be honest, this was already possible in QGIS before, and often with much more advanced data extraction (to reimport via shape, dxf and so...). But from what I have heard, Vectorworks plans to keep improving its WFS capabilities, which is very promising. tl;dr Use “Do not transform” for initial setup if no GIS info is applied Use the other options only when GIS is already set up correctly For coordination, one clear snap point with known coordinates is often enough IFC is basically XYZ geometry, which is why “true” georeferencing remains difficult Vectorworks GIS enables WFS integration > is much better now than in earlier versions...

some additional thoughts to consider: using just „world coordinates“ (given survey is already transformed or geolocated (i.e. in Germany, most common) using „real“ GIS-Geolocating Feature with EPSG Codes the seccond methos is of course the most professional and flexible, but if done without the needed expertise, it is not easy to handle… I struggle extremely to teach this every team member in a needed depth… when using in large projects, there is in fact a huge impact on performance when referencing across different files when updating them, the „transforming geolocated objects…“ takes very long loading times (often not worth the hustle when survey is already set…) when copying or transferring geometries in different systems, there are three methods (not always easy to choose which one to use… and most importantly, they give different results… so handle with care … )

You can import the DWG twice — this is usually how I handle it. Import it once as 2D/3D Object Conversion for the best 2D appearance. Import it a second time as 3D Objects only. With the second import, blocks that contain 3D information should be placed at the correct Z height. If I remember correctly, Vectorworks changed this behavior sometime between 2020 and 2022. In older versions, using the 2D/3D import option converted the blocks into symbols and preserved the correct Z elevation for each instance. In current versions, they tend to remain flat instead... Sometimes the imported objects also have a record attached that stores the correct Z values. If so, you can use that record field to set the Z height accordingly - in that case: no need for a 2nd "3D only" import. conversion option is found in advanced dwg import settings:

It’s possible to assign multiple data visualizations, but the order in which you activate them matters, it determines the sequence in which the criteria-based visualization is applied.

From a German landscape architecture perspective (i.e. real construction-oriented planning, not just early “design phases”), the Site Model in Vectorworks is conceptually very powerful - but still far away from what is needed in real-world projects, especially in terms of analysis and visualization. That is why I have spent a significant amount of time developing custom Marionette objects and scripts. One thing is very clear to me: the Site Model itself (existing + proposed terrain, components, modifiers) is far more powerful than what the current built-in analysis and visualization tools are able to expose. I think, as a community, we could come up with a coordinated "wish list" of what a Site Model should be able to do in a professional landscape architecture context. I am a bit short on time right now, but I will start with some initial brainstorming ideas: Analysis limited to a defined area (control geometry), not always the whole Site Model Analysis per Site Model component / stratum, individually and per defined area Workflows that exclude Hardscape and Landscape Areas on top without using “Cut Out Site Model” > so that only the actually required fill volume (excluding Hardscape / LA build-ups) is calculated Support for dynamic fill layers with thickness limits vs. unlimited layers … …and so on. I will come back to this thread later to add more thoughts - as mentioned, I’m a bit short on time at the moment.

We’re not using 2026 yet — we’re only testing each update, and unfortunately realizing every time that it’s still too buggy at the moment (existing trees, data mapping, etc.). I don’t see us using it before Update 4. When testing, the Grade objects behave exactly the same as in 2025. In my opinion, the Grade object should be a modifier-only object. A separate display/layout Grade object (possibly a Data Tag–based solution) should handle the visual representation only, without interfering with the grading network. That would, in my view, be the simplest and most straightforward approach. So any feature request in that direction (or as u said "layer only") would get my upvote 🙂 I kind of remember someone explaning me that the grade network can only be global (code wise...) ... but i actually can't belive that ;D

Q1: Duplicate the entire project. Otherwise, the grade networks are unfortunately "broken" as u described... To deal with this, I created some custom VectorScript tools that can repair grade networks or redraw them from the 3D polygon. However, with Vectorworks 2026 there are now some bugs again with my scripts... Q2: I strictly separate layout/display objects from site modifiers, even if this means "double" some modifiers that would otherwise be useful as layout or display objects. That is why, over the past years, I created my own Marionette objects specifically for layout and display purposes (useful if they need to exactly align on top of other objects...). These objects are not connected to the site model grade network. A quick workaround is: Simply do not create grade objects that are meant only for display on top of the existing modifiying network (slight offset does the job) This may not be obvious at first glance, but strictly separating layout and modifiers has proven to be a kind of bullet-proof concept in my experience. imho the 2026 grade update is less improvement then i hoped for...

I think I know what the issue is: When using viewport styles (with style-controlled design layers), their visual order is regularly messed up. Refreshing the viewport reorders them correctly again (as long as no custom order was applied). But here's a nice workaround: If you publish with batch export, you can check the option to refresh viewports while exporting.

I always use the list ordered and group > ungroup afterwards - works well for all 2D objects

I would wish for a "drape mode" for Curbs like Hardscape does (as addition to the actually sometimes really useful gravity mode)

Hello everyone, when combining the Get Item node with the Index node, the Index node outputs “-1” whenever the item is not found. As a result, the Get Item node receives an unexpected integer, which can cause an error or return an unintended element (because -1 points to the last list entry in Python). Wouldn’t it be more practical if the node simply returned an empty list in this case? Do you think there is any risk in modifying the node like this? In other words: Get Item returns an empty list whenever it receives “-1”. # This version of the Get Item node is designed to safely handle invalid index input. # It accepts a single index or a list of indices. Any invalid values are skipped: # - index = -1 (returned by the default Index node when no match is found) # - None # - values that cannot be converted to integers # - negative or out-of-range indices # # Only indices within the valid range 0 ≤ index < list length are used. # All valid matches are returned as a list of items. # # This prevents errors when the Index node outputs -1 and avoids unintended # behaviour such as retrieving the last list element due to Python’s negative indexing. @Marionette.NodeDefinition class Params(metaclass = Marionette.OrderedClass): # APPEARANCE this = Marionette.Node('Get Item (Safe)') this.SetDescription( 'Returns elements at the specified indices. ' 'Ignores -1 and invalid indices. ' 'Accepts a single index or a list of indices.' ) # Input Ports list = Marionette.PortIn([]) list.SetDescription('The input list') index = Marionette.PortIn([], 'iIndex') index.SetDescription('Index or list of indices of the items to return') # Output Ports item = Marionette.PortOut() item.SetDescription('The resulting items as a list') # BEHAVIOR this.SetListAbsorb() def RunNode(self): # inputs iList = self.Params.list.value idx = self.Params.index.value # --- Normalize index: allow single value or list --- if isinstance(idx, (int, float)): idx_list = [int(idx)] elif isinstance(idx, (list, tuple)): idx_list = list(idx) else: # last fallback – try to treat as iterable try: idx_list = list(idx) except TypeError: idx_list = [idx] l = len(iList) result = [] for at in idx_list: # filter special cases if at is None: continue # skip "not found" marker from default Index node if at == -1: continue # convert safely to int try: i = int(at) except (TypeError, ValueError): continue # allow only 0 <= i < l – prevent negative Python indexing if 0 <= i < l: result.append(iList[i]) # outputs self.Params.item.value = result

Thanks, that helps a lot! Index handling I created a small helper node that lists the indices so I can keep track of them. (The Symbol Resource... hope that this list is synced to the Marionette Commands menu items... at least in my Marionette Coommandy Libary.vwx the saved wrappes are the only resource existing) res_list, count = vs.BuildResourceList(16, 0, '') I only ran a quick test with a few items, without renaming or adding new ones. So I’m curious to see how the indices will change once I start renaming entries or inserting new ones. If you have any additional information on how the index logic behaves, that would be great! I hope they are static and just add up when new ones are created 😄 And if anyone here is obviously more experienced than I am and has better ideas, I’d really appreciate hearing your input. Maybe there’s even a way to match the menu command by its name instead of the index. In a large command library this would be much more convenient — especially since the indices might not be static and change over time? Executing the menu command I tested the menu call in both VectorScript and Python. VectorScript (doesn’t work): DoMenuTextByName('CExtMarionetteMenuDyn', 1); RedrawAll; nothing happens. Python (works — absolutely amazing!): import vs vs.DoMenuTextByName('CExtMarionetteMenuDyn', 1) vs.ReDrawAll()

Hello Marionette and Scripting Experts, Over the years I created many Marionette commands and objects. I originally saved my commands as *.py files and converted them to *.vsm plug-ins via the Plug-In Manager so I could organize them neatly in our custom workspace. As my networks grew more complex, this approach showed serious drawbacks — produced odd error messages and were not user-friendly. I’ve since learned that Marionette commands work far more reliably when stored as actual Marionette Commands inside Marionette Command Library.vwx, instead of exporting them as *.py and store them as Vectorscript plug-ins. I now also have a working solution to roll out this library file from a central source to all Windows workstations (iside their appdata folder) My question Is it possible to: trigger a Marionette Command from Marionette Command Library.vwx via a small Vectorscript and then create .vsm plug-ins that simply call this trigger? This would let me keep all real Marionette logic inside the shared library file, while still organizing the commands cleanly inside the workspace (including shortcuts). Has anyone done this before, or knows whether it’s technically feasible? Managing a large command library becomes visually confusing otherwise 🙂 Thanks in advance!