A big community has different needs. The “more featurez” guys are important to push new possibilities, but most are more “players” than serious. But the other half, working professionally shouldn’t be neglected. For 18 releases (2.50 to 2.67) for the “more features” clan, we will have 2 release and then silence for many month/years. Please hear us
You may be in the same case as me, not seeking for new features but for a robust and flexible program to work professionally (a kind of RHEL for Blender).
Trying to really look for all the areas in blender which are time-hungry, we can split them in 2 categories : solvable with Python or not.
2.7x will go the route of instability, constant changes in API, UI, etc… 2.69 will be a companion for many professionals for maybe 2 years, and a great opportunity to finally develop a great addon database without the hassle of the twice a month update or broken add-ons.
For those 2 years that we have to live without upgrade, it would be nice to leave us with a good survival toolkit:
Replace hacks with proper functions :
For example, replace OpenGL hacks (like Pie menus do) with an easily editable PNG containing all icons, or allow several PNG for add-ons to ship with their icons. If every addon developer has to build it’s own Blender, it will be a mess (20 versions of Blender for 20 Addons ) and will give some security concerns as well (trustable ?)
Polishing of existing tools : Collada import, collada export, inset all those tools are nice, but half working. Have a standard compliant import export for collada, fix corner cases for inset (self intersection for example) like Howard did for bevel.
Optimisations and modularity :
OSL is really powerful (look at PYLA…), but unusable if you don’t have a 5000$ PC. Just adding a texture node in a scene makes it to render 5x slower than without OSL activated (without the texture being used by OSL).
Cycles was developed as an external renderer, would it be possible to have it to be updated separately (like Lux, Mitsuba, etc…) ? With all the SSE Optimisations coming, Opensubdiv instead of the old catmull-like solution, etc… It would be really unfair to force people to take nothing or everything. Or get a kind of backports system like RHEL ?
Allow Blender to have more objects ? That one may need big changes but a clear statement on feasibility would be great.
I know Devs have do their best and don’t like request. Hoping that making the icon file external/editable is not too hard. If you have some other Idea (realistic ones) about what would be useful for you to use 2.69 on the long term, maybe the devs will be kind and give us a solid release.
With all the planned changes and upgrades we are going to need a newer, and more sophisticated, “Endi”. This old one we have is so tired and clapped out. There is no way he can be optimized - he should be replaced. We need an “Endi 2.0” for Blender 2.7 and newer.
@davesf, thanks for the constructive answer @Andi, seriously you read my post as a feature request or you didn’t read at all ??? I’m speaking about replacing hacks in that case, just make a PNG easily editable. About optimization and finalization of available tools (like Howard did on this forum for his now very robust and stable bevel tool). The cycles-related thing may sound as a feature-request, but cycles was planned as an external render. I’m just asking if it could finally really become one. I thought you would be happy that we have 2 versions for us, but even then you continue your destructive posts !
Other examples of nice but not really usable features :
OSL (see OSL threads activity level to guess it’s usage in the community), very powerful, some really nice tools like PYLA. But unusable in the real world. Just activating it with a “image texture” node, and the render time are 5x that of without OSL. Only very reach people capable of buying render farms can afford that.
I’m not requesting anything, but I think we can speek about our needs and give good constructive feedback ! I hope Ton see our needs too. Only 2 release for us, please do them with us !
The biggest wall I have run into recently is Blender’s practical object count limit. While we can easily have thousands and even tens of thousands of particles in a single scene at once, I am running into a much lower practical object limit.
I have written an AddOn called RE:Array which makes unique objects for each element in a 2D grid array. So a simple array as small as 64x36 produces 2,304 objects. While the datablocks are instanced from a single mesh, the objects are unique. On top of that the script auto animates all objects and assigns drivers. In this example you would have 2,304 object, 2,304 fcurves and 2,304 drivers.
Blender becomes almost unusable on my 6 core 8Gb system with a valid GPU. Yet the scene only uses 64Mb of memory. they are just instanced cubes.
With the discovery of this severe limitation I have to realistically accept the fact that Blender is not as good as other professional apps that can easily handle 2,304 animated objects (C4D Mograph in particular on the same exact machine).
And lets not blame it on python. While python may have been used to generate the object the objects exist inside Blender as valid animated objects as if an end user had created them all by hand.
I don’t think we need anymore bells and whistles until Blender can fluidly handle thousands of animated and driven objects in a single scene.
Let’s see if I can phase this for google. Blender’s practical maximum object count is only 1,000 objects per scene. Adding more than 1,000 objects to a scene causes Blender to become unusable.
added your idea Atom. I really don’t know how to present it to the devs. They are flowed with request, on the other hand, we have nearly never polish and stability releases, and they can’t test all functions looking for “not properly working areas”, so they need our feedback to know where some polishing is needed. We Have 2 month and then nothing for us until 2.88 I guess. Would be bad to miss the comet
2.7x will go the route of instability, constant changes in API, UI, etc…
Disagree - for 2.4x we needed to rewrite API’s, but now there is really no need, I think you over estimate the breakages that will happen for 2.7x.
re: replace hacks, pie-menu is not apart of blender, its in testing and doesn’t come with releases.
so we never accepted this into blender propper, of course duplicating icons about like this is unacceptable. Just saying this hack is not in blender, so nothing to replace.
Why support collada? - opencollada development us just about at a standstill, at this point I would consider OpenCollada a failed project
Check activity: https://github.com/KhronosGroup/OpenCOLLADA/graphs/contributors
(yes, opencollada the library and the collada format are different, but neither seem to have been a success).
As for optimizations and supporting more objects - wont argue with those, however we have threaded depsgraph project and 2.7x plans to improve this area too, so - stay tuned
My original pie menu script was really just meant as a prototype for a C implementation but that never happened for various reasons – mostly because the UI menu code is very difficult to understand – and I found that the python version was Good Enough™ for what I needed it for so c’est la vie.
I’m not really sure what they’re doing with the icons these days but these opengl ‘hacks’ are in fact fully supported ‘features’ in blender, somewhat ironically the reason I ported over the 2.4x Image to gl buffer code was to test using a static image for a pie menu instead of generating it on the fly.
Unless I’m completely misunderstanding what you’re saying here and just want a way for addons to be able to add icons to blender proper and display in the UI as menu items and whatnot – which has been on my todo list for a while now but unfortunately I’m kind of lazy so…
So you can guarantee that we will not see so much add-ons die because of breakage ? We will be able to use Add-ons developed for 2.68 on 2.88 ? People can do codage effort today, knowing their work will not be useless for ever after 6 month and some real life changes ? @Uncle Entity too 2) Uncle Entity says the opposite about those GL icons, fact is that they sometime disappear. Anyway, I was meaning an easy way to use custom icons for addons devs yes. I hope Dev will get it for 2.69
I agree on Opencollada, but FBX is problematic because of license, Alembic is not supported either. We don’t have any good recent solution… I personally work a lot with Sketchup people, and Collada is the only reasonably working possibility. And i saw a lot of other thread and bug reports about other exporter/importer I’m not using.
Sometimes disappear? That’s obviously a bug but without a reproducible test case…
And I really wasn’t saying the opposite, no clue about the policy on including icons in the addons svn repo, all I was saying is the pie menu addon is using opengl in a way that is fully supported by the API.
Plus lack of python access to icons isn’t really a bug per se and if the next release cycle is going to be bug fixing only then it probably isn’t realistic to think something like this will be included.
I’d guarantee nothing, but from where we stand now - I cannot see a reason for large API changes,
Its my opinion that most API changes would be because of changes to Blenders internals (in that case the API normally follows).
Of course if we refactor materials for eg, Re-work - texface/blender-internal/cycles/nodes, split UV’s from per face images for eg,
(which we may do), scripts that touch with this data will probably need updating (not rewriting).
It’s just that we only have 2 releases without big changes. For some of us who concentrate more on producing with Blender than updating it / it’s add-ons or playing with all the latest features, it’s sometime a bit hard on the long term:
we can’t afford to have perpetually 70% of the add-ons working. On the one hand, the frequently updated one which don’t work on stable versions and the one updated all 2 versions or dead.
We can’t recode all dead add-ons but we need them (Automatic cycles nodes for converting BI materials after import for example, because all importers are style creating BI materials even with cycles official for more than a year and now default for many people)
Other solution is to have 3-4 versions of Blender installed with each it’s working add-ons, very inefficient, or to take a version and stay with, what I would like to do with 2.69. But to take such a decision, we would be happy to know we won’t have to see the unpolished things 2 years long, because they will make us mad after such a long time !!!
We know you do your best, sometime for free, but so do we. We build that community, develop some addons (still small in my case, but some of my code went into trunk after modification), speak about blender, answer on stackoverflow, showcase nice pictures, etc… and if you put all of that in hours of work, I would like to see how it compares to the coding time. Not to say we are more important, but we need each other and both work are essentials, producing and using.
We are not all whining every month about what we find bad and I try to solve most problems myself actually. But what some of us say more or less loud/often, it would be great if you could hear them at least 1 time every 2 years. Then I’m happy to see people make 3D explosions or falling water on youtube sometime.
