kob

This is still not fixed in SP3. I can't imagine that I'm the only one who relies on Component Class Textures as a way to globally control and change textures on a 3D model. This is a huge issue for me, and must be for others as well. I will have to continue to use VW2018 for all projects until this is fixed. If anyone from VW is reading this, please have this addressed in SP4 so that I can finally use VW2019.

Still not fixed in SP3. This isn't a huge concern, but I just wanted to flag it as an issue. Hopefully it will be dealt with in SP4.

I like my Flyover Tool sensitivity fairly high, at 92. Whenever I restart VW2019 (which needs to happen about every 4 hours because the memory leak still hasn't been fixed) The Flyover Tool sensitivity seems to revert to a default level. When selecting the preference icon, the sensitivity still shows that it is set to 92, but the tool clearly does not act this way. By simply hitting the ok button to dismiss the dialogue box, the sensitivity is now restored to 92 and performs as expected. But, this wasn't an issue in 2018, and it's annoying that this extra step needs to be done at all.

Open GL is not updating component textures after a change has been made to the texture of a component class. I set up my model with walls to be rendered by components and I assign a class to all wall components and set them to be rendered by that class so that any wall that has Siding 1, for example, can quickly be changed across the entire model simply by changing the render texture of the class: Siding 1. 2019 is no longer updating the model to show the new texture. I can force the new texture to be rendered on the model by editing some element of each wall in question, or by editing the Renderworks Texture through the resource manager. This workaround is time consuming and frustrating. After two days of troubleshooting with test files including brand new files created solely for the purpose of attempting to isolate the issue, I've been able to determine the conditions that need to exist in order for the issue to appear: 1. The file needs to have a design layer viewport in it. In addition to all of the layers representing the various floors in my building, site plan, and 2D details layer, I also have a layer I call Layer Link which contains a design layer viewport showing all of the various layers for my actual building. I frequently use this Layer Link to preview my model as I'm designing, or to explain elements of the design to clients or builders. After deleting this design layer viewport, the problem is resolved. But, this Layer Link is fundamental to the way I work and has never presented a problem before 2019. Losing this functionality would be unacceptable. 2. The file needs to contain at least one design layer that has a different scale than the rest of the model. My site plan is usually at 1"=10', and my details layer is usually at 1 1/2"=1', whereas my actual model is usually at 1/4"=1'. Oddly, after deleting these other layers so that all layers are the same scale, the issue still persists. 3. The issue only presents itself in Open GL. When rendering in Fast Renderworks, the texture updates on the model once a change has been made to the component class. Working even in Fast Renderworks is unacceptably slow. Open GL is the only render mode that is fast enough to work in while allowing me to visualize textures, so working in other modes isn't acceptable. Hopefully this issue can be addressed in the next Service Pack. Until then, I'll have to go back to using 2018.

I just experienced the same problem. The "save as" route solved the problem. But the font in question is Century Gothic. FontBook says that it's a True Type font, though. Has anyone else figured out a solution rather than a workaround?

I'm having a similar issue. Textures in Open GL are mapping differently that in Final Render. Here it is in Open GL And here it is in Final Render The final result is correct, but it would be nice to have it all line up while I'm modelling in Open GL. In case it's not obvious, it's the black vertical siding texture that I'm having an issue with. In case it's relevant, the texture is custom created by me, made from a seamless image that is the exact same height and width.

I'm just trying out VW 2019 and disappointed to see that selecting windows and doors remains unbearably slow. When clicking on a window or a door, it is often 3 full seconds before the OIP displays its information or I'm able to do anything with the door or window object. Considering the fact that I may need to select and modify or otherwise work with a door or window object several hundred times during a work day, the lag is incredibly frustrating. This problem didn't seem to exist a few versions ago, but has since about 2016. Hopefully this can be resolved in the first Service Pack.

I've just noticed this happening with VW 2018. I found this thread, and indeed, quitting Safari cleared it up. I thought I'd mention it here in case anyone else was experiencing the same thing.

Looks like SP2 fixed this. Thanks!

Thanks zoomer I'm glad to hear I'm not the only one noticing this. I should maybe clarify. This was working all the way up to 2017, but is just now becoming an issue with 2018. I do, in fact, specify window heights relative to finished floor. I use the Elevation field on the OIP (below Width and Height) to specify Sill Height Above Finished Floor, and this value gets reported to a window schedule. But the Height field at the top of the OIP is usually 0". (It's sometimes something like -36" when the window is at a stair landing. This way, my window schedule reports Sill Height in relation to the Landing Height and not the Finished Floor of the Story.). My Stories usually have two Level Types: Top of Slab = 0". Bottom of Slab = -4 or -9 or -11 etc. My Exterior walls have a Bottom Bound = Bottom of Slab and a Top Bound = Bottom of Slab, Story Above. My interior walls have a Bottom Bound = Top of Slab and a Top Bound = Bottom of Slab, Story Above. When I take a window with a Z height of 0" and insert it into a wall, I want it to keep the Z height of 0" and not automatically change it to whatever my Bottom Bound is set to. Perhaps my approach to the software is different from most other people? I'd love to know if this was something that was consciously "fixed" or if it's just a bug. Is anyone else experiencing the same thing? Here's a screenshot. This is a Basement Window. The Slab here is 4" thick, so my Story is set up to have a Bottom of Slab = -4", and a Top of Slab = 0". The window has a sill height of 5'-3", but a Z height of 0". If I duplicate this window and drag it to another wall, the Z height will automatically change to -4", and I will have to remember to go change it back to 0".

