Matt Overton

Many times you let a render run in the background only to find an error (human mostly) that means some part of the scene hasn't worked properly. A texture hasn't taken the the way you thought it would, it's scales all out or to reflective. So you fix then re-render the viewport. The change you have made is a long way from where the viewport starts the rendering so it's going to be a while be before you see the result. It would be great if there was a way to direct the renders attention to the most relevant parts of the image first. Then just let it go on it's marry way. Say by hovering the cursor over the target location or setting hot spots by pressing a key over those locations.

Not sure why they just don't roll OzCad's tools in these to supplanted the stock tools. They seem to address most of the common issues that come up on forums. There was noise that was going to happen to the titleblock but in the end it didn't and again lots of the issues you see with titleblock are very much dealt with in VAA titleblocks.

No a related note... Has anyone found a good source of seated figures? I tried faking a receptionist once by just embedding them in the floor it really looks wrong.

Would say the better approach would be spread the features out over a series of service packs within the year. Give the testers space to concentrate on the working of each feature both in isolation and in the context of an active project. Testers have the same problem general customers do. Each release is a vast drop of new information that then needs to be digested worked out how it does work, how it works in context, what doesn't work is it a new bug,...., etc, etc. Would help isolate issues caused one feature on others. Might also help with the internal sales pitch if all the staff are reporting continual productive gains over the year.

If it's going to dockable with other palettes it still needs to be overhauled to fit more naturally with the size of the other palettes. Still, Yes, Object information Palette does get unwieldy for many objects and really could be better tuned to get the right information on screen at the right time.

I feel like 2019 will be a hard sell in the office, so expecting to be in same position. VW2018 worked out fairly well and stable and feeling in the office (and indeed talking to other local users) is longer term the development is concentrating on graphics and niceties not productive or workflow improvements.

Oldest palette in the program needs to be thrown out and restated to fit with the current interface. Better still combined with object info as above.

Maybe, Maybe Not. Given Metal can push 3 times as many draw calls than Vulkan. MoltenVK on Metal could be faster if it takes advantage of what makes Metal faster in the first place and possibly faster long term as the Metal team have skin in the game to deliver better performance long term. From the presentation Apple did note openGL isn't going away soon. We could all be using "Webtorworks" by then.

Maybe this could be part of the long wished for ability for VW to restart and only the back up file when it crashes. They could also use this to background saving and allow the app to become active again faster when there is great distance between machine and server by way of a copy on write system instead of a save system.

Although would be nicer if by snap grid distance firstly snapped on to the grid then by grid distance but that's an aside.

Like "Move Objects" in Preferences. You can flip key commands if you like.

So given the writing has been on the wall for a while for this change to low level API's. I'd assume from everything that has been said about it, that Vectorworks Graphic Module was developed to be a replacement to what parts of OpenGL Vectorworks relied on that weren't to be covered in newer API's. Including licensing GUI parts used in the App cross platform. So to me the issue is. Is VGM ready for OpenGL to disappear?

There seem to be a few interesting things at WWDC for VW so far. (like an open AR scene file format USDZ) I find it odd DirectX12 (3d), Metal and Vulkan have all come out of the same AMD Mantle project yet are vastly different. Although seems to be some moves by Vulkan team to find common ground. https://www.tomshardware.com/news/khronos-meta-api-vulkan-metal-directx12,33962.html Given VGM age I do wonder how much it was designed with Vulkan in mind and if runs Vulkan on Metal. Or if porting from DirectX to Metal will be easier given they have common ground.

Also interested if someone has found a solution all I've found is wishes for it work better. Like it would be good if we could nominate the default drawing layer (and Class) for each viewport.

off-topic: Love the Exasperated Architect shadow person.

Zoomer, Yes, the levels system is proving problematic on a number of fronts and seems to only really add value with (few) PIO's that can be bound to them. Walls styles haven't really worked well interacting with levels within a storey. Slabs and Roofs can't react to levels. Windoor doesn't work with levels anyway nor do most of the fitout PIO's. If we basically ignore levels the system works better generally. Including getting back to being no worse off than previous with Duplicate and Name layers for options.

Yes would add,... - Kitchen Design. Think every Kitchen company could have a web design tool like Ikea and the bigger flat pack companies do. - Real estate - With potential owners able to lease a copy of the file to test their own furniture in. Learning curve needs to simplified. Tutorials and more important better logic about how the system works. I can see the potential but I'd also say that about the traditional versions of VW and yet how much has really been delivered of the promise*. *After 20 years Grumpy middle-aged me would say this of a lot Tech.

Yes if doesn't have the means to draw new customers and new revenue then I'm not sure why it's being considered either. That said we have regular clients who use visio over the top our PDF base plans. I'm sure there would be money to had letting us share drawings directly with more tech savy clients.

I feel like there is a few similar wishes to this one that could be merged in to get the count up.

I have no problem with all these strategies they all work at different times. Still it’s not a single teachable system and that makes it a problem. Although must have another go at container classing as that is closet to how a versioning system would work. I think in past it came unusable with existing buildings demolishing different parts. Shame there isnt a way to push objects into an existing container assigned to group. After all at various way points in project you do want to clean out and freshen the file up for next stage of development. Given there is the resources to throw at VW in a web browser the. Versioning is definitely needed to stop that turning in to a right royal mess.

Given nothing in the Programme works until the User nominates a file to open (which could be a default or a double clicked document). The whole priority of the start-up should be getting to the point that selection is made and getting it on-screen and active. Everything else can wait and happen in natural lulls in activity in my mind. Like the Resource Browser if it's not visible on screen or only going to show document resources there is zero need for it to delay getting to a user active state.

Wall overall thickness setting should become Target thickness when the wall has components. Instead of current behaviour. Firstly it would help to set an expected overall then see how the build up differs. This would let us record and maintain a design assumption or a site measured thickness in the wall type then see if the component build-up was matching or might need tweaking. System should still report stats in the text beside the box without making the box inactive. ie "265mm Determined by Components (5mm below target)"

Given Design Development is a fundamental part of what we do as designers shouldn't it be easier and less error prone than that?

Has anyone found a good way to build options or test changes within a single BIM file? Seems the only way to do it is have a file per option. Which then leads to lots of copy pasting and updating symbols in one file and having to update. The biggest impediment I've found is Stories don't allow 2 layers of the same level type. So if a Duplicate a layer to make an option it forgets it's story association breaking all the story aware objects like walls. I can re-associate with the story but not it's level, this not only takes time to break all the object then more time fixing them. It seems like there should be a better way.

So if I take it in context the major work could be in overhauling how existing features work such that they could be marketed as new/improved. So a hypothetic new framed component type that made framing automatic, vastly improved sections and maybe even curtain walls faster wouldn’t be a new feature as the functionality exists but sure would be welcomed and could easily produce enough marketing videos to sell the upgrade in its own right. If that’s the sort of no new features we are taking I’m on board.