Jump to content

Jesse Cogswell

Member
  • Posts

    240
  • Joined

  • Last visited

Everything posted by Jesse Cogswell

  1. I've had some success with placing symbols into an ordered list from bottom to top, then exploding the list back into a group. It's kind of messy, but it's the only thing that I have found to consistently work.
  2. @mjm My understanding of Bruce's issue is that while you can do this (or use the fancy new Align Working Plane to Current View button in a 3D view before placing the worksheet), it would only every work for that view, versus having it on the screen plane and always facing the camera while you orbit around the drawing. Personally, I would just have the worksheet open in its edit view and would only place it either directly on a sheet layer, or within an annotation of a viewport, both of which can ONLY be on the screen plane, so there's no need to have a way to toggle it.
  3. While the "Show Other: 3D" does work, one of the tricks I use to quickly build 2D components is to use the Extract Face tool set to Create Planar Object. Then, I can orbit around the model and select faces I want, then just toggle them to the screen plane when I'm done. I do have to manually trace faces that wouldn't be flat to the screen plane, but even that is easy to do in a 3D view with the working plane set to the ground. And my experience with trying to cut and paste in place from one component to the other does not always correctly place things, at least with extracted faces. It's a personal workflow choice for me, but it currently necessitates using the screen plane. I would love to see an option to set planar objects in a 3D component to the 2D component (like screen plane does) before the screen plane is entirely deprecated.
  4. The only reason that I miss the Screen Plane is due to how Vectorworks thinks about hybrid symbols. When creating a symbol, VW automatically separates 3D objects from planar objects into their respective symbol components, but when editing the symbol later, it uses the screen plane to separate objects back to the 2D component. As an example, let's say that I am given a drawing with a bunch of 3D symbols in it and I want to make them into hybrids. In earlier versions of VW, I might edit the 3D component of a symbol and trace it with 2D rectangles, circles, or polylines. When I was done, I could select those shapes and set them to the screen plane in the OIP. Upon exiting the symbol, VW would recognize those screen plane objects and convert the symbol into a 2D/3D hybrid. This does not happen in VW2022, the only plane you have access to in the OIP is the Layer Definition. I mean, in this case you could just enable the 2D Legacy Features, move the objects, then disable the 2D Legacy Features but I think it would be better if, when editing symbols, you had a plane option of "2D Component" or something so that you could send flat planar objects to the 2D component while editing the 3D component.
  5. So far I've seen Redshift take much longer than Custom Renderworks at medium settings with everything except Renderworks Backgrounds with lit fog, which Redshift seems to really excel at. Below are a couple of quick renders from an old project. The images on the left are both Custom Renderworks, all settings at medium and an ambient light level of 15% and indirect light set to Exterior 3 Bounces, the top with a background with lit fog and the bottom without. As you can see, it took a long time to complete. The two images on the right are Redshift with an ambient light level of 25% (Redshift seems to produce darker images). Those took no time at all, but most of the gobo texture did not come through. I played around with this file quite a bit to try to get the same level of texture detail from my other tests above, but could not find the magic recipe to get sharpish texture. What's also a bit weird with Redshift is that, while rendering, I have not seen Vectorworks utilize more than 5% of the GPU.
  6. @zoomer Good call on refraction vs. reflection. You were spot on, setting the refraction to 1 fixed the issue. I futzed around with changing value but even at 1.01 you start seeing distortions that are unrealistic. Viewport Redshift rendering with Refraction set to 1.0 Redshift with refraction set to 1.01, you can see the distortion around the edges of the vitrine. So is this a bug with how Redshift handles refraction in that it just overdoes it? It's interesting to me that we still get the sense of refraction from Redshift even with refraction set to 1.0, so it makes me wonder if some of it is applied by default. I tried raising the refraction in Renderworks to see the level of distortion in Redshift, but couldn't get anything other than realistic (if not exaggerated) refraction. Custom Renderworks with refraction set to 2.0 @JBenghiat Your comment made me start wondering about the tests that I had done thus far, that maybe the reason I was seeing gobo textures in redshift was that Render Bitmap wasn't using the full Redshift engine, so I rendered the gobo projector out with sheet layer viewports instead. Interestingly, I still get the gobo texture, just not quite dead sharp. There's also something weird happening with the refraction, as if it is refracting the beam without the gobo texture. Example: Custom Renderworks on the left with refraction set to 1.5, Redshift on right with refraction set to 1.0. I wondered if Redshift was having an issue rendering gobo textures on different planes, so I set up a couple of different shapes to light, and it did all right with everything except the sphere, which produced a weird anomaly. Example: Renderworks on left, Redshift on right.
  7. I've been playing around with Redshift quite a bit since the VW2022 release, but at the moment I don't see it replacing Renderworks for me. I've seen a lot of inconsistency in its output depending on whether you're rendering in a viewport, using the Render Bitmap tool, or just setting your design layer render mode to a Redshift style. I do a lot of museum exhibit lighting and have been using Renderworks to produce near photo-realistic renderings. This can take a long time since Renderworks does not use the GPU to do the processing, so I was looking forward to Redshift to speed up the process. I'll detail my current issues with it and provide examples below. My biggest holdup is that Redshift does not recognize any light source set with Use Emitter. This is a huge bummer in that it lets me light a scene using Spotlight Lighting Devices, but render them realistically without too much fuss. To use Redshift, I would have to use the IES files for the fixtures, which requires using a script to "extract" the Light object inside the Lighting Device since Lighting Devices can't use Custom light types. Example: Custom Renderworks on the left, Redshift on the right. Light source is an ETC Source 4 19 degree. Images from Render Bitmap Tool. The next issue I have is with how Redshift seems to render glass textures. Reflections seem to "cascade" and get repeated over and over, which can make vitrine cases hard to render. Example 1: Same as above but with color in the light to show reflections a bit better. Custom Renderworks on left, Redshift on right. Object is a 1/4" thick shelled solid with default Glass Clear RT texture applied. Example 2: Sheet layer viewports with vitrine case, Custom Renderworks on left, Redshift on right. Vitrine is 1/4" thick shelled solid. Lit with just ambient light, no external source. Here's a bit of the inconsistency I was talking about. The image below is the same case with the same Redshift style, but rendered directly on the design layer with the Render Bitmap tool, notice that the reflections are much more similar to the Renderworks view. Example 3: Another vitrine case. Redshift almost makes it look like the vitrine is full of water. Example 4: Excerpt of a sheet layer viewport rendering with Redshift style. Notice that all of the case sides have mirror-strength reflections. Now, more on topic with this thread, I did play around with gobo textures and was able to get them to ALMOST work. I could not get a gobo to read as sharp, but I was able to get some texture out of it. Example: Gobo in ETC Source 4 19 degree. Custom Renderworks on left, Redshift on right. Render Bitmap Tool images. What's curious is that after I shelled the solid and rendered another bitmap with Redshift, the gobo came out pretty sharp. But I have no idea how it happened, I was not able to get another bitmap with a sharp gobo with Redshift. In terms of lighting, I am excited about how well Redshift renders lights using IES files (though I remember seeing another thread where the quality was inconsistent, I need to do some further testing). Example: Light with IES file from ETC Source 4 19 degree at 25% intensity. Custom Renderworks on left, Redshift on right. Renderworks tends to "blow out" with both IES custom sources as well as emitter based sources, so Redshift is showing a much more realistic intensity, just with the weird reflections. The IES file also has some weird artifacts on the outside, but they don't appear in the Redshift render. Final issue isn't based on Redshift directly, but is a bug that has been around since the Clip Cube was introduced. The issue is that the textures for anything that isn't an extrude or sweep get distorted in rendered views when the Clip Cube is engaged. Example: This is the shelled solid with the gobo texture light on. With the Clip Cube, the gobo doesn't render and the glass texture is completely distorted. Renderworks on left, Redshift on right.
  8. I'm going to be honest here, I am not a huge fan of Marionette. I find it clunky and slow and far less powerful than writing scripts. The only advantage it has over scripting is the ability to have a Plug-in Object exist entirely within a drawing, allowing users to have custom parametric objects without having to share and install plug-ins. That being said, it is much more approachable than scripting if you don't have coding experience. I played around with replicating my script using just vanilla Marionette nodes and was able to get it pretty close. The only thing I wasn't able to solve is that it groups all of the 3D Locus points together, and I was not able to find a way to ungroup them without manually doing it after running the script. The Marionette you started above can be simplified. There's no need to mess with the List or Set Select nodes as the Objs by Crit node will automatically produce a list of all objects meeting the criteria. From there, you need a Delete node to delete the source 2D Locus Points, and a Get Location to pull the X and Y coordinates as a Point 2D. The Locus node will build either a 2D Locus Point or a 3D Locus Point depending on what kind of point is given as an input, so you can use a Get XY node to pull apart the data from the Get Location node, adding an additional Real input node with a Point 3D node to get the requisite 3D point to force the Locus node to generate a 3D Locus Point. A Get Class and Set Class node will match the class of the source Locus Point. Now, this will convert EVERY 2D locus point in the drawing that is not embedded in a symbol or plug-in object to be converted to a 3D locus point, and all on the active layer. So if you want to fully replicate my script from up above (and only convert selected 2D Locus Points), you have to wrap the network and convert it to a menu command, since selecting the network or the wrapper will deselect the Locus Points. There are a couple of issues, as the whole network has to be run as part of creating the wrapper, and you will get an error with the Get Location node for having an empty list on the input. So you'll need to add a Valve node to execute the network only if the list is not empty. My test document is attached (in VW2021 format). Convert 2D Locus Marionette.vwx
  9. Ah, missed a parenthesis around SEL=TRUE in the ForEachObject criteria. That's what I get for testing it with a file of only locus points. Fixed code below. I also added a check so that it will only work on selected locus points on the active layer, so you won't accidentally convert locus points selected on a non-visible layer, or a visible layer with Layer Options set to Show/Snap Others. PROCEDURE Convert2DLocusTo3D; {* Converts selected 2D Locus Points to 3D Locus Points at given Z height Developed By: Jesse Cogswell VW Version: 2019 Date: 9/2/2021 *} VAR height:REAL; locusCount:INTEGER; heightStr,currentLayer:STRING; PROCEDURE ConvertLocus(h:HANDLE); {Pulls location and class data of given 2D Locus Point and replaces it with a 3D Locus Point} VAR A:POINT3D; class:STRING; BEGIN locusCount:=locusCount+1; GetLocPt(h,A.x,A.y); A.z:=height; class:=GetClass(h); Locus3D(A.x,A.y,A.z); SetClass(LNewObj,class); DelObject(h); END; BEGIN locusCount:=0; heightStr:=StrDialog('Enter Z Height','0'); currentLayer:=GetLName(ActLayer); IF(ValidNumStr(heightStr,height)=TRUE) THEN BEGIN ForEachObject(ConvertLocus,((SEL=TRUE) & (T=LOCUS) & (L=currentLayer))); IF(locusCount=0) THEN AlertInform('No 2D Locus Points Selected','',FALSE); END ELSE AlertInform('Please Enter a Valid Height','',FALSE); END; Run(Convert2DLocusTo3D);
  10. @the frog Wrote up a quick script for you in Vectorscript. It brings up a dialog asking for a Z Height, then replaces selected 2D Locus Points with 3D Locus Points at the given height. Let me know if you have any questions about getting this script into Vectorworks as either an instance in a script palette (per drawing) or permanently into your workspace. PROCEDURE Convert2DLocusTo3D; {* Converts selected 2D Locus Points to 3D Locus Points at given Z height Developed By: Jesse Cogswell VW Version: 2019 Date: 9/2/2021 *} VAR height:REAL; locusCount:INTEGER; heightStr:STRING; PROCEDURE ConvertLocus(h:HANDLE); {Pulls location and class data of given 2D Locus and replaces it with a 3D Locus Point} VAR A:POINT3D; class:STRING; BEGIN locusCount:=locusCount+1; GetLocPt(h,A.x,A.y); A.z:=height; class:=GetClass(h); Locus3D(A.x,A.y,A.z); SetClass(LNewObj,class); DelObject(h); END; BEGIN locusCount:=0; heightStr:=StrDialog('Enter Z Height','0'); IF(ValidNumStr(heightStr,height)=TRUE) THEN BEGIN ForEachObject(ConvertLocus,(SEL=TRUE & (T=LOCUS))); IF(locusCount=0) THEN AlertInform('No 2D Locus Points Selected','',FALSE); END ELSE AlertInform('Please Enter a Valid Height','',FALSE); END; Run(Convert2DLocusTo3D);
  11. @mlachenal You can get this script into your menu bar following the steps below: Open up the script editor that you wrote this in. Select everything and copy it. Go to Tools - Plug-ins - Plug-in Manager. Click on the Custom Plug-ins tab. Click New. Select Command and give your command a name. With the new plug-in selected, click on the Edit Script button. Paste in your code, make sure the Language is set to Python, and click OK. Close the Plug-in Manager window. Go to Tools - Workspaces - Edit Current Workspace. Click on the Menus tab. In the box on the left, navigate down to the Miscellaneous category and expand it, your new command should be there. In the box on the right, find a place for your script to appear. Click and drag the plug-in from the box on the left into the box on the right. Click OK. I should also note that the category that the plug-in appears with in the Workspace Editor is "Miscellaneous" by default but can be changed from the Plug-in Manager window by clicking the Edit Definition button and selecting a different category or creating your own.
  12. Vectorworks uses something of a global naming scheme. Symbols, classes, viewports, lighting positions, anything that can be named all share the same pool. What I'm guessing is happening is that you have a symbol named "Circle" as one of your label legend containers. If so, you can rename it to "Circle Symbol", which will open up Circle as a possible name for your position. It can get really frustrating in Vectorworks to track down naming conflicts, as the conflict might not exist on the drawing itself, being a class name or a symbol definition, so even running a Tools - Selection - Custom Selection with the criteria set to look for any Object whose Name equals Circle might not turn anything up. I've gotten very strict with my naming within my own drawings, anytime I make a symbol, I make sure to include "Symbol" at the end when I name it.
  13. @Benson Shaw Here's a link to the script that I wrote to connect either 2D or 3D locus points to create a polygon.
  14. Vectorworks can absolutely count nested symbols. If you are doing it inside a worksheet, you just want to make sure that you have INSYMBOL as part of the criteria (or INOBJECT if you want to count inside plug-in objects). Attached is a screenshot that I set up for a quick test which shows the formula in the worksheet. Likewise, running Tools - Custom Selection also gives the proper results when Include Components of Symbols is checked.
  15. One solution that you might consider using for your symbol is to set it to have size be page based rather than world based. To do this, I would recommend creating your symbol directly on a sheet layer to determine best sizing. Then in the Create Symbol dialog, select Page-based under the units section. This will create a "green" symbol and will always appear to be the same size when printed regardless of scale. This holds true whether the symbol is inserted in a design layer or as part of a viewport annotation.
  16. I've been seeing this fairly often in VW2021. At this point I just ignore it.
  17. I downloaded the file and took a look at it. The thing that I am seeing is that any 3D Locus point has its "legs" extended way outside the space. Every one of your chair objects has a 3D Locus at its center, so it becomes a mess. Just look at this isometric view in wireframe: The issue is that the ends of those locus points basically extend out into infinity, technically putting geometry too far away from your Internal Origin, which causes all of the anomalies that you are seeing. While you can remove the 3D locus points from your chair symbols, there are some baked in to the Truss objects, so I don't think you will be able to get rid of them completely. This is a similar issue to this post here: But the fix that @Pat Stanford wrote for that one doesn't seem to fix this issue. I went through all of the Vectorworks preferences in the application itself (Document Settings, Spotlight Settings, Vectorworks Preferences) as well as the scripting side and could not find a preference that I could toggle to get this fixed. Even setting #D locus points to never being visible still causes the graphical issues of having objects too far away from the Internal Origin. So, I don't know how to help you. But I am indeed seeing the same issues that you are in your file. I also tried backsaving to 2019, but it didn't resolve the issue. If I removed all of the objects with 3D locus points from the drawing, the 3D flyover would behave properly, and newly placed 3D locus points would likewise behave properly. I could also place the Event Chair 1 without having the huge locus points. I know it's at the expense of time, but try deleting the seating, the trusses, and the LED screen and rebuilding them.
  18. I just ran a test going from both Vectorworks 2019 and 2021 to Vision 2021 and had no problem getting focus to come across as long as the Focus Point objects were listed and checked in the Object Types box of the Export MVR File dialog box. Also make sure that your Vision is completely up to date, I remember there recently being a bug where this functionality was broken, but as of version 26.0.4, it appears to work correctly. My bigger problem with the MVR export is that color and gobo data doesn't come across in the export. I have found that it's best to split my Vectorworks export into pieces. Scenery and theater architecture as MVR for the better normal and texture mapping (though I've occasionally run into an issue where texture names overlap, since the MVR export seems to rename textures to "Textr#" without regard to file) Movers as MVR export for easier data reconciliation Conventionals as ESC export to retain focus, color, and gobo information I tend to like having more granular control of by Scene Graph, so having multiple layers from the exports is actually welcome. And it prevents me from having to use Vision's awful color picker. Seriously, can we please get a text field where we can type in something like "R26" rather than having to scroll down to Roscolux, expand it, then scroll down to the color to select it? It's a huge drag in a large plot using multiple color manufacturers. All the more or a bummer that we already have to enter the color and gobo information twice (once in the OIP and once in the Edit dialog) for it to even come through in the ESC export.
  19. Keep in mind that I only have experience with MVR and Vision, but what works for Vision might also work for Capture and Depence2. The trick with getting focus information in to Vision is to add Focus Point objects in as part of the MVR export. Either make sure they are selected (if your MVR settings are set to selected objects), or visible (if your MVR settings are set to visible objects) before your run the Export MVR command. They will get their own category in the MVR export window.
  20. Open up Vectorworks Preferences. Click on the Session tab and click on the Reset Saved Settings button. Keep in mind that this will reset ALL of instances where you clicked "Do not show me this again."
  21. Vectorworks very rarely completely remove tools, they just remove them from the default workspace. If you go to Tools - Workspaces - Edit Current Workspace, you will be able to find the old Hoist tools under the "Legacy" category for both menu commands and tools. As a warning, they will be mixed in with all of the other legacy tools, but there are still some gems in there.
  22. Sorry, I'm super busy this week but will try to look at it if I get some time in the evenings.
  23. I've had some issues with VW2021 showing only "No Selection" in the OIP when I first open a drawing, but it rights itself if I change my active layer. So when it happens, I just do the Ctrl+up and Ctrl+down and continue with the drawing. I have not run into this yet in SP4, however, so maybe that particular issue has been fixed.
  24. @Shengxi Wu The bug pops up when you have your attributes set to "By Class." Going into the Edit Texture dialog causes the Fill Type, Fill Color, and Pen Color attributes to reset to no longer be by class, reverting to the last manual values set in the attributes pane. If feels like random colors if you draft with attributes set By Class, as I do 99% of the time. I've attached a video of this in both Vectorworks 2019 and 2021, but this has been happening for as long as I can remember. 2021-08-02 10-31-23.mp4
  25. It's been this way for as long as I can remember. I daily drive VW2019 and it happens literally every time I open up the Edit Texture dialog. It does the same thing in 2021. I've gotten used to resetting all my attributes by class every time I deal with a texture.
×
×
  • Create New...