Good things:

[bcd]

VWGM - I love how the OGL doesn't need to refresh thanks to the Vectorworks Graphics Module.

Now flyover in OGL is superior to wireframe!

[PVA - Admin]

The Vectorworks Graphics Module is the answer to all of our VW-related hopes and dreams. I am only being slightly overdramatic.

More and more functionality is getting loaded into it all the time, the speed everyone is looking for will happen once the VGM is in charge of 3D wireframe and Top/Plan view as well. Both of these are tasks that are being worked on full time here.

[willofmaine]

Including speedy section viewports? Regardless of the number of cores one might have access to?...

[PVA - Admin]

It wouldn't be regardless of cores, it would be exactly relative to how many cores.

Currently, no matter how much hardware horsepower you throw at Vectorworks when creating a section, it will max out what the software is capable of WAY before it will approach the limits of what your hardware can do.

Moving things to the VGM removes that limitation and allows Vectorworks to go as fast as your computer can handle. As an analogy, it means your top speed is limited by the car you are driving, not Vectorwork's highway speed limit. Now, specifically allowing sections to be calculated using your computers graphic hardware is actually very complex and not something that is going to happen soon. Moving OpenGL, 3D wireframe, top/plan and "visual" things like that over is much easier.

It may seem like I am dancing around the question and that is because I am. It is actually way more complicated to explain than you might think.

I will go with another analogy to make it easy on anyone reading:

-OpenGL is like running a race, and section viewports are like plowing a field.

-Your GPU is a high power Formula 1 race car. Your CPU is a horse and plow.

The horse is very good at plowing the field, and the car is very good at running races. If you tried to make the horse run a race (which is what we did in VectorWorks 12, for instance) it will be very slow, but it will finish eventually.

Obviously, the race car is much faster than a horse, but if you just tried to attach the plow to the back of it and take off, you would encounter... problems. That sort of sums up the task of moving section viewports and other calculation-based functions like that into the VGM.

Hopefully I didn't just make it more confusing.

