Anthony Esau
-
Posts
15 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by Anthony Esau
-
-
Hello!
Is it possible to attach a record to a custom plug-in object automatically as part of the script of the custom plug-in? And then assign values to the record fields?
I tried a combination of vs.GetCustomObjectInfo()[1] to get the handle to the custom plug-in object and then vs.SetRecord() to set the record to an existing record format, but it doesn't actually attach the record. A test file along with the .vso of the custom plug-in are attached. It creates a rectangle and then extrudes it based on dimensions provided by the custom plug-in parameters. And it should assign those dimensions to the record. But it doesn't even attach the record. The test is very simple to get up and running, but I do have a practical use case that is similar but with a little more to it.
Here is the script for the custom plug-in.
# inputs width = vs.Pwidth depth = vs.Pdepth height = vs.Pheight # define variables PIO_handle = vs.GetCustomObjectInfo()[1] direction = [1, 0] # for creating extrudes # Create the extrude bottom = 0 top = height origin = [-width / 2, -depth / 2] vs.BeginXtrd(bottom, top) prof = vs.RectangleN(origin[0], origin[1], direction[0], direction[1], width, depth) vs.EndXtrd() # Attach record and set Pedestal RF fields blockRecord = "Box RF" vs.SetRecord(PIO_handle, blockRecord) vs.SetRField(PIO_handle, blockRecord, "Width", width) vs.SetRField(PIO_handle, blockRecord, "Depth", depth) vs.SetRField(PIO_handle, blockRecord, "Height", height)
-
Not sure if it is remotely the same issue, but I have not had any luck getting a number of types of objects (3D polys, extrudes, or NURBS surfaces, 2d rectangles) to show up in graphic legends. For the source of my legend, the criteria is set to objects in a certain layer with a certain record attached. In the narrow scope of my testing, only symbols, custom plug-in objects, and tapered extrudes are included in the legend despite other types of objects meeting the criteria of being in the correct layer and having the record attached.
Unchecking the "Hide Empty Cells" option of the graphic legend does include cells for all the objects (3D polys et al), but it doesn't show the visual representation of the objects that were previously excluded. Trying various settings in the "Define Legend Image" portion of the graphic legend options did not help.
@Amanda McDermott perhaps this is contributing to the challenges you are having.
-
1
-
-
Quick update: I submitted this to tech support and received the response that "This issue has been escalated as a bug and is currently being investigated by our engineering team."
-
3
-
-
Continuing my monologue 😅
It looks like the issue arises from naming the String nodes with a prefix of a number and a space. In that last demo file, I named them "1 String," "2 String," "3 String," and "4 String." In the OIP, they all show up as "String" but are in sequential order.
If they are named "String1," "String2," "String3," and "String4" then the Marionette object style functions properly.
Unfortunately, in my attempts so far, the string inputs in the OIP for existing objects using the old style stick to the old String node names even when the Marionette object style is edited or even replaced. So there is a workaround for the broader bug, but not an efficient solution for my existing project.
-
Since my demo file is for a very specific use case and contains custom Marionette nodes, I put together a simpler example with all standard nodes to check if the problem was unique to that Marionette network or not. The attached file demonstrates that string input is broken when a style is created from a Marionette object. It uses only standard nodes.
-
I ask about workarounds in the last paragraph above, but ultimately a bug fix for Vectorworks would be a better solution. Can anyone else confirm if this is a bug? Or is there something that needs to be updated with the Marionette object to be compatible with the VW 2024?
-
Hello!
After updating to Vectorworks 2024 from the 2023 version, I am having an issue with a Marionette object style that I have used extensively previously. The purpose of it is to "clone" or duplicate the geometry of a symbol and then swap the textures. So it is essentially a symbol that has textures that can be changed per instance.
Now in VW 2024, the styled Marionette object no longer changes the textures. If I convert it to an unstyled Marionette object it works though!
However, if I convert each instance to unstyled, the settings of which textures to replace in the Object Info Palette also change. So I would have to manually change them back to the correct textures that are specified. If the OIP settings persisted, I would simply convert all the objects to unstyled for my current project and move on. While looking for solutions, I created a custom plug-in object that performs the same task as the Marionette object and functions properly in Vectorworks 2024, so I would transition to using that instead of Marionette objects.
A simplified demonstration file is attached. Is there a way to convert all the objects to unstyled and keep the OIP settings? Or can a Marionette object be replaced with a custom plug-in object (and transfer the OIP settings)? I'm not afraid of a little scripting if that might provide a solution but would have to weigh that complexity against brute force manually changing all objects.
-
Ah. Thanks for confirming that it isn't just me. Good to know that it's already on your radar.
-
Hello!
The texture selected in the Get Texture node changes from time to time without user input. I believe it is related to the creation, deletion, and renaming of other textures, but this issue does not always show up regularly. Sometimes the selected texture of one node will always change to the newest created texture while other Get Texture nodes will not be affected at all. Sometimes the selected texture arbitrarily changes to something seemingly random or perhaps to a texture whose name is alphabetically next to the one that I originally selected.
As you can imagine, this behavior is problematic when creating a wrapper or Marionette Object because the results shift from what is intended. And the fix is to go through and manually reset the selected texture in the Get Texture node, only for the texture to change arbitrarily in the future.
Has anyone else encountered this? Any fixes?
I have resorted to a modified Get Texture node that takes the name of the texture as a string input, but this is much less convenient.
My main use case is a Marionette Object with some custom nodes that recreates a specified symbol but replaces selected textures with other selected textures. So it is kind of like being able to create multiple instances of the same symbol but apply different finishes to them. I work as an exhibit designer and in my models I constantly need many physical structures that are the same except with different paint colors or different graphics / signage applied to them. So I set up a symbol with placeholder textures and then create multiple copies of it with the custom Marionette Object that replaces the textures of each instance. Randomly changing textures from the Get Texture node throw a big wrench in this setup.
-
A bit crude, but you can add the command "vs.EditTexture(hTexture)" to open the texture editor for each modified texture. The user will need to click through all of the boxes that pop up, but it forces a refresh of all the textures with the updated information.
In my job, I am constantly importing graphic layouts that were generated in Adobe Illustrator. So the scripts shared in this thread have been incredibly helpful. For my situation, individual sizing of the Renderworks textures can be automated by reading the metadata from the images to calculate what size the images were designed to be. This requires installing the Pillow Python library and adding "from PIL import Image" to the top of the script. Then the following lines are added to the main loop.
# Calculate the size (width) of the image with Image.open(imagePath) as pil_image: image_width_px = float(pil_image.size[0]) image_resolution_x = float(pil_image.info["dpi"][0]) image_size = round(image_width_px / image_resolution_x, 3)In my limited testing, Pillow doesn't read the dpi correctly from files created in Photoshop and I haven't tested images generated by other programs. Might need some additional tweaking to work more broadly.
For setting the texture size, "vs.SetTextureSize(hTexture, image_size)" has been working well for me.
-
1
-
-
And...I'm a little slow...but I now realize the "cp39" in that filename signifies Python version 3.9 which corresponds with the version that Vectorworks 2023 uses. I had been installing Pillow for Python 3.11 previously which resulted in the error (if I am finally understanding correctly).
-
Thank you for sharing SimA. I had to modify the command to "pip3 install Pillow" for it to run on my machine. And the results are listed below.
username@users-mbp ~ % pip3 install Pillow Defaulting to user installation because normal site-packages is not writeable Collecting Pillow Downloading Pillow-9.4.0-cp39-cp39-macosx_11_0_arm64.whl (3.0 MB) |████████████████████████████████| 3.0 MB 1.7 MB/s Installing collected packages: Pillow Successfully installed Pillow-9.4.0 WARNING: You are using pip version 21.2.4; however, version 23.0.1 is available. You should consider upgrading via the '/Applications/Xcode.app/Contents/Developer/usr/bin/python3 -m pip install --upgrade pip' command.However, Pillow still would not run in Vectorworks, even with some additional mucking around updating Pip and installing different versions of Python with Homebrew. (I had uninstalled several versions of Python previously for an unrelated reason and thought installing the latest version might help this situation.)
BUT what did work was once again using the Install Python Library feature of the Marionette Tool preferences with the link to the "Pillow-9.4.0-cp39-cp39-macosx_11_0_arm64.whl" file listed in the output above from https://pypi.org/project/Pillow. This file was different than the one I had installed previously. And now Pillow runs in Vectorworks! I believe this is the one thing that made it work rather than any of the other changes with Pip and Python.
Thanks for sending me in the right direction SimA!
-
I also have this issue on a MacBook Pro with an Apple M1 Pro chip. macOS 13.2.1. Vectorworks 2023 SP3 (Build 684728).
I installed using the Install Python Library feature of the Marionette Tool preferences. This is the URL for Pillow that I put in:
I also tried deleting the PIL directory shown in the error code above and installing some different versions from https://pypi.org/project/Pillow, but they didn't work either. Is there a proper way to uninstall a Python library from Vectorworks? Searching around the internet suggests that many times this error is resolved by updating to the latest version or re-installing Pillow, but these reference points aren't within the context of Vectorworks.
-
I too would like a way to show the fill colors of objects in hidden line renderings. So count my vote in favor of implementing something like this request for an Unshaded Polygon No Lines mode!
Attach record to custom plug-in object
in Python Scripting
Posted · Edited by Anthony Esau
Ah, I didn't read the documentation for GetCustomObjectInfo() closely enough and missed one of the returned values which threw off my numbering. Thank you for identifying the mistake, @JBenghiat!
Good point about accessing the object parameters rather than attaching a potentially redundant record. I have already been using the object parameters as dynamic text in a graphic legend, but I would like to do some calculations with the parameter values and make that information available to the legend. And I may attach different records based on the settings of the object. My documentation pipeline for this object is still being worked out, so we'll see if it plays out effectively. By the way, the PIO is a museum pedestal that can be made in a few different styles which affect the relative size of the vitrine (acrylic case) on top of it.
Here's a snippet of the actual work-in-progress PIO script (not the test from above) incorporating the other suggestions. Thanks so much for your input @JBenghiat. So far this is working in my limited testing.