Jump to content

VW2013 teaser...is this the best you've got...?

Recommended Posts

Hands down the best feature is the background rendering. That could double my productivity. I will miss the forced breaks, but when a deadline is approaching I will never again have to choose between working on my elevation or rendering.

I hope this will use multi core on mac so that it does not slow down performance of VW while there are renders processing in the background.

I hope they make it so that you can control the red out of date VP visibility. If not as soon as you edit an item in the model all VP will be out of date as soon as they are finished rendering.

Link to comment
  • Replies 261
  • Created
  • Last Reply

Top Posters In This Topic

I hope they make it so that you can control the red out of date VP visibility. If not as soon as you edit an item in the model all VP will be out of date as soon as they are finished rendering.

I was thinking about that. Since you currently can not export or print viewports that are out of date, this would only save time if you can jump to a different file to do your work. I am assuming they have thought of this. Even if they didn't big time savings.

Link to comment

The biggest advantage appears to be the time savings...faster panning while in render mode, generate renderings while continuing to work, crunch building sections from the cloud (according to the Keynote), etc. Having just upgraded from 4gb to 12gb things will seem like light speed.

Biggest disappointment is the lack of Roof Components. Eliminating the 'too complex' error is a nice step, however.

Biggest 'almost but just missed' feature in my eyes is the Detail Viewport. Why no ability to add breaklines to the detail viewport so a single wall section viewport can be broken into enlarged stacked display segments with breaks? Instead we need to create new detail viewports each with unique tags for each joint in a single wall section. I'm guessing time will be needed developing that work around.

Other specific features look promising. I've learned to withhold too much praise until they are put through their paces, however.


Link to comment

I'm testing several files, just to compare if the new release is faster like described, but I have to witness VW2012 being faster???

Turning the Enhanced Navigation Graphics off makes it the same speed. The anly thing I notice when on is that it's more 'beautiful'.

So what I thought to be one of the big things is just a beautifier? I really would like to know if other experience the same thing?

Edited by DWorks
Link to comment

yeah, in the presentations and brochures they were conspicuously silent on the issue of multi-core and 64 bit stuff...i'm not an engineer, and don't fully understand it myself...but the core architecture of the software i would say. so, i asked tech support how 2013 is advancing in this sense. their answer: it doesn't. apparently we're still in the dark ages for at least another year. as far as i can gather, speed improvements are largely superficial.

Link to comment

The specs will reflect what's needed for running both Vectorworks and Renderworks (Cinema 4D Engine). Vectorworks is not 64bit. The Cinema 4D engine is as well as supporting multithreading. It does not use the graphics card and relies on the main processor only.

See this article in the section called Other Talk for more info about the switch to 64bit on a Mac - http://architosh.com/2012/06/aia-nemetschek-talks-with-architosh/


Link to comment
It seems that this only should be the priority. They can tweak the window tool all they want, but if they can not harness the power and capacity of the modern day run of the mill computer, even some entry level machines now come with 6GBs, they are going to be left far in the dust.

My feeling is they shouldn't be in a position where they have to prioritise so much.

Link to comment
The minimum specs are 4GB of RAM - 8GB Preferred. I am not an engineer either, but If they are utilizing more than 4GB I think that means they have moved to a 64Bit architecture.
A common misconception...

32 bit address limit is a process limitation, RAM is shared amongst whole system.

Iirc that Renderworks is 64 bit and being a separate process would not affect VW.

Also, to confuse things, you have 64 bit address and 64 bit data. 64 bit address means that you can have bigger things, 64 bit data means that you move bigger things around, which may be faster or slower depending on what you want to move and to where. So 64 bit architecture can mean either - but in my book means both.

Link to comment

My feeling is they shouldn't be in a position where they have to prioritise so much.

You are right, but it seems that they were caught quite flat footed. This migration to 64bit could easily have been foreseen, but it seems as if they did not act on it early enough. Maybe because the way the program was constructed made it too difficult, but they their back is in a corner at this point. While they shouldn't be in this position, they are now, and they need to work hard to fix it - probably above almost any other concern.

Link to comment
They have stated long ago that they are working on a from the ground up rebuild version and are going 64 bit and multi-core.

It's taken too long. I begin to wonder how big there team is?

dont under estimate the complexity in doing this. I use to develop large computer systems for a living and one of my projects was to port our 32 bit app to 64 bit. Our app was similar age to VW but was a server/server based app that inherrintly would run across multiple processors, so the complexities of having to rewrite algorithms to be thread safe or multi processor aware was not on the list.

It took about 18 months to port, test and more importantly optimise data structures for 64 bit. Without optimisation the app ran slower than 32 bit version.

For a ground up rewrite expect much more time. I worked on the system for just over 10 years. In that time, two ground up rewrites came and went without seeing the light of day. A third made it to production only for it to be replaced within a year by a much simpler system that offered about 20% of the functionality.

Our >25 year old system outlived and out performed the lot. The only reason why they replaced it was because being so old it was perceived that maintaining it was expensive and slow.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...