Workflow management

[VIRTUALENVIRONS]

On 9/12/2023 at 4:38 AM, vassen said:

My files have reach 600MB and i am yet to create viewport for presentation and print.

Addressing only presentation and print.

 

Your problem is not new and there is a reason many people choose to render/animate in CINEMA 4D.  The files become much lighter, not necessarily smaller, but lighter.

 

A CAD system has to carry much more technical information than an Animation System.  Even if you don't add anything yourself, the system does it on its own making files heavier.

 

When you send a file from Vectorworks to CINEMA 4D iT becomes much lighter.  Symbols or instances also don't need to carry any info.

[line-weight]

5 minutes ago, VIRTUALENVIRONS said:

Addressing only presentation and print.

 

Your problem is not new and there is a reason many people choose to render/animate in CINEMA 4D.  The files become much lighter, not necessarily smaller, but lighter.

 

A CAD system has to carry much more technical information than an Animation System.  Even if you don't add anything yourself, the system does it on its own making files heavier.

 

When you send a file from Vectorworks to CINEMA 4D iT becomes much lighter.  Symbols or instances also don't need to carry any info.

 

What @vassen is trying to do here shouldn't be a problem in VW, and exporting to cinema 4D is unlikely to be a useful workflow.

 

It's not a rendering - it's a shaded view.

[vassen]

15 minutes ago, VIRTUALENVIRONS said:

Addressing only presentation and print.

 

Your problem is not new and there is a reason many people choose to render/animate in CINEMA 4D.  The files become much lighter, not necessarily smaller, but lighter.

 

A CAD system has to carry much more technical information than an Animation System.  Even if you don't add anything yourself, the system does it on its own making files heavier.

 

When you send a file from Vectorworks to CINEMA 4D iT becomes much lighter.  Symbols or instances also don't need to carry any info.

Thanks for those info.

But the issue is not to send to cinema 4D or any other rendering software.

The issue here is within Vectorworks itself. The viewport take long to update when we are in shaded or openGl mode.

That why i was asking about workflow in vectorworks if everyone have same issue as i am having or your workflow is different to what i am doing.

[bcd]

VW->Lumion is great there's no reason to consider shifting to C4d - in fact if you were do do that it would be significantly better to render using the Redshift engine in C4d rather than C4d itself.

In this instance, I'd be placing low-res trees in VW, Exporting the Tree Layer on it's own and over in Lumion import the Trees Model, align it to your Master and use Place item on nodes  to replace all the low res trees with high res, optimized Lumion trees.

Edited September 13, 2023 by bcd

[vassen]

10 minutes ago, line-weight said:

 

What @vassen is trying to do here shouldn't be a problem in VW, and exporting to cinema 4D is unlikely to be a useful workflow.

 

It's not a rendering - it's a shaded view.

@line-weight thanks to you are straight to the point.

I guess i would have to find a new where of doing my workflow to be able to update my viewport rapidly as on some project i take roughly a whole date to update my viewport and generate all the PDF which is quite a pain as you can not doing anything when viewport is being updated.

[vassen]

3 minutes ago, bcd said:

VW->Lumion is great there's no reason to consider shifting to C4d - in fact if you were do do that it would be significantly better to render using the Redshift engine in C4d rather than C4d itself.

In this instance, I'd be placing low-res trees in VW, Exporting the Tree Layer on it's own and over in Lumion import the Trees Model, align it to your Master and use Place item on nodes  to replace all the low res trees with high res, optimized Lumion trees.

@bcd That seemed to be a nice idea, need to look after it.

The issue for me is that i do print my vectorworks viewport without rendering sometime, so having low res tree or other low res element quite affect the quality of presentation around the building or house. Printing of elevation and isometric view with low res element is not presentable to my point of view....

But working on it to see how to reduce the pain of updating without loosing time.

[bcd]

Perhaps Low res for the full site on one Layer and high res on another for your close shots only?

[line-weight]

20 minutes ago, vassen said:

@bcd That seemed to be a nice idea, need to look after it.

The issue for me is that i do print my vectorworks viewport without rendering sometime, so having low res tree or other low res element quite affect the quality of presentation around the building or house. Printing of elevation and isometric view with low res element is not presentable to my point of view....

But working on it to see how to reduce the pain of updating without loosing time.

 

Have you done the experiment of hiding all the trees, and seeing if this helps?

 

Best to be sure about the cause of the issue before working out solutions.

[vassen]

3 minutes ago, line-weight said:

 

Have you done the experiment of hiding all the trees, and seeing if this helps?

 

Best to be sure about the cause of the issue before working out solutions.

For this project, i have not yet made the viewport for this project. will soon do it and keep you updated.

[vassen]

14 minutes ago, bcd said:

Perhaps Low res for the full site on one Layer and high res on another for your close shots only?

Will check if able to do it now...

