• 0
Christiaan

Syncing of Viewports in Project Sharing

Question

Can somebody clarify: are updated/re-rendered viewports meant to sync across Project Files/Working Files in all cases? Or are there exceptions?

Share this post


Link to post

15 answers to this question

  • 0

I do not believe the act of updating a VP by one user in a Working file will affect the version of the VP in another users Working file - this seems to be a local operation, and you would want it to be local to each user to avoid eating up computer time.  Any data that is changed that might affect a VP is updated on Commit after the 2nd user refreshes.

Share this post


Link to post
  • 0
15 hours ago, Chad Hamilton HAarchs said:

I do not believe the act of updating a VP by one user in a Working file will affect the version of the VP in another users Working file - this seems to be a local operation

 

Really? Can't get my head around that. What's in the Project File then? If I update a viewport then save and commit and then somebody creates a new Working File, presumably they get the updated viewport. So why not somebody with an existing Working File?

 

15 hours ago, Chad Hamilton HAarchs said:

and you would want it to be local to each user to avoid eating up computer time

 

But that would mean everybody can potentially have a different version of drawings in their Working File.

Edited by Christiaan

Share this post


Link to post
  • 0

No - updating a viewport is just a rendering operation in a local window.  Saving and committing data is different.  Think about working in a non-project sharing environment - you work on the drawing, add some data, then save - if you go to viewports containing views of the data, they are not updated, they need to be updated.  Imagine you have two identical viewports - update one, the other is not affected until you update it.  And you don't want to have the viewports automatically updating - you want them to update on demand.  Otherwise you would be constantly waiting while the machine performed updates.

 

Project sharing works the same way in this regard - you work on the drawing in your Working file, save and commit.  The data is saved to the Project file.  No viewport is updated until there is a demand to update it.  For users in other Working files, the data isn't even read into their copy of the Working file until that user demands a Refresh.  If another user has a viewport affected by the new data after a refresh, that viewport isn't updated until there is a demand for update by the user.  

 

Viewport rendering isn't data - it's just making data visible.

Share this post


Link to post
  • 0
On 06/02/2018 at 5:21 PM, Chad Hamilton HAarchs said:

No - updating a viewport is just a rendering operation in a local window.

 

This is bonkers if it works this way. Sure, it's not underlying model data but it is drawing data. And drawing data are more important than model data when people are people from them.

 

On 06/02/2018 at 5:21 PM, Chad Hamilton HAarchs said:

Think about working in a non-project sharing environment - you work on the drawing, add some data, then save - if you go to viewports containing views of the data, they are not updated, they need to be updated.  Imagine you have two identical viewports - update one, the other is not affected until you update it.  And you don't want to have the viewports automatically updating - you want them to update on demand.  Otherwise you would be constantly waiting while the machine performed updates.

 

It's not automatic updating of viewports I'm expecting. It's the most recently updated viewport to be pushed to other Working Files that I'm expecting.

 

Rendered viewports are committed to the Project File so why not then propagated to the other Working Files?

Share this post


Link to post
  • 0

I've just tested this and it all works as I expected:

 

1. User A updates/re-renders a Sheet Layer Viewport in their Working File

2. User A executes a Save & Commit

3. User B refreshes their file and the relevant Sheet Layer Viewport is updated match the updated Viewport in step 1

 

So I guess my original question still stands: are there any exceptions to this process or should I treat such exceptions as a bug?

Edited by Christiaan

Share this post


Link to post
  • 0

Just to note,

We have this issue too, we have elevations viewports on sheets that are kept in the main working/project files, when user A updates anything inside the viewport / annotation etc, it's pushed through, but not the renders themselves, they seem to be only saved to that specific users own working file.

 

Is this on purpose by VW or a bug?

 

i figure it would be beneficial for them to be pushed through for other users too, such as everything else is, so that others can work on them as well, (for example if user A is on holiday etc),  rather than to have to re-render all the viewports again.

 

is this still the case in VW2018 ?

(we are currently using VW2017), 

 

kind regards anton

 

Share this post


Link to post
  • 0