I'm not sure what has changed with 2018, or if maybe there is a setting that I have changed. Previously I would insert a window with a Z height of 0 into a wall, and the Z height would remain 0, regardless of where the bottom of the wall was in relation to the Story. Now, the window object is changing the Z height to be the bottom of the wall. Since the bottom of my exterior walls are usually set to a Story Level called 'Bottom of Slab' which changes depending on the slab thickness, the windows now show a Z height of -9" or -11" or -13.5", or whatever. Even if I go back into the Object Info Pallette and change the Z back to 0, If I duplicate that window and insert it into another location, the Z height of the new window will automatically adopt a Z height equal to the bottom of whatever wall it gets inserted into. Is there something I'm doing wrong, or is this a bug?

I'm trying to create a solar animation, but layer plane objects are displaying in the .mov file. I do all of my rendering from Viewports (where there is an option on the OIP to prevent planar objects from appearing), but it seems that one needs to be able to select a heliodon in order to create a solar animation (which I can't seem to do when looking at a viewport), so I'm assuming that I need to work from a saved view in order to be able to select a heliodon and create the animation. This is my first try at using saved views or rendering anything other than a viewport, so perhaps this is where I'm messing things up. The project is a 3 storey house, so there are 5 layers turned on (basement, ground, second, third, roof). Unified view is on so that they all appear correctly. Under Unified view options I have deselected Display Screen Objects. When I render my saved view as a static Custom Renderworks image, everything looks as it should, with no planar objects displaying. However, when I export the solar animation, planar objects are now showing up. They appear as solid lines rather than dotted lines as they do on the design layers (in case that's relevant). There are lines for the property lines, dotted lines that represent eave overhangs when in plan view. circles that represent tree trunks in plan view. Etc. Here's a copy of the mov file. I've just exported 5 frames. On a completely different topic, I wish I the Physical Sky Background had an adjustable horizon. I want the sky to change colour throughout the animation, so I have to use the Physical Sky Background, but there remains a gap between the edge of my site and the horizon. I've tried extending the site, but it still never seems to close that gap. Thanks, and hoping someone has a fix for those planar objects that don't belong. Animation 4.mov

Has there been a fix to this issue? I have experienced the same thing ever since upgrading to VW2017. I used to think it was because I was running an external monitor with a Macbook Pro. However, I've since upgraded to a Mac Pro, and the issue still persists. Vectorworks 2017 was installed as a fresh install on the new machine, so there shouldn't be any issues with importing an old workspace. When I open the application, the window only covers the left 4/5 of the screen. I option-click the green button in order to maximize the window and all is fine. Not a huge issue at all, but if there's a fix, I'd love to know.