Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Richard1

  1. 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.
  2. 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.
  3. 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".
  4. 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
  5. 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?
  6. 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
  7. 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.
  8. 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)


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

  • Create New...