PVA - Admin

A good practice perhaps but it's not the way we want to work in the long run. We want to progress to the latest version of VW when it comes out and move everything forward with it. And we want Nemetschek to expect us to work this way. ^This. Any example files where this or other anomalous behavior occurs after updating to 2014 or SP1, please send to Tech@vectorworks.net with a brief explanation and a link to this thread. I am still trying to nail the issues down and this would be a great help.

Doing my best, I hope to see the results of all these wishlist requests soon. The point where I'll start to see the fruits of the recently restarted forum collaboration still a bit away in the production cycle, but within a few months it should get interesting. I can't openly speak about development specifics until they're given the green light, but I'll share everything I can.

Wishlist request submitted. (Specifically for U3D as an export format.)

Many additional optimizations are needed in Vectorworks itself before we can take full advantage of C4Ds speed. Often the rendering engine is sitting and waiting idle for Vectorworks to process geometry and pass it along. The current C4D engine used by Vectorworks 2014 is R14. As for the mode, I am not sure. When I asked, the answer was something to the effect of "there isn't a simple answer to that question" so most likely a combination of both depending upon context. On Windows it comes with 32bit and 64bit, the engine itself detects which should be used on the system it is running on and launches the correct version accordingly. On OS X I believe it forces 64 bit now since Macs are almost completely 64 bit across the board.

For the first iteration of it i think I'll keep a simple viewport update and a complex geometry calculation as the two sample operation tests. (Mostly because that keeps it simpler and at the moment this is still only a side project for me.) Im thinking later on a "Designer Features" file that includes a site model update, an auto-hybrid regeneration, a roof creation, etc with times for each. (The only reason I disagree with the selection highlighting test is for technical reasons in-house, it can change its behavior based on a few things unrelated to hardware power at the moment that would skew benching results randomly. Once thats sorted I would completely agree that it is an excellent metric.)

So far I know of nothing that lets them note and return the model other than simple images/PDFs. The Vectorworks viewer will let them view the files fully now (they added Unified View to the viewer at long last) but I am fairly certain they would not be able to save. I know this role is the direction Nomad is headed in, but not how long until it gets there.

Im going to be listing the computers make/model along with the CPU as well in my results, since the large majority of users do not assemble their own custom rigs. Along with this however, yes, I think a test file is in order, at minimum a document with a viewport along with the time it took the listed machines to render them. There are other operations that I could include as well, just need to devise a simple method so that all users can execute the same tests in the same way. Updating a viewport is relatively easy, I may have a duplicate array test of some kind as well to test the general geometry/mathematical operation speed, if I can come up with something reliable and repeatable.

Excellent! This is exactly what I am already working on here with all of the hardware available to me.

If you didn't want to model the boards themselves, then I think the only way to get depth from the texture would be to apply either a bump or displacement map within the texture itself: The marketing video explaining it briefly is here: I am not sure if we have any training materials specifically covering it yet, I'll keep an eye out.

I have two other users that are actively experiencing this, but I can not get it to occur here in house at all. Still trying though, the only thing that seems similar is that the files came from older versions, however with both of the users i've been working with even a full layer import into a fresh 2014 document experience the same problem that I am unable to replicate.

The problem I see with this is that you would have to fully install Vectorworks on the machine in order to benchmark it in this manner. So you couldn't simply go around benching multiple machines, since you would rapidly run into the max activations limit installing Vectorworks on so many machines. That system would work great for judging machines that already had Vectorworks on them, but would not be so useful for testing prospective new computers. I was attempting to devise a procedure that would allow a user to drop a small utility or two onto a machine and test it, without the entire process of installing Vectorworks itself.

Isn't Renderworks good old Intel CPU based rendering, albeit multithreaded, so graphics card isn't doing much other than displaying the rendered pixels? OpenGL there will be a difference, but that isn't Renderworks. That's my understanding. Correct, video cards will currently only process the OpenGL rendering mode and a bit of wireframe/hidden line. The video card will not currently affect any of the full Renderworks rendering modes.

We do not yet have support for OpenCL.

U I O P [ and ] will control tabbing through the various sets of modes for the tools that have them. "U" for the first set of modes, "I" for the second set, etc.

For any users that were interested in the benchmarking topic: I just benched my own machines again with R11 and R15 of Cinebench. The OpenGL metric seems to have stayed very similar, I got an OpenGL score of 36 in r11 and 38 in r15. However the CPU scores were very different and marked with a new type of unit. r11 scored my iMac at 3.92 "pts" while r15 used a new metric and scored the same machine 344 "cb" So it appears they have indeed changed how they rate CPUs.

Are you unable to simply select all the object and then change them to the desired layer via the Object Info palette? Or is it that they are all in the same class as well, and you want them separated by class, not layer?

You could set the viewports up on sheet layers or saved views and then use Publish to produce a batch of PDFs, but unfortunately Publish doesn't include PSD format as an export option. Definitely something for the wishlist.

The later versions have greater hardware requirements, yes. A Machine that ran 2008 without issue may no longer be able to keep up with software created 6 years later.

Sorry for the delay in response, we have only recently finished our testing of hardware setups like that in tech support.

You can contact Sales here to see about options: http://www.vectorworks.net/sales/

That is specifically to fix the quicklook component of OS X. You do not need to run it, it simply resides in the designated location.

A few videos on the subject: http://kbase.vectorworks.net/questions/461/Design+Layer+Viewports http://kbase.vectorworks.net/questions/571/Design+Layer+Viewports+2

Vectorworks specifically can only take advantage of one graphics card at a time, the dual graphics in the Mac pro would benefit the user only in extra monitor support, as well as leaving one graphics card free for other applications and the OS GUI itself. I don't know whether they will be running the cards as two discrete devices or if they will be SLI/CrossFire linked, but at the moment, Vectorworks can only use a single graphics device.

You should be able to find this under Tools > Options > Vectorworks Preferences > Interactive > Interactive Appearance Settings Two of the color items should be "General - Background - Perspective...", which should let you change the colors individually.

That it would be economically unviable to support more than the previous two versions, most likely. I cant speak to the specific numbers (though I have never figured out how the Nemetschek user base numbers work, that headcount doesn't make sense to me either...) but I do know that charging users that keep up to date extra to support software for users that do not upgrade regularly would be unfair. The idea of users paying to keep their older versions patched definitely has merit, but not something there is any sort of support system for here currently. ^ Completely agree with this. The conversion issues in files/workspaces/preferences are the main factors holding a regular and consistent upgrade path back.