Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by twk

  1. is there a nil object in python? In any case, for handle error checking I normally use: # based on your example worksheet = vs.GetObject('WS_TEST') if worksheet not in [None, 0]: vs.CreateWS(('WS_TEST'), 2,2)
  2. As @Pat Stanford suggested, the vectorscript editor should be adequate for marionette editing. I personally use PyCharm. Much more robust, for actual plugin development, version control, managing external libraries as well. They have Windows and Mac versions as well https://www.jetbrains.com/pycharm/download/#section=windows
  3. There's a great resource on this on the Dev Wiki by @_c_. https://developer.vectorworks.net/index.php/User:CBM-c-/VS-List_Browsers_part_1 It is one of the last frontiers for me to tackle for vectorworks scripting.. a bit of a read, but very well documented.
  4. Ah, @BillW, these are great. Much cleaner to implement as well.
  5. I'm not sure the function itself shortens the variable 'p'. It overrides it completely with whatever the GetPolyPt or any other function spits out. Which in the case of the GetPolyPt is a 2-dim tuple. So in the case of the vs.Vec2Ang() function, that particular function 'requires' a 3-dim tuple, when you are passing values from GetPolyPt into the Vec2Ang function you'd have to unpack the values you get from GetPolyPt and add a 3rd value. p = vs.GetPolyPt(handle_to_poly, 1) ang = vs.Vec2Ang((p[0], p[1], 0)) # the third value 0 is added by you I think we are coming to the same conclusion, I'm just a bit thrown off by your original post stating "If you passed some z values before in the third slot, you'll loose them". From my knowledge whatever 'p' was before you set it is overwritten with this new value and type. I also just saw your commenting on the DevWiki which explains things very clearly.
  6. I'm not following. Maybe this is a python thing, but the value of your variable 'p' gets overwritten once you set it to vs.GetPolyPt(vs.FSActLayer(), 1). The GetPolyPt function always returns a tuple of 2 values. So whatever 'p' was before will become whatever GetPolyPt gives it. eg. p = "Hello there" print(p) # "Hello there" p = (0,1,2) print(p) # "(0,1,2)" variables in python are dynamically typed.
  7. I use the McLeonards one for 2D vector calcs at the moment. For scalars and other basic arithmetic with vectors. Never seen the 3D one before, looking through it now. Thanks for the share!
  8. Maybe comparing The Gaming Experience/Industry vs The AEC Industry is an apples vs oranges comparison. What the UE5 release is showcasing really, is a bit more to do with how the developments in gaming software (ie Unreal Engine) has caught up-to, and surpassed, both the Film and AEC industry and actually leading the charge now in technology foresight. It's more of, there is now a gaming engine, which CAN accurately hold and display REAL-WORLD data on the fly, with minimum computing power. Which has effects in the real world in our industry. Overturning the traditional workflows of large studios, render farms, render times, etc. Everyone is having to rethink things. An architectural firm, which used to outsource renders to a specialised archviz studio, can now do it in-house, with renders that only take a day for videos flythroughs, seconds for still images. Real-world context can now be imported at the click of a button.. no more time-consuming travelling to site, etc. eg below. Theres a lot that what Unreal as a company is doing that will potentially change how we do things.
  9. I think you raise fair points. And to be honest, we HAVE been hearing and seeing virtual reality since the early 90s. Yet the industry (AEC) has yet to fully adopt it in that time. At the moment, I do believe CAD is still needed in the meantime, ONLY because the medium with which we are transferring our designs to site is still in 2D format. PDF's, printed drawings etc. And sure with the advent of HoloLens and other AR solutions, the game is looking more and more adaptable to change. Some notable things with the UE5 release, is that these are things that we're never though possible with current gen specs, let alone, consumer grade specs. It's the accessibility for those on lesser budget/team that is eye-opening.
  10. I believe it still is there, cos as you're exporting models/materials/assets to Unreal engine, all the geometry and BIM Data is in the Unreal project file. The 'magic' I believe on display (no pun intended), is that all that info is not accessed/visible until the user needs it. Sort of like streaming for online videos.
  11. Also, whenever I think of something showing up as just hype (bitcoin, crypto, NFT's, metaverse), I think of articles like this:
  12. It sure does feel like we're on the back end of an era, getting phased out. Had a conversation with a colleague the other day, about how NFT's will be the real-estate of the meta-verse. And how virtual architecture on the meta-verse will be the evolution of our discipline. I for one am always skeptical of any hype, however, things are exponentially moving nowadays its getting harder to grasp new concepts before the next one comes along.
  13. We had thought about this workflow in the past but never went this route after project sharing came in. Ever since project sharing was announced we have been using it (together with all its issues). There were more cons than pros with using the WGR(Work group referencing, either via Viewport or Layer Import) method or splitting the project into PLOT and MODEL(Design) files. Eg's 1. WGR explicitly splits the tasks for a project. A single user working on the PLOT file must wait for the work in DESIGN file to be completed, update the source, then publish. Upon seeing any mistakes, must then work on the DESIGN file, save, refresh in PLOT file, then publish. It is an 'old style' of project sharing, and works, however on larger files, having to wait for the DESIGN file reference to update can eat up time. With project sharing we've noticed, comitting/refreshing takes much less time, even quicker on VW 2021. 2. Data tags, section-to-viewport referencing do not work with WGR With Project sharing, having everything in a single file just makes it easier to manage things. Like classes, saved views, detail marker to viewport referencing, titleblock revisions, storeys, etc. HOWEVER, for it to work, it requires ALL users to understand the problems with it to properly troubleshoot and possibly avoid them all together, they include: 1. Avoid save and committing at the same time as other users 2. After every save and commit, confirm that you're changes are saved. Either by opening a fresh copy of the project file, or asking a coworker to refresh to check if your work has been committed. 3. Save and commit a the end of the day, unless necessary. 4. If/When the file crashes during committing, always check project file first to check if your changes have been committed. Sometimes they have, and committing from a crash file will corrupt the project file. If they haven't and your locked out because the project file thinks you're a new user/opening a new working file, get the admin to release your work and manually copy in your work from the crashed file. We fought with project sharing since its inception, but the benefits outway the other workflows, we've found. With regards to PDF sizes, the following option seems to help:
  14. From my experience, any plugins created before the latest version work with the latest version -- IF -- they are not using depreciated function calls (alot got dropped in 2012). But if you're wanting plugins to be backwards compatible they have to be created/edited in that version to work with that version. E.g You create a plugin in version 2018, and then come 2021, a new version gets released and all should be well (from what i know, no functions were depreciated in 2021). However, once you make any edit to the plugin using the plugin manager, under 2021, (eg add a parameter, remove a parameter, change a parameter name, etc), that action breaks backwards compatibility. If you point your script to an external source and are changing script code in an external editor, this doesn't seem to affect the *.vso or *.vsm files. So if you are want to do edits to the plugin via the plugin manager and still maintain the backwards compatibility you'd have to do it in the earliest version (in this case 2018) you want compatibility for. Again, my own experience.
  15. Wrap p1 in str(p1) instead. That's using python to convert any data type to a str type.
  16. You can find it on this page: (Scroll to bottom of page) https://developer.vectorworks.net/index.php/Vectorworks_Scripting#Version_Information
  17. Here is a stripped out version from my custom python library for a geometry object. In this case the object must be a 3D type (Mesh, Extrude, 3DPoly, Nurbs, etc); And this is only for the 3D bounding box points. Josh is right, if its a mesh object, there are function calls to get the actual vertex points. import vs class GEOMETRY3D(): class POINT3D(): def __init__(self, x, y, z): self.x = x self.y = y self.z = z def __sub__(self, other): self.x -= other.x self.y -= other.y self.z -= other.z def __add__(self, other): self.x += other.x self.y += other.y self.z += other.z def mid_point_to_other_point(self, other_point): return def length_to_other_point(self, other_point): return def get_offset_pt(self, offsetX=0, offsetY=0, offsetZ=0): return GEOMETRY3D.POINT3D(self.x + offsetX, self.y + offsetY, self.z + offsetZ) def __init__(self, handle): self.handle = handle self.generate_bounding_box() def generate_bounding_box(self): self.top_center = GEOMETRY3D.POINT3D(self.center.x, self.center.y, self.center.z + (self.depth / 2)) self.bottom_center = GEOMETRY3D.POINT3D(self.center.x, self.center.y, self.center.z - (self.depth / 2)) self.top_back_left = self.top_center.get_offset_pt(-self.width / 2, self.height / 2) self.top_back_right = self.top_center.get_offset_pt(self.width / 2, self.height / 2) self.top_front_right = self.top_center.get_offset_pt(self.width / 2, -self.height / 2) self.top_front_left = self.top_center.get_offset_pt(-self.width / 2, -self.height / 2) self.bottom_back_left = self.bottom_center.get_offset_pt(-self.width / 2, self.height / 2) self.bottom_back_right = self.bottom_center.get_offset_pt(self.width / 2, self.height / 2) self.bottom_front_right = self.bottom_center.get_offset_pt(self.width / 2, -self.height / 2) self.bottom_front_left = self.bottom_center.get_offset_pt(-self.width / 2, -self.height / 2) @property def bounding_box_points(self): """ Top to bottom, Top Left Back to Top Front Left Counterclockwise --> then Bottom.. :return: """ return self.top_back_left, self.top_back_right, self.top_front_right, self.top_front_left, self.bottom_back_left, self.bottom_back_right, self.bottom_front_right, self.bottom_front_left @property def center(self): ptxy, z = vs.Get3DCntr(self.handle) return GEOMETRY3D.POINT3D(ptxy[0], ptxy[1], z) @property def height(self): return vs.Get3DInfo(self.handle)[0] @property def width(self): return vs.Get3DInfo(self.handle)[1] @property def depth(self): return vs.Get3DInfo(self.handle)[2] # obj3D = GEOMETRY3D(vs.FSActLayer()) # for x in obj3D.bounding_box_points: # vs.Locus3D(x.x, x.y, x.z)
  18. As soon as I went back into Vectorworks, I figured out what the issue was. I'm in a project sharing file, and even though I had all the walls checked out, I had to check out the the WinDoor objects as well. I think this is by design, as the Data Manager does a document wide setting when in use. Working now.
  19. Trying to add a data sheet to the WinDoor object (@Julian Carr), however the Data Sheet is shown grayed out still on the Object Info pallette Data Tab. Also the WinDoor needed to be added manually to allow for Data Mapping, it wasn't set by default. Also the WinDoor object already has IFC data on it? Is this programmed internally? I would like to setup a datasheet to just show the ID and certain UserID fields. Any help is much appreciated.
  20. Thanks @Vlado and @Dave Donley, I managed to sort it out. Using the vs.GetAssociation calls on the texture resource handle
  21. With a bit of trial and error, and crossing my eyes through DebugList view, it turns out, the vs.GetAssociation(handle, i) and vs.GetNumAssociations(handle) did the trick. The debuglist view did show the hatch handle, buried under a AssociationNode.
  22. Does anyone know, how we can find out what hatch is being used in a particular texture? Has it got anything to with Shader Records? I can't seem to find anything. https://developer.vectorworks.net/index.php/SDK:Using_Shader_Records @Rick Berge @Vlado @JBenghiat
  23. I have been using the python external libraries openpyxl and pandas dataframes for data exchange between vectorworks and excel. They have very good documentation. https://openpyxl.readthedocs.io/en/stable/ https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.html
  • Create New...