Jump to content

Richard1

Member
  • Posts

    40
  • Joined

  • Last visited

Everything posted by Richard1

  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!
  16. Tested with Collada and FBX: Exporting "Soft Goods" produces a single-sided mesh with a single-sided material. This means my drape is often invisible from the actual front when imported into 3D applications (tested with Blender, ETC Augment3d & MA3D), while it is visible from the 'back'. However, I cannot find any way within VWX to either visualise or define which side of my soft goods is the 'front', or to specify that they should be exported double-sided. How do I specify which side of the drape is the front, or (better) that a particular drape should be exported double-sided? The closest thing to a workaround I've found is to export it, import it, then either rotate it 180deg or redraw it but starting from the other end if it's wrong. This is really slow and tedious, and doesn't work for drape that I need to be double-sided. Note: Collada and FBX do not officially support specifying a mesh or material as double-sided, so for maximum compatibility any double-sided meshes should be exported twice, once facing each direction. There is however a Collada material extension "double_sided", this is not part of the ISO standard but is widely supported (eg used by Google Earth) I am not aware of any equivalent for FBX.
  17. Thanks for the hint. It appears that I have to walk the tree of the referenced VWSymbolDefObj and check the visibility of each subobject there too. This seems to work. It is however very confusing - I would expect IsVisible() to return false if all the symbol(s) used by the object are invisible.
  18. I'm trying to determine whether or not to export an object. If the user has hidden the object, then the object should not be exported. As far as the user can tell, hiding the Lighting-LED class hides the object, but it still reports True to VWObject::IsVisible() - thus an apparently "hidden" object is being exported.
  19. Using Spotlight: If I add a "USITT_Followspot" and "Light Instr Robe Actor 3" to my drawing, the classes "Lighting-Followspot" and "Lighting-LED" get created. If I hide the "Lighting-LED" class, the Robe Actor 3 is hidden If I hide the "Lighting-Followspot" class, the USITT Followspot is hidden Yet, both of these objects are in the "None" class! When walking the document, how can I determine that the "Robe Actor 3" is in fact in the None class and the Lighting-LED class? I cannot find any reference to the "Lighting-XXX" class at all. The "VWSymbolDefObj" pointed to by the "Symbol Name" parameter is also in the "None" class. I've looked through all the named parameters of the object, and none of them mention "Lighting-Followspot" or "Lighting-LED".
  20. Thanks Moritz. I had expected "Truss" to export a definition for a procedural Truss object (so that MA 3D could auto-generate its efficient truss mesh) and not multiple highly-detailed meshes! I was very surprised to see that the Prolyte Box Corners are being built up of two 3DS files. Initially I thought this meant it did not work, as my MVR with two 'symbols' had two 3DS files! Permitting multiple "Geometry3D" children is a major difference between GDTF and MVR. GDTF does not allow any Geometry nodes to reference multiple 3D model files, and as MVR does not explicitly say otherwise, I expected MVR to be the same. Not only will this require very significant work to support, it also means that it will rarely be feasible to round-trip MVR files without changing (re-generating) the geometry files, as modern 3D applications are likely to convert a "symdef" into a single hierarchical object in order to properly use modern rendering techniques such as instancing. This further makes it impossible for applications to determine whether 3D models have actually changed, as the 3DS file(s) will always change. Secondly, what is the purpose of the Symbol "uuid" attribute? The github spec claims that it must be unique, yet in the attached MVR both instances of the Symbol have the same symdef and uuid values. The Symbol "uuid" appears to serve no purpose whatsoever. Unfortunately, the github MVR does not permit me to create issues, comments or PRs and does not appear to have any way to request access. That is very sad. prolyte_truss.mvr
  21. I'm currently implementing a GDTF "MVR" importer/exporter, and have run into a lack of test data. The official MVR wiki and github don't have any examples of the usage of "SymDef" and "Symbol" tags, and so far I have been able to use Vectorworks 2020 or 2021 to export an MVR that uses SymDef and Symbols. All the exports I've been able to make so far are creating individual Geometry3D and 3DS files for every object, even when they appear to be symbol references within VWX itself. Does VW2021 currently support "SymDef" and "Symbol", and if it does, how can I cause it to create an MVR file that re-uses Symbols?
  22. Exporting a model using textures that have some characters in the filename results in the filename becoming corrupted, so the textures cannot be found by any importers. For example, the attached MVR uses one of Vectorworks' default textures, filename "Siding Aluminum Double Dutch Lap Blue 5in <Surf Hatch> RT.png" In the 3DS files, the texture filename is given as "Siding Aluminum Double Dutch Lap Blue 5in <Surf Hatch> RT.png" In the MVR itself, the texture is "Siding Aluminum Double Dutch Lap Blue 5in %3CSurf Hatch%3E RT.png" Note that the angle brackets have been replaced by "%3C". It appears that the texture filename has been URI-encoded when saving it, but this change to the filename was not propagated to the 3DS file(s) that reference it. This inconsistency means that no MVR loader is able to find the texture, and the cones are left untextured. Additionally, the 3DS format itself is generally considered to only support DOS 8.3 filenames, so not all 3DS loaders are capable of loading this file. The same fault appears to occur in all Vectorworks 3D model exports that use separate texture and mesh files, such as 3DS, Collada, FBX (external textures) etc. Note that Collada and other formats have specific encoding rules for filenames (URIs). It does appear that the filename is being URI-encoded for Collada, but the encoded version is being used to save instead of the original. This means Collada importers decode the URI and cannot find the texture! Cones_Named.mvr
  23. In order to connect a debugger to a Release build under MSVC there are two important settings for building your plugin: C/C++ > General > "Debug Information Format: Program Database (/Zi)" (C7 compatible also works, but is larger) Linker > Debugging > "Generate Debug Info: Generate Debug Information (/DEBUG)" The "PDB" file this generates is your key to debugging, keep each version safe as you will need the correct one to debug each individual build. By default they'll be alongside your VW plugin, with the extension "PDB". (There is ident information inside each PDB so windbg and visual studio know which is right. Google MSVC Symbol Server for nice ways to store multiple versions) You do not need to disable optimisations, however doing so can make single-stepping more predictable - clearly you can't step into code that has been optimised away! However, any stack backtraces that enter Vectorworks code not covered by the PDBs in the SDK (eg walking your callstack backwards from a breakpoint or from crashes in the field) are likely to be very wrong as x64 stackwalking requires PDB information. (This wasn't true of MSVC x86 code) Vectorworks don't appear to have published PDBs for the main application, which is a shame. It would be nice if they would do so - though it would have to be a "stripped" version of course so as not to expose any of their private proprietary information.
  24. This function does not return nil on failure (VW2019 SP5.3), instead it seems to be returning the original object. Worse, I have not been able to find any documentation as to which object types are supported by the function. So far I have found that passing it a kLine2D returns the original object, thus the following snippet destroys the original drawing: MCObjectHandle tempPoly = gSDK->ConvertToPolygonN(h, (Boolean) true, 512); DoSomethingWithAPolygon"d(tempPoly); if (tempPoly) { gSDK->DeleteObjectNoNotify(tempPoly); } Fortunately this causes our plugin to crash, so our users have not lost data (yet)
×
×
  • Create New...