[Carol Reznor]

hi @vassen

 

If it is not the trees that are causing the 'slowness', try checking both your hardscapes and site model.

 

what to check for in your Site model: is the Source data simplified enough for ease of use? For example when the source data consists of polylines, how complex are these?

 

what to check for in your Hardscapes:

- in the drawing: Are the paths of the Hardscapes (Boundary mode) properly closed? Sometimes it happens when you check the path within the Boundary Hardscape the line is not actually closed) - Can cause issues. 

- are the hardscape components defined by materials? Do these materials use a texture Surface hatch? Surface hatches can slow down the rendering of VP in my experience. I believe changing some VP settings in this case can help.

Good luck!

Edited April 18 by Carol Reznor

[vassen]

1 hour ago, Carol Reznor said:

hi @vassen

 

If it is not the trees that are causing the 'slowness', try checking both your hardscapes and site model.

 

what to check for in your Site model: is the Source data simplified enough for ease of use? For example when the source data consists of polylines, how complex are these?

 

what to check for in your Hardscapes:

- in the drawing: Are the paths of the Hardscapes (Boundary mode) properly closed? Sometimes it happens when you check the path within the Boundary Hardscape the line is not actually closed) - Can cause issues. 

- are the hardscape components defined by materials? Do these materials use a texture Surface hatch? Surface hatches can slow down the rendering of VP in my experience. I believe changing some VP settings in this case can help.

Good luck!

Thanks for your detailed answer. The Hardscapes are properly close.

We uses all vectorworks materials in the design.

[shorter]

On 9/12/2023 at 10:01 AM, Tom W. said:

 

600 MB is not particularly big. The largest file I'm working on at the moment is 2.7 GB + not having any issues with it. Another one is 2.2 GB. A third is 1.4 GB.

 

I personally have not found that design layer viewport or layer import referencing radically reduces file size + often creates more problems that it solves.

 

To @Christiaan and @Tom W. re: referencing... It works.  But you have to know how to use it properly.  It only 'creates more problems than it solves' if you fail to adopt the correct protocols and fail to follow those protocols.  It is NOT an adhoc workflow, i.e. you need to plan for it's use.

[Tom W.]

20 minutes ago, shorter said:

 

To @Christiaan and @Tom W. re: referencing... It works.  But you have to know how to use it properly.  It only 'creates more problems than it solves' if you fail to adopt the correct protocols and fail to follow those protocols.  It is NOT an adhoc workflow, i.e. you need to plan for it's use.

 

I'm quite good at the planning/organisation side of things, the problems I was referring to were related to geometry not translating in the references. Specifically, Roof clipping in the source file was being lost in the target file meaning that the referenced DLVP of the building would show Roof components sticking out of the Walls in 3D views. This meant I had to turn off those component classes for it to display correctly + also meant I couldn't generate section VPs from the target file, I had to go back to the source file in order to do this, where of course I only had that building + not the site model or any other buildings...

 

So I wouldn't completely agree with your 'it works' statement...

 

I submitted a bug about this several years ago, not sure what the latest is.

 

I do still use referencing but not generally for the main building model, more for any contextual buildings. And since the file sizes are only marginally larger than those when I was referencing in everything I'm quite happy doing it this way.

[shorter]

1 hour ago, Tom W. said:

 

I'm quite good at the planning/organisation side of things, the problems I was referring to were related to geometry not translating in the references. Specifically, Roof clipping in the source file was being lost in the target file meaning that the referenced DLVP of the building would show Roof components sticking out of the Walls in 3D views. This meant I had to turn off those component classes for it to display correctly + also meant I couldn't generate section VPs from the target file, I had to go back to the source file in order to do this, where of course I only had that building + not the site model or any other buildings...

 

So I wouldn't completely agree with your 'it works' statement...

 

I submitted a bug about this several years ago, not sure what the latest is.

 

I do still use referencing but not generally for the main building model, more for any contextual buildings. And since the file sizes are only marginally larger than those when I was referencing in everything I'm quite happy doing it this way.

 

When I say 'it works' i was not referring to referenced DLVP... 😉

[Tom W.]

9 minutes ago, shorter said:

 

When I say 'it works' i was not referring to referenced DLVP... 😉

 

Ok then I should clarify that the Roof clipping bug also occurs when using Layer Import Referencing. I did refer to both methods of referencing in the original post you quoted.

Edited April 19 by Tom W.

[shorter]

30 minutes ago, Tom W. said:

 

Ok then I should clarify that the Roof clipping bug also occurs when using Layer Import Referencing. I did refer to both methods of referencing in the original post you quoted.

 

We don't use Roof Clipping.

[Tom W.]

4 minutes ago, shorter said:

 

We don't use Roof Clipping.

 

Is that what you meant by 'you have to know how to use it properly'? 🙂

Not really a solution.