rb-arch
-
Posts
111 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by rb-arch
-
-
No Vectorworks live link. Pretty disappointing and I'd gladly pay $250 per station to get it.
-
1 hour ago, Tanner Shelton said:
@rb-arch This was brought up in another thread, here is a link to a post from JuanP
His comment on Twinmotion was "The development is happening during Q1, stay tuned for more updates!"
Excellent! Finally some good news.
Regarding the fans, we have mid 2015 iMac 27" machines loaded with RAM and TW make the fan go but we don't mind pushing these machines hard. We've batch rendered in Artlantis (all 5 machines) for years and the fans crank away like a render farm!, no issues. The fan is doing its job. RB
-
I wonder if there's going to be a VW plugin for Twinmotion 2020.
-
3
-
-
- Popular Post
- Popular Post
1 hour ago, Sean@UVS said:Agreed!
It's extremely frustrating not knowing if the software is actually doing anything or not. When i export an image, the only indication I get that anything is happening is that the program freezes up. When it comes back to life, I know the render has finished. I get the teacup and progress bar sometimes when rendering in the working environment, but it often takes it's sweet time to show up. Surely, it's not supposed to be like this.
Running a MacBook Pro (15-inch, 2019) with 2.4 GHz Intel Core i9, 32 GB 2400 MHz DDR4, Radeon Pro Vega 20 4 GB & Intel UHD Graphics 630 1536 MB.
MacOS Mojave, vectorworks 2020 spotlight.
Glad we're not the only ones. Rather than new features, I'd prefer stable software. It is stuff like this that makes me re-consider the subscription service. We still have project sharing bugs from 2018 that aren't resolved.
-
7
-
I wish they'd fix this.
It really does take away from the user experience and updating (renders, shared files, viewports etc.) is way more annoying. You have no idea what is going on and then you can easily refresh, or re-update because you didn't think you clicked it the fist time.
This basic stuff drives me nuts.
-
2
-
-
On 9/11/2019 at 10:24 AM, rb-arch said:
Here's a link showing the disappearance of the status / update bar on the lower right.....
Anyone else having this problem? All our iMac's are like this - the status bar doesn't show updates when saving, saving and committing or updating viewports. It is amazing how much more frustration it adds when you don't know how far along it is. My video shows the difference between 2020 and 2019. The link should show a high quality video.
-
Here's a link showing the disappearance of the status / update bar on the lower right.....
-
The status bar / message bar update that would show progress for saving, saving committing, updating viewports etc. doesn't work on my Mac. Pretty annoying and I hope they didn't take away that functionality.
-
Thanks can you point me to some samples?
-
On 8/22/2018 at 4:21 AM, zoomer said:
I think the problem would be more if Chaos Group is interested at all
to port VRAY to just another App platform that may not have a large
user base and also a large degree of Mac users.
This is precisely the group in the market that is underserved. We use Artlantis and get decent results, but it is buggy and not well supported. We've been looking for an alternative and there is none. There's no way we're buying cinema 4D to get to V-ray etc. We've tried everything, Twinmotion (bad renders), Lumion (won't work fro Mac), V-Ray (can't get there from VW), etc.
For us, it is becoming unacceptable. The Mac users are being stranded.
-
1
-
-
On 2/10/2019 at 11:25 PM, KIvanov said:
Hello rb-arch,
This is knowing issue and it will be fixed.
Best Regards,
Kostadin Ivanov
When?
-
We're trying to use project sharing in 3 person office. We thought we'd use the new data tags and tag all the objects in the sheet layers. It has been an unmitigated disaster. Now, you can't even update a viewport (elevation or section) without checking out tags on other sheets - it makes no sense. The tags take ownership of everything so it is nearly impossible for two people to work on the project.
Even with an entire elevation sheet layer checked out, if we try to generate the viewports it will ask us to check out tags on floor plan sheet layers.
-
1
-
-
8 hours ago, Boh said:
ThanksTolu. Appreciate the response. Still confused however.... For now I will stick to the laborious cut-and-paste-from-backup technique when trying to retrieve unsaved/uncommitted changes to a crashed working file.
You're going through the same learning curve we did about 4 months ago. In project sharing, it is our opinion that the auto save files are essentially useless. Cutting and pasting changes doesn't really work in practice.
As discussed above, we now set our autosaves to *overwrite* the WF. This gets around the cutting and pasting and keeps the relationship in tact between the WF and the PF. Lastly, it does seem to be intuitive to take the backup file and "save as" the WF, but this seems to be a bad practice according to Tolu.
-
5 minutes ago, Tolu said:
Absolutely! You can do that today though. You can set your Autosave setting to “Overwrite original file.” It is much like you hitting Ctrl+S (or Cmd+S) every x minutes.
I would not recommend every 3 minutes since there will be resource contention. Furthermore, you will be unable to work every 3 minutes because changes are not allowed during file save. However, if this works for your team, you can do that.
Wow, of course! I think I had that checked on years ago and stopped doing it that way. Since we started using Project Sharing we've never really revisited this tab other than to change the auto save settings. So thank you for the reminder, from a long time user LOL....... 🙂
Lately in our discussions here, we've also sort of agreed that we very rarely get any use out of the auto save back up files because it is just too onerous to cut and paste *certain* types of work.
Thanks.
-
2 hours ago, Tolu said:
Your WFs have a uuid, so I'm very opposed to anything that overwrites your WF. If you want to prevent down stream problems, I recommend you copy missing data from the back up file into your real WF. Do not save over or overwrite your WF. This might mean hitting (cmd+s) more often.
I would like to understand why Vectorworks is crashing multiple times a day, however. This is the underlying problem we need to resolve. Do you have ”Error Reporting” turned on in VW Preferences dialog? If not, could you please turn it on, and then send my a direct message with the last 6 digits of your serial number? I can analyze your crash logs to understand why VW is crashing frequently.
Thank you,
Tolu
We've had many discussion in the last year Tolu, and you've helped us get things running smoother and I hope we've helped highlight some software issues. One thing I would like to request is and auto save of the WF, that overwrites the WF just like it would if you hit Save manually. Unless you use this software to actually produce drawings I don't think you can fully appreciate what a pain it is to cut and paste from a back up file.
We used to set our Autosave to 3 minutes, and when we crashed, we'd take the Autosave file and save it as our "most up to date" WF. For reasons you've explained (technical ones I don't understand), this is a bad idea.
If there was an Autosave WF that would overwrite as I describe above, in theory you'd only lose 3 minutes of work (or your preferred setting) and you'd retain the uniqueness of the UUID number for the WF - to keep its continuity.
Just a thought from a long time user.
Randy
-
1
-
-
15 hours ago, JMR said:
As per instructions from NNA and other users, we now keep working files on individual pc's. Only the project file is on the disk server.
The working files are backed up to the same computer where they reside on.
In case of a crash you describe, I've successfully opened a working file backup and saved it over the working file.
As to ongoing issues, a few days ago we experienced the shifting walls problem again, in these cases the situation is remedied by saving a copy of the most current working file as an ordinary .vwx file and then re-sharing it. I'm going to bug-submit this when I can make the time.
We still experience frequent issues with crashes, checkouts, commits and title block borders. Project sharing is still very buggy, though there has been improvement from the earlier versions.
Oddly project file updating is extremely slow in 2018 for some reason.
We've had all these problems, and solid operations not reporting to the PF, Legend text going to zero point, walls un-joining, etc.
We've also recovered auto save files and overwritten Working Files, but were instructed by Tolu to not do that. Generally, we still find it to be buggy, but when it works it is great.
-
After countless back channel discussions, we still have the following (serious) problems with SP2. We have already issued drawings to the site that were in error because of project sharing, and I see no fixes to date for the following:
- Sheet layer work (when a user has the ENTIRE project checked out) is not pushed to the PF and other WF in the office. This happens regularly, and we try to ask "what were you working on", but things fall through the cracks. How do you summarize 3-4 hours of work to a co-worker - you can't. We have a situation right now were sheet re-ordering, viewport organization, and sheet re-naming is stuck in one machine. Nothing will push the work through. We have to remake the project file.
- Same as above for solid modelling in design layers. In that case sometimes we group the entire design layer and save and commit, and it will push the work through.
- Walls become unjoined, randomly, and frequently.
- Legend text, which resides in a design layer, will set itself to zero point font. That makes it disappear from the sheet layers. We had 5 sets of drawings issued to site with this error, which only occurs with project sharing.
So, we'll continue to beta test his for Vectorworks, on our dime. Note, we've taken every bit of advice from all parties for network settings, autosave settings, etc. Our network is new and fast, and our workflow is not exotic.
randy
-
We can't even get this software to push basic drafting changes to the machines. It is borderline useless right now - I've sent the files to people here and where I've purchased it and no replies so far.
-
We're still experiencing significant problems with project sharing, especially point #1 in the OP.
Quite frankly, we're sick of being the beta testers for this software. I'd prefer an issue of the software that improved the core commands over improvements to the site model for example. Of course all improvements are welcome but I get the sense that the focus is on new shiny stuff rather than the core of the software. Not good.
Project Sharing is critical, and if this continues much longer we'll be faced with a difficult decision.
-
1
-
-
23 hours ago, Tolu said:
2. This will happen if another user has created an object on that layer. That is another user has a soft lock on that layer. There are 2 types of lock - exclusive lock and soft lock. With exclusive lock, only 1 user owns that lock, and only that user can modify that object. However, multiple users are allowed to hold soft locks on an object. These objects are always container objects, e.g. layers, groups, etc. With a soft lock, users are allowed to modify the contents of the object, but they are not allowed to modify the object directly.
- If a user checks out an object or a layer, that object or layer is exclusively checked out to that user.
- If a user modifies an existing object (or creates a new object) on a layer, that object is exclusively checked out to that user. In addition, that user owns a soft lock on that layer.
IMO these soft locks might be the root of some of these problems.
There are *many* times when we do our work, save / commit / release only to find out later that there is still an obect checked out by another user. This object will not show up under the main project sharing window (which is should). It is getting confused. What we find is that a user may have an object checked out, but the layer released. In this scenario another user can't check out the layer until the other user does a custom release of the entire file. Maybe we'll start using the colours.
-
This is frustrating. The software pushes you more and more into the viewports, but then the tools don't work. We're trying to do a panel layout and count the symbols in the viewports and there's no way to do it.
-
Yes, I see your point but that is not a likely scenario.
IMO the most relevant and useful file is the file that was created 3-5 minutes before a crash. For example, it is possible that our WF's would not be saved for 30 minutes, or longer, while working. In that scenario, isn't it also possible (and likely) that the old, original WF wouldn't match the current state of the PF?
That's why we grab the back up and re-name because we feel that file will most closely match the status of checked out objects and layers etc. I also think it is impractical to paste work back into a WF from a backup, depending on what was lost.
So, my scenario would be:
- 12:00 I open my WF and check out some layers, do some work for half an hour.
- 12:27 a backup is created.
- 12:30 I crash without saving back to the local WF.
If I open the original WF again, it will say that I don't have anything checked out. The Backup file will though, and it is only 3 minutes old. This is why we don't use the method you describe, of pasting work back into an original WF. It is impractical and we'd would not think to do it that way. Also, in the scenario I outline above, with your method, I'd have to track down 30 minutes of work in that back up file and ensure I copy it over (which can lead to crashes as well if you've ever tried it!).
It is possible I'm not understanding you correctly, but I think I am.
-
2. We wouldn't recover something that old, but what does happen is you need to remover something in the last hour or so from your local drive's VW backup. We have our autosaves set to 3 minutes, so we typically don't lose much work. However, I do think our practice is to recover the back up file, then save as OVER the local WF, then save and commit. Is that a problem.
-
4 minutes ago, Tolu said:
Just wanted to chime on this report:
1. It is recommended that your Working Files (WF) are saved locally.
2. Do not use auto saved backups of your WF with Project Files (PF) . It is best to always reopen the PF to get a new WF.
3. Do not make all users an Administrator. The original poster mentioned all users are administrators. This is dangerous. This means any team member release the exclusive lock that another user owns on one or more objects. If this happens, that user might lose work.
Thanks,
Tolu
Hi, to clarify:
1. OK.
2. What happens if your WF crashes and you need to recover your work and then commit save to the PF? If you can't use an autosaved back up of a WF what good is it? Maybe I don't understand what you're saying.
3. I understand what you're saying. Sometimes though things don't release so easily, even with custom release, so being able to override that from another user is handy. There's only 3 of us so it isn't a problem, but I could see it being one in a larger office. Maybe we'll try to make only one administrator just to see if it improves things.
To be clear, when this all works it is really great. When it doesn't there is a significant risk of missing drawing issues / problems on printed sets that make their way out for construction.
Twinmotion Plugin + Sync
in Wishlist - Feature and Content Requests
Posted
OK, that's encouraging but it also mixes in with some other thoughts that I have about these subscription updates. I'll save those for another thread, but so far TM seems smoother and faster and better. We're early adopters so no $$ yet.