Jump to content
  • 0

Syncing of Viewports in Project Sharing


Christiaan

Question

20 answers to this question

Recommended Posts

  • 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
Link to comment
  • 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.

Link to comment
  • 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?

Link to comment
  • 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
Link to comment
  • 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

 

Link to comment
  • 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.

Link to comment
  • 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 

Link to comment
  • 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.

Link to comment
  • 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

 

Link to comment
  • 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
Link to comment
  • 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.

Link to comment
  • 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'.

Link to comment
  • 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.  

Link to comment
  • 0

For what it's worth, and If I'm understanding everyone correctly... I strongly agree with Christiaan on there should be an ability to choose this option to for the very reason Chad doesn't think its a good idea... after all... when a viewport is rendered isn't the rendering technically an image file held in cache? Why couldn't that saved image view push back to shared file... or at least give me an option to do it? 

 

If I'm on "A" and update some building elevations... I should be and able to check out a viewport of that elevation, update it to show my changes, and then push back to shared file... Then user "B" does not have to replicate utilizing their processing resources to recreate the same elevation I already took time to render. 

 

In my opinion the advantage of using multiple users on a single file is not only sharing the labor involved in the production but also the user's workstations resources. This is especially true when I'm trying to assigning someone responsible for collating a printed set for review or mailing and they have to re-replicate strenuous computer resource re-rendeirng viewports someone else already rendered? 

 

I never realized this was the case until I had a deadline (always the case /eyeroll) and then found this thread. Christiaan, did you ever track down the work around to get it to push the viewport update back?

  • Like 1
Link to comment
  • 0
5 minutes ago, TimG said:

In my opinion the advantage of using multiple users on a single file is not only sharing the labor involved in the production but also the user's workstations resources.

 

Agreed. We could effectively be running a render farm in our office but we can't push the renders back to the Project File from separate Working Files.

  • Like 1
Link to comment
  • 0
7 minutes ago, TimG said:

Christiaan, did you ever track down the work around to get it to push the viewport update back?

 

No, the only way I've found is to generate a new Project File once your render is done and then tell everyone else to dump their Working Files and create new ones. That does work of course if you have renders from multiple files that you want added to the Project File.

Link to comment
  • 0

ok... this just in... (I'm a stubborn SOB sometimes). I took what you said Christiaan and figured a work around I thought I'd let you and other's for future reference know.

 

You can check out viewports, and if you do it pushes rendered VP back (at least it did on my two machines I'm testing it on) I found two ways to do it.

 

1. Rename the viewport (in my case I just put and _ at the end) This will check out the viewport and upon save + commit it will push the rendered view of that back.

 

2. Just cut the viewports you want to push (this will check them out), then paste in place. In my case it pasted back the rendered VP and a S+C pushed the rendered version for the other workstation to see as well.

 

Still would be better with a global option to turn this on or even a right click per viewport or something...  but these work arounds would at east allow renders pushed to shared file from multiple working files

  • Love 1
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.

Guest
Answer this question...

×   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...