Tag for Blender tasks related to datablocks, library linking, assets, overrides, and related topics
Thanks for the help! Just tried this and it totally works. However this process is a bit obscure. I'm sure it's just my lack of understanding of how scene instancing and collections work under the hood. I'd like to suggest a new menu item:
I started using blender with 2.78 and use it daily. I'm pretty sure there is no significant slowdown in 2.8 compared to 2.78.
there is no bug here. After making everything local, your view layer is still not instancing the MonkeyCollection, you only have an empty object instancing that collection. in other words, your monkey object itself does not exist in the scene. You have to instantiate its collection in the scene (e.g. by drag-dropping it in the outliner, from the instancing empty to the master collection)> then you can edit it as any regular object.
will it be possible to maintain links to USD's, so that when the USD is updated, the Blender file referencing it will be too?
Tue, Aug 20
It's been a couple years since the comments about USD. Now, it's open-source and widely adopted, and Sybren A. Stüvel has done excellent work on Blender I/O (which isn't finished yet, but it's already very impressive!). So I have a question: will it be possible to maintain links to USD's, so that when the USD is updated, the Blender file referencing it will be too?
I think it could work like this: Blender would store a path to the USD to do the linking. A "fake" .blend file would be created, importing the USD once the file with links to USD is opened. Then the links would point to the "fake" blend file with the imported USD. The USD would be like DNA, and the "fake" Blender file could be like a half-way between DNA and RNA--- The .blend file with links to USD would think it's linking to .blend file DNA, but that .blend file would just be a temporary import of the USD. Does this make sense? Of course, referencing USD's directly would also be awesome, and since this format is open-source, maybe it's possible. But I think that would require building the USD I/O into linking and appending.
Mon, Aug 19
@Campbell Barton (campbellbarton) my understanding is that reports about 2.8 undo being slower than 2.7 are not issues in the undo system itself, but rather related to features like subdivision surfaces and the dependency graph.
Undo is bad in both, this is not a regression, any complex file makes undo nearly a torture to use. Just animating a camera for example, you are just transforming the camera, and making undo in a big scene takes A LOT instead of being instantaneous as it should be
Is the issue with slow undo known/reported?
Are there examples of comparable files which perform when in 2.7x and very badly in 2.8x?
Think rB63bf2ddc5dcf did fix that issue fully actually. remaining issues are from missing override flags in other ID RNA pointer props.
Sat, Aug 17
I agree with the understated importance of this issue: no matter how great the advanced functions of a software are, if it's basics aren't rock solid, it's not usable in an actual production process.
The Undo function is one of the most used and the lag it currently generates kills all possible efficiency that Blender can otherwise provide.
The "undo step is no more expensive than the associated operation" is an absolute must-have before I can advocate for using Blender in a professional context, which I hope I eventually will.
Fri, Aug 16
I agree with you guys, I think this should be high priority, I work for the video game industry as a Senior Character artist and I'm wasting a lot of production time because of the slow undo. Characters scenes are heavy ( around 25 millions polys ) and we use a lot sculpting tools with subdivision modifier. I'm currently testing blender 2.8 features and I'm evaluating if it make sense to use it for the whole character modeling production. Unfortunately for the moment I can't recommend it to my co-workers because of this performance issue. Blender team did a great job with this 2.8 release and I love using this software, as soon as this performance issue is fixed I think it will be awesome to use and ready for production.
Thu, Aug 15
hi @Brecht Van Lommel (brecht) , with version 2.8, we decided to give another go to Blender and overall it is great release and we were considering switching, but this undo issue is a the biggest show stopper we found so far. I'm surprised to be honest with the fact that this is considered "normal" priority. I have never worked in a production that doesn't have a few thousand objects per scene with a few million polys. If undoing a move takes a couple of minutes, this makes blender unusable for most productions I think. I decided to add this comment with the hope to bump this up a bit. I hope that's OK.
Wed, Aug 14
I've updated the patch based on the feedback.
Tue, Aug 13
Mon, Aug 12
Fri, Aug 9
Have been working on this today, have it partially working (crashes still a lot, the append part of the code is very complicated :( ), but am hitting some design issues actually.
Thu, Aug 8
Better (less brute-force) approach to fix materials issues from placeholders.
Wed, Aug 7
Ah, thats because the Safe Areas are actually not part of the Camera, but of the Scene (appending the scene will correctly bring this over).
It's not only the camera using it, but also the sequencer, see https://docs.blender.org/manual/en/dev/render/cameras.html#safe-areas
Hm, thats strange, checking...
Tue, Aug 6
Is there a way to avoid the loop over all datablocks?