1 hour ago, anton5 said:

Just to note,

We have this issue too, we have elevations viewports on sheets that are kept in the main working/project files, when user A updates anything inside the viewport / annotation etc, it's pushed through, but not the renders themselves, they seem to be only saved to that specific users own working file.

 

Is this on purpose by VW or a bug?

 

Anton, according to Chad it's on purpose.

 

Either way the behaviour appears to be inconsistent. I just tested this yesterday on a project and the renders were pushed to other working files.

Share this post


Link to post
  • 0
8 minutes ago, Christiaan said:

 

Anton, according to Chad it's on purpose.

 

Either way the behaviour appears to be inconsistent. I just tested this yesterday on a project and the renders were pushed to other working files.

ah thats interesting,

i wonder if there are any specific settings that you changed / or if anything was set up differently to manage to push the renders through.

 

kind regards 

Share this post


Link to post
  • 0

This is my experience - if you add annotations to a viewport in a Working File, then save and commit, it is pushed through to the Project File.  If you invoke the "Update Viewport" command to update a viewport in the Working File, whether for rendering, modeling, or to update any other new data, that does not cause viewports in Project File to have updated views.  To me that makes sense.  For example - imagine user A is working on updating the design documents, and user B decides to do a complex render of a view of the school, then saves and commits.  User A's file would be essentially locked up while the viewport rendered - that's why we have control over when viewports are updated.  I have no idea whether this is on purpose or not, but it does make sense to me.

Share this post


Link to post
  • 0

Yes i see your point Chad,

but that's just the point, we don't have control, we only have the option of not having it being pushed through, having an option to tick, (like when you referencing in to a separate sheet file for example), to cache the viewport renders, or in this case pushing it through to the other users, in a tick box option would be very useful. 

Just so that you could choose either way if you see what i mean.

 

kind regards anton

 

Share this post


Link to post
  • 0
21 hours ago, Chad Hamilton HAarchs said:

For example - imagine user A is working on updating the design documents, and user B decides to do a complex render of a view of the school, then saves and commits.  User A's file would be essentially locked up while the viewport rendered

 

This could be solved by only allowing rendering to be done if you have the viewport checked out, no?

Edited by Christiaan

Share this post


Link to post
  • 0
18 hours ago, Chad Hamilton HAarchs said:

If you invoke the "Update Viewport" command to update a viewport in the Working File, whether for rendering, modeling, or to update any other new data, that does not cause viewports in Project File to have updated views.

 

I'm sure I did this just the other day and the updated render was pushed to the other Working File. I will try and again and try to record it.

Share this post


Link to post
  • 0

I set up two computers next to each other so I could check and verify the conditions we've been bouncing around.  

 

1.  On machine A, add an annotation to a VP, then run 'save and commit' - refresh on machine B - the annotation immediately appears. 

 

2.  On machine A, update a rendered VP to show the rendered textures, sky, etc., then 'save and commit' - with the same sheet layer visible on machine B,  hit 'refresh' - no change on machine B until 'update selected viewport'.

 

3.  Add some data to the model on machine A - I added some geometry that would stand out very visibly, then 'save and commit' - on machine B, 'refresh' - the new data does not appear in the VP until you also 'update selected VP'

 

This works with any data that's added, including adding rendering textures, but anything on machine B that would normally require a viewport update still needs a view port update.  Adding annotations do not require a VP update, rendering operations, or model revisions, do require a VP update.  They will only show up after 'refresh' plus 'update selected viewport'.

Share this post


Link to post
  • 0
10 hours ago, Christiaan said:

@Chad Hamilton HAarchswhat do you think about having an Project Sharing Setup Option that gave us the option to only allow rendering of viewports if you have them checked out?

In my opinion, this would not be good.  I think it would be better to have the program behave as expected, and in my view the analogy would be between the behavior of data, revisions and viewports in a shared file should be the same as in a regular Working File.  To deviate would be confusing, and one more thing to have to keep in mind while working.  Again, the basic reason for not auto-updating viewports is to avoid chewing up machine computational time when you really want to be working.  

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now