I know that messages are free, but after see your messages in some threads… could be better to use one message and edit if you need. 
2 Likes
)))) Yes,))) I am too verbose))) sorry
keeping the conversation about @anon13094437 thread… if we pick a mesh and add a vertex color layer blender needs 100bytes only to add that to the mesh. Why is necessary add 100bytes for each vertex to add a data that only needs 6 bytes? maybe 12 bytes if the color is storage like float.
I looked in the sources, it seems you are right, and the coordinates are stored in float types (4 bytes each).
I did a little test with a mesh and when I add a vertex color blender ups 35MB for a 320k mesh. I suppose that part of that is that blender needs store the data two times when you are in edit mode.
Could be good that some day devs told us why edit mode is so slow, real reasons no “well, some things are not good implemented”. and if that memory problems are normal… because I’m not programmer, maybe is completely normal, but at least it appear excessive
1 Like
I, like others of you, we have constantly followed the evolution of the work of the UI of blender 2.80 (in some ways also struggled towards so that the best that there was from the old workflow interface, was maintained …) was a year very intense … and I am pleased to be an observant witness of this evolution and to see the fruits of this harvest.
Now it is true, we must look over the performance as it was done for the UI … because surely soon the biggest criticisms, now that the door “of the amateur” has broken through, the biggest complaints of discredit will arrive on this performance issue. …
I suspect that the competition will make advertising campaigns on this … as did Microsoft on Linux year ago… … …
a beginner’s question …
Do you believe that maths “tricks” can be used from “similar” compression algorithms to those used for video coders and decoders to obtain better “resolutions” and less resource consumption?
There are similar methods. But the problem is that now, for real-time editing, such an implementation will most likely increase the computational load, since encoding / decoding itself will require too much computational resources.
Such an approach would be good, for example, for sculpting, where the requirements for the program structure of the grid are different, and, theoretically, it is possible to pack the grid with compressed blocks, and to determine the specific operations of block editing of the grid.
In addition, I’m not sure, but glTF seems to use something similar for static storage of geometric data.
It would be interesting to know someone else’s opinion, more competent.
but maybe, hardware math accelerations already existing in the gpus could be used …
I have an instinct and a fervent imagination I hope they correspond to reality
The funny thing is that the UI look was revamped, but the code behind is still very bad. It’s so bad that they cannot add tabs to the panels, hence the only one editor possible per panel. So we need new core design but new UI code too actually. The next release are going to be very exiting.
1 Like
in the blender live stream where Ton was, he made a brief reflection on the UI elements that were too archaic at the code level … who knows, maybe in the next releases, now that there are resources, someone will work to modernize the core code of the UI elements …
but this, I believe, is a less urgent need at the moment …
there are more obvious priorities now …
I just found this here, very interesting:
https://code.blender.org/2019/07/accelerating-cycles-using-nvidia-rtx/
It’s not about the subject. We talk about optimization in the blender core. No new API/hardware that is better.
When/if the engine gets heavily optimized, would love to have the sculpt mode designed to support the same amount of polys as zBrush and get an advanced toolset, but it’s easier to ask than to do of course.
I mention that because as a pro working in a big VFX studio, I know that zBrush is the frustration of many generalists/even scultpers because it has never been made for Linux - and because its interface is a total joke (even for sculpters using it everyday). Blender could as well enter the pro industry and get love by being a good Linux compliant alternative sculpting solution.
2 Likes
Have you seen the sculpting branch?
I bet that the next release (2.81 2.82) will be more attractive to users, and the kernel will remain in the same ass as it is now.
The same story happened with the transition 2.49 - 2.5. Crowds of schoolchildren were happy that the new blender had become so beautiful.
The attractive 2.5 interface, Cycles, and tracking have attracted a bunch of users whose opinion has now spawned this new beautiful 2.8.
Sculpt branchs is only adding new features and revamp someparts of the sculpt core. Blender had a good perfomance in sculpt mode. Could be good see the ideas of @pablodp606 for edit poly core, but I don’t think that he will work in that, at least by now.
Pablo Dobarro talked a lot about improving the Mesh System in general in this Blender today episode - so I guess edit mode performance will also benefit.
Maybe i’m wrong, but I think that he talk about mesh in scculpt mode.
1 Like
Yes, I am talking about the ability for Blender to handle more data/better data through a new more effective design of geo core.
Currently, by having such a ineffective geo data management, Blender loose on the memory requirement, and on the performances (more data is more computation, and this is the cascade of issues that comes with it). A rework of this foundation will benefit Blender on almost every aspects (and sculpt mode would benefit this a lot indeed).
I think this is even bigger prio than cool projects like everything node (which I really am impatient to see).
2 Likes