Jump to content


  • Posts

  • Joined

  • Last visited


5 Neutral

Personal Information

  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That workflow is genuinely unusable. Nobody is going to swap out millions of fixtures across all their existing drawings for a different symbol. To a first approximation, 100% of fixtures in common use do not yet have a proper GDTF. The majority never will. The Vectorworks 2022 Resource Library does not appear to contain any GDTF fixtures at all. This is the primary (and in most cases only) source of fixture symbols for Vectorworks Spotlight users. Capture and Cast Wysiwyg both generate custom GDTF files containing the data it knows about the fixture when exporting to MVR. While the GDTF they generate don't contain much DMX slot info so would not be used to control the fixture in a lighting console, it is sufficient for the user to match up to a "real" fixture within the receiving software, and for the receiving software to configure the user's choice to match the configuration within Capture. That is how it must work if MVR is to be a useful form of interchange. For the avoidance of doubt, are you saying that Vectorworks is deliberately throwing away all that information?
  2. Add a Source Four LED S2DS 50deg symbol from the Resource Library Note that the Beam/Field Angles are 49/50deg Export MVR Note that the Beam and Field angles in the MVR are 25 deg And that it's mysteriously become a moving head SourceFour50.vwx SourceFour50.mvr
  3. Thanks Tim Can you please add this information to the SDK documentation? I'd also really appreciate it if the SDK documentation could be updated, it really seems like it's not been touched since 2018 or so!
  4. This may be due to a Vectorworks 2022 bug that is still present in SP3.1 The MVR exported by Vectorworks 2022 SP3.1 states that it is MVR 1.4, which only permits the legacy 3DS format. However it is using MVR 1.5 features, such as glTF/GLB for geometry. The version number needs to be updated so importers know what format(s) to expect.
  5. It appears that the Beam and Field angles entered always ignored when exporting an MVR. If I used a GDTF, I always get the "default" values from the GDTF. If there is no GDTF for my fixture, (as is almost always the case), then I get 25deg no matter what. This feels very broken.
  6. It would be appreciated if you could add some information to the VWX MVR export dialog stating what actually is going to be exported from a given drawing. Otherwise users are going to be very disappointed when they find that so much of the data they entered into their drawing vanished - or changed.
  7. Actually, it's worse than that. It seems that Vectorworks exports exactly the same light source and beam information for every fixture: This section appears to be exactly the same in every "Custom@" GDTF exported by Vectorworks: Source Four, Source Four LED, Robe Robin BMFL Blade, Arri Skypanel S360-C - all the same!
  8. VWX2022 SP3.1: I have a drawing containing a selection of Source Fours with different lens tubes fitted (19, 36, 50 etc) using the standard resource symbols. In the drawing, Beam Angle, Field Angle, Beam Angle 2 and Field Angle 2 were automatically set appropriately. However, the MVR export says the Beam and Field angle is always 25 degrees. I don't see anywhere in the MVR GeneralSceneDescription that's specifying the beam angle, the only place seems to be in the generated "Custom@Light Instr ETC Source 4 LED2DS XXdeg.gdtf". That Custom@*.gdtf is always saying "25" for BeamAngle and FieldAngle, regardless of the fixture symbol or my custom settings. Can this please be fixed? It makes MVR almost useless for transferring rig information.
  9. @Vlado JBenghiat is correct. Debugging a Vectorworks plugin is only possible if one of the following applies: You compiled Vectorworks itself on that Mac Your Mac has access to the Vectorworks private developer keys You have disabled macOS SIP security features. Obviously the first two are not possible for anyone outside Vectorworks. Apple do not support disabling macOS SIP security features, and have indicated to us that they will be removing this possibility in future macOS updates. Several Apple support agents have insisted it's not possible at all on Big Sur/M1, so I've been holding off upgrading my Mac
  10. The xcode debugger cannot be attached to Vectorworks in any currently supported version of macOS. Apple support have insisted to me that the only solution to this is in Big Sur or later is for Vectorworks to enable the "get-task-allow" entitlement. Can this please be done in the next VW2021/2022 service pack and future updates? If it cannot be done due to Apple's signing or notarisation rules, can Vectorworks please raise a formal issue with Apple regarding this issue, and let us know their official response? It is strictly necessary for all developers to attach a debugger to macOS applications that have a plugin architecture. While it still appears to be possible to use Recovery mode and csrutil to enable debugging, this is a very large sledgehammer. Worse, Apple's response to my support request indicates it is going to be removed. This kind of problem is making it very difficult to justify continuing to support a macOS version of our plugin, as any issue that we cannot reproduce on Windows will never be resolved.
  11. Thanks bbudzon. That is the rpath I tried in my Dec 8th build, so I guess that's probably correct and not the cause of the remaining issues. I'm rather surprised that Vectorworks haven't tested building a Qt-based plugin using the published SDK and VWX/Qt libraries. Can this test step please be added to your pre-release process, and the necessary build steps documented in the SDK?
  12. Qt, not Quicktime. Vectorworks uses Qt for some things. 2022 SP1 ships with Qt 5.12.10 on macOS. Our plugin uses Qt as well so we need to ensure our plugin loads the ones provided by Vectorworks.
  13. Thanks. The main issue I seem to have is linking and loading an appropriate set of Qt libraries. I haven't been able to prove this yet, so it may be something else.
  14. I'm trying to upgrade our existing Vectorworks plugin to support 2022. On Windows this was very simple, I just added an extra configuration that configured the paths and libs for the 2022 SDK instead, and this works just fine (with the same caveats as before that the VW SDK .props file must be imported before anything else) On macOS, adding the new Target appears to compile but does not result in a working plugin on either Intel or M1 Macs, whether forced Rosetta2 or not. (Big Sur and Monterey) Our plugin uses Qt5, and it looks like the loader paths have changed for this. I've tried updating them to the same Qt5 loader path used by the Vision dylibs that ship with VW2022 SP1.1, but this still does not work on any platform. How can I determine what is preventing the macOS edition of the plugin from loading?
  15. The MVRs exported from Vectorworks are including a lot of completely empty 3DS files - no faces, not even any no vertices. Seen in both 2021 and 2022. Eg All the Prolyte truss symbols are exported as two 3DS files. One of them contains the truss mesh, the other is apparently completely empty. The MVR export is also including all my 2D-only layers, complete with an empty 3DS file for every item. This results in really huge lists of 'blank' models when the MVR is imported into other software, as well as totally empty (and very confusing) blank hierarchy. In a recent export 42 out of 100 3DS files were completely empty, this made finding the actual models in the other software really difficult! I believe these blank 3DS files are in fact 2D symbols (or 2D parts of a symbol). These clearly shouldn't be exported!
  • Create New...