u mean the zmodeler brush? the canvas is not a full 3d viewport with 3d camera…etc and doesn’t operate the same way as a DCC…so technically it’s not “full 3d” in that sense.
Interesting. I have no idea whether these are related issues, but I had to jump back to a build roughly a month old because I could not render (Cycles, not Eevee) a scene anymore which has worked smoothly before (memory usage exploded in the most recent builds). It seems to me there have been some regressions within the last few weeks.
Apart from that on the one hand I’m stunned how much faster some things now work in the viewport than in 2.7x despite the fact that they’re also drawn much nicer. Building a nature environment is so much more fun now … if it weren’t for that laggy UI anyway.
That UI seems to get slower just the same degree the viewport gets faster. I’m not fond of that complete revamp anyway, but okay, that’s because I’m selfish and don’t want to relearn stuff I can already do. Others may love it, I get that, and I’ll get accustomed to it sooner or later too.
That lagginess however … well, I hope it goes away soon because otherwise that would be a big step back, all the hard thinking about usability and workflow for naught.
The Zbrush canvas is basically a very simplified 3D viewport yeah, it doesn’t have all the features of a full traditional 3D viewport, but it’s 3D. When you are doing regular sculpting (Edit Mode On 
), using the regular sculpting brushes, you are sculpting in 3D.
Once you leave that mode (Edit Mode Off 
), and your model is dropped on to the canvas, and you can only use the 2.5 brushes (that part where if you draw on the canvas you’ll be painting several duplicates of your model) that’s when you are in 2.5D/Pixols mode.
1 Like
Armature: Speedup by removing unecessary check
Armature: Speedup Went from 37fps to 47fps with artificial testcase (lots of bones with one custom shape). Baseline 2.79 is 24fps.
6 Likes
funny thing, tested editing performance on a cube subdivided 8 times
8 core i9 9900k running at 3.6ghz (64gb ram, rtx2080)
vs a
macbook pro quad core i7 3.3ghz (8gb ram, intel 550)
vs a
6core xeon 1620 3.5ghz (64gb ram, 1070)
and it’s very similar in terms of fps, no huge improvements on the faster systems.
I thought it’d be cool to make en edit mode benchmark but with performance gains being pretty minimal across these systems I guess it’s better to wait for some investigation on the performance regressions ticket.
Hi, I read some time ago, no idea where, simple objects are not very good to test subdivide performance. May you have a human body mesh to test with.
I will check on Intel HD 4000 and GTX 760 if I find some time.
Did you test with an animation or moving mesh around?
Cheers, mib
No, I was mostly interested in editing performance.
(to clarify, subdiv was applied, I just wanted to get an easy to create consistent high poly object as I don’t have access to the same files from every workstation)
I guess open subdiv would do a great deal for anim, but I’m most of the time I’m modeling so not really following that one.
1 Like
The edit mesh performance it’s a know issues, bf will fix before the final b2.8 release
I saw that ticket about performance regression - I just found it interesting (I’m not a coder, this may be how things are everywhere) that single core clock speed seems to matter and not much else. Number of cores or gpu don’t really seem to make a big difference.
Anyhow, fingers crossed we get some speed increase.
2 Likes
On the dev’s High Priority TODO list for the next two weeks:
https://developer.blender.org/maniphest/project/2/type/To%20Do/query/LVuBeJukZpzX/
are both Opensubdiv as well as the general Performance Regressions ticket, so with a little luck we should see improvement soon.
Everything on that list is supposed to be complete in two weeks (or at least that’s the goal).
6 Likes
Clement continues with his focus on performance, with reductions in the time needed for an element in editmode to be selected.
https://developer.blender.org/rBc7767f1bcfd28ae3352b58a52eae2d63b4a22329
https://developer.blender.org/rB413ffd4606f52fe76a0a61f05582c086d37c3744
I’m hoping he’ll eventually get to where the draw engine is multi-threaded, that will be a nice boost when it occurs.
8 Likes
Single core ipc of those cpu’s(not counting clock difference) would be close enough it would be hard to notice much of a difference, even though there actually would be a miniscule one between the architecture generations.
The xeon is Sandy Bridge EP, the macbook would be skylake and the 9900k is coffee lake.
Note that the performance bottle neck in that test case would not be the gpu.
Thats right, mesh editing is not easily parallelizable. Though if under the hood the mesh were to be divided into multiple patches and operations would be queued in a job list of sorts that get applied to each patch respectively…
refactoring for something like that would probably be a huge job though.
2 Likes
I see, good to know. Thanks for the explanation!
Makes you think twice before investing a powerful workstation if you’re mostly modeling.
soon, very soon, if it is not already so, Blender will be taken as a reference point and benchmark to develop the new cpu and gpu
^ ______ ^
because it will be the only relevant software where engineers can study the source code and develop new ideas and steps to speed it up
I love this convergence that makes everything exponential.
the Singularity is Close… Ray Kurzweilg would say…
2 Likes
Such a nice news^^
1 Like
then having a viewport performance on edit mode similar to max -as an example- is technically impossible ?
I never said impossible…? Just difficult and laborious.
Just the fact that it is so efficient in Max proves that it is possible. Through how much effort though…?
I wish there was a way to donate for a specific subject like this.
3 Likes
Even if there was funding specifically for this, the real problem would remain. Is there an active developer with expertise in this willing to take the task on?
I’m talking about a developer not only with the skills to implement it, but one who is sufficiently familiar already with the current code base too. Though I suppose if a developer is willing to invest the time they can become familiar with the codebase as they work on it.