If you are interested in the ACTUAL technology that would be required for us to do this, Google-up on "CUDA" (Nvidias version of GPU computing) and "OpenCL" (Intel and ATI's versions of GPU computing.) This article actually explains the concept rather well, but it is loaded with jargon.

Edited May 30, 2014 by JimW

[PVA - Admin]

However, Section Viewports are currently 32bit single-core CPU only, so even just moving them to 64bit and multi-core CPU, to say nothing of moving them to the VGM, would be worlds of improvement on the current experience and that is something that will happen much sooner than moving section viewports to the VGM.

[willofmaine]

Jim! Thanks for taking the time to explain this! I like your analogies.

As far as I can tell, with the possible exception of their having more than four cores, Mac Pros seem entirely excessive when it comes to Vectorworks. I think you'd written somewhere that i5 and i7 processors were the minimum (in Macs?); maybe i7 is the maximum necessary for VW.

If you load up a 27" (2560 x 1440 display, 4-Core) i7 iMac with 16 GB RAM, a 4 GB GPU, and 3 TB of storage, it's about $3,000.

A 6-Core Mac Pro is $4,000 to start with (skip the base Pro, since it's only 4-Core). Add maybe $600 for a 27" 2560 x 1440 display, and it's $4,600? or over 50% more (and that only includes just a 3 GB graphics card and storage limited to 256 GB). I can't figure out exactly what's available for external storage for the Mac Pro - let's say maybe $600 for 2 TB. Add that and another $600 to get at least 4 GB of VRAM (which would actually have to be two 6 GB GPUs, one of which it seems VW would never use) and it's $5,800, or over 90% more!

If GeekBench 3 is to be believed (in this context), single-core / multi-core scores are:

My '06 Mac Pro: 1509 / 5272

27" iMac: 3899 / 14673

6-Core Mac Pro: 3574 /20654

Does this suggest that 32 bit, SC section viewports might be 2 1/2 times faster for me on a new iMac (3899/1509)? And almost 10 times faster once they are 64 bit, MC (14673/1509)?

And to go from the iMac to the 6-Core Mach Pro would only be about 1 1/2 times (40%) faster (20654/14673)? Not to mention the slower processor speed in the meantime, while VW sections remain 32 bit? This doesn't seem like much of an increase for the 50% to 90% greater cost? Maybe if one's computer primarily just sits there cranking out hidden line drawings or Renderworks renderings, the 6, 8 and 12 core computers might make sense, but, the vast majority of my time is spent figuring out what I'm going to draw and drawing it? I suspect being 40% faster 5% of the time would never pay for a Mac Pro...

And when it comes to 3D wireframe, top/plan, and OpenGL, even my '06 Mac Pro with its 256 MB graphics card has typically been sufficiently fast (at least until VW 2014 that is, which crashes with every OpenGl rendering...).

Okay, sorry this got so long winded! I wanted to write it out for myself at least; maybe someone else will find it helpful if they're trying to similarly decide between an iMac and a Mac Pro...

Again, thank you!

Will

[PVA - Admin]

For now, there would likely be no difference in section viewport times no matter what hardware you picked. There are other limitations on sectioning performance than just what one core of the machine is capable of for the time being.

Most of my testing and benchmarking has been done around Renderworks specifically, not sectioning, since it is so limited by other factors such as file composition and geometry currently.

This isnt real data, but it is an approximation of what you might see in testing results for section viewport speed at the moment:

CPU 1 - 2.0GHz pentium processor, single-core: Section time 10 minutes.

CPU 2 - 2.0GHz pentium processor, dual-core: Section time 10 minutes.

CPU 3 - 4.0GHz pentium processor, single-core: Section time 8 minutes.

CPU 4 - 4.0GHz pentium processor, dual-core: Section time 8 minutes.

CPU 5 - 4.1GHz i7 processor, 8-core: Section time 8 minutes.

CPU 6 - 90.5Ghz 65-core liquid nitrogen cooled quantum processor from the year 2045: Section time 8 minutes.

[Kevin McAllister]

@Jim Wilson this is a very old thread about section viewports. How many of the limitations mentioned here still exist for section viewports in VW2019? I find that with higher geometry files Vectorworks sits in the "Section" portion of rendering a viewport for a long time. This doesn't seem to change with each update even though many other advances have been made with section viewports. I'm currently working with a file full of 3d polygon geometry (imported venue which I've placed my solids geometry into) and it is very slow.

 

I sure hope this gets some work for VW2020.

 

Thanks,

 

Kevin

 

[PVA - Admin]

Nearly all of th delay in sections is because they are still single core. Geometry calculation is very likely to be the last thing that becomes multicore and unfortunately, that won't make the cut in 2020, as there are party items left still that have to go first.

 

It'll happen, but not all at once.

 

Edit: (Large Items)

[Kevin McAllister]

11 minutes ago, Jim Wilson said:

Nearly all of th delay in sections is because they are still single core. Geometry calculation is very likely to be the last thing that becomes multicore and unfortunately, that won't make the cut in 2020, as there are party items left still that have to go first.

 

It'll happen, but not all at once.

 

Hi Jim,

Thanks for the info. What is a party item? 🙂

I guess when geometry calculations are finally upgraded it will feel like everyone has a new computer since it affects so many other things.

Kevin

 

[PVA - Admin]

Hehe woops, that's what I get for doing forum replies on my phone on a plane to Phoenix.😁

 

 

[Kevin McAllister]

1 minute ago, Jim Wilson said:

Hehe woops, that's what I get for doing forum replies on my phone on a plane to Phoenix.😁

 

 

Same travels and have a great summit! I'll make it to one sometime....

 

Kevin

 

[herbieherb]

Is this also the reason that it takes longer to move a line than to move a polygon? Is the polygon already optimized and the line not?
I found out that way: I draw 40'000 lines and measure the time until I can continue working. The same takes much less time with 40'000 polygons with e.g. 3 points. Actually, it should be the other way round, because I have to calculate more coordinates for the polygon?

[PVA - Admin]

1 hour ago, herbieherb said:

Is this also the reason that it takes longer to move a line than to move a polygon? Is the polygon already optimized and the line not?
I found out that way: I draw 40'000 lines and measure the time until I can continue working. The same takes much less time with 40'000 polygons with e.g. 3 points. Actually, it should be the other way round, because I have to calculate more coordinates for the polygon?

Honestly I would have expected they take the same time, or as you suggest, that the polygons would take more time. That is weird...

But yes, from what I understand modifying object parameters (anything from moving a simple pile of things all the way to bulk altering values of a collection of complex plugin objects like Doors) is all controlled by "Core" which is the single thread engine that does all our math and geometry calculations as well.