Why? could you resume that Pablo told in Blender Today?
Not sure I understand the question, but if you mean where he was saying that, it’s 52 minutes in, when addressing Piotr’s question regarding the edit mode performance.
“the highest priority at the moment is undo” (I’m guessing that’s in the context of performance improvements)
2 Likes
I believe (but could be wrong) that the undo problem is due to blender reloading the entire file every time undo is pressed, so if you have a large 1.5gb or over file, you’re in for a world of frustration. It probably explains why some sliders (such as the creation parameters) cause blender to become unresponsive when moving them (they must be writing to the file in increments rather than when exiting the creation options?).
I believe USD will resolve this issue completely, assuming blender is adopting it internally and not just for import/export. Fingers crossed they are using USD internally in combination with Hydra for cycles and EEVEE, because we’ll see a MASSIVE performance increase throughout the software, not to mention the viewport will be able to handle much more geometry/instances without breaking a sweat (similar to Clarisse and more recently Houdini).
Also if everything nodes works anything like Houdini, then the .blends will be much smaller anyway, as the file will only store the steps to create geometry rather than the geometry itself. Of course you could consolidate each geometry’s node tree into a file output node, save it out to it’s own file, and then disable that node tree in favour of a file input node. It wouldnt result in a lighter file, but it would mean there was less to update/reload each time there was a save, undo or a file open.
1 Like
Ye, that’d sum up the undo problem I guess.
Was there any indication that Blender is going to be able to handle USD’s natively? I tend to get my hopes up way to fast, to be on the safe side I’m counting on it to be just an exporter. Which is perfectly fine.
Would be pretty neat though, I’m just afraid that that’d be a project that takes years to finish.
Not in cases where the slow down is due to a single high density mesh. If you deal with each datablock individually you see gains only if those datablocks are small. The undo needs to store changes on a more granular level than just storing the last state of the object.
I think native USD would be amazing, but considering Blender is making a big push for sculpting where meshes can easily reach millions of polys, the undo system needs to be addressed properly without relying on the one sided gains that USD may bring.
As for nodes, the high density mesh problem still exists unless you want to make a node for each individual brush stroke or modeling operation. Do you realize how much longer it takes to model with nodes if you only need to make one off objects. You only see speed gains with with nodes in modeling if you need to make many similar objects. So if we rely on nodes for speed ups, then the burden is on every single artist that uses blender instead of the devs making the change once.
1 Like
Hello DanPool, the node system shouldn’t slow down the modelling process, it would just be a tool to record each action in nodal format, so just a different and more user accesible/powerful way of exposing the undo history to the user in an editable format. This should also speed up undo/redos because the actions would be stored on a per object basis rather than having to update the entire file. Additionally this would enable a user to undo non sequentially and also on a per object basis (currently you have to go through undo’s sequentially for all objects). Each stroke/non modifier based change made in edit mode shouldn’t be stored in the edit mode node as it would become too cumbersome, they should be stored in ram and then consolidated into one node specific to the type of action when exiting the specific tool/mode.
Here’s an example node tree of a cube thats created, moved, scaled, edited in edit mode, subdivided, then sculpted, then a material added.
geo node called “my cube” which contains:
cube create node -> Translate node -> Scale node -> edit mode node which contains it’s own nodes (all manual edits such as moving verts would be stored in ram until changing tool at which point they would be consolidated into a user edit node, and all modifiers such as extrude, bevel, smooth, and even addon’s such as multi extrude would get their own node each) -> subdiv modifier node -> sculpt mode node (works the same as the edit node) -> material node
cube node contains basic set up like length/width.
edit mode node which contains for example:
user edit node (where the user manipulated the geo’s verts, faces and edges using move rotate and scale (kept in ram until the user uses an edit mode modifier, at which point this node is created and the ram released) -> extrude node -> bevel node -> Multi extrude addon )
What I’m describing above is similar to how Houdini works, hence it being so powerful.
Just to clarify I’m not suggesting the user would have to manually create the nodes, rather the system writes them out automatically to record what the user is doing. This is where blender could potentially become much better than Houdini, because it’s viewport based workflow is leaps and bounds ahead of Houdini’s.
Guys, we’re complicating life here …
The devs have already identified the problem … and also the possible solution … they have to make “read only” the elements of the scene that do not change, and make the undo system act only on those parts that change … so doing the performance increases significantly.
Brecht gave a clear overview here.
https://developer.blender.org/T60695
That’s a solution for the current system for sure, but it doesn’t come with all the benefits outlined in my comment above.
my comment had a more generic reference, I didn’t comment directly on you
Let me explain why Brech solution will deinitively solve the problem and Undo become super-fast:
because instead of “downloading - uploading” the whole scene on disk, as happens now, blender will write and read, if for example we have moved 500-1000 vectors in a single step, only and exclusively these … it goes without saying that there are very few data compared to what happens now … and all the other possible solutions will become superfluous to the solution of the problem, in my opinion.
yep, it’s basically the same solution as what I mentioned above. The main difference is that with the node based history tree, everything is exposed to the user, allowing for the tweaking/animation of each actions parameters, and non sequential “undo’s”. In conjunction with blender using USD, blender would become a powerhouse capable of far more than it currently is.
Imagine being able to animate the parameters of an edit mode modifier/addon such as multi extrude for example. It’s basically the same as the animation nodes addon, but much better, because animation nodes is based on Python, which is really slow compared to C++, and I don’t think python is capable of multithreading either (could be wrong on that).
I think it’s a bit more complicated than that … as far as I know blender and its native format are highly integrated … a good blender part is in its blend files.
i think it would take a long time for a conversion to USD
We consider this a high priority task and will try to get it solved sooner rather than later. It’s marked as high priority in T63728: Data, Assets & I/O Module.
2 Likes