In the video description of new circular array modifier that someone (@alikendarfen) made and there is note:
Note (2018/05/09): that won’t be part of the 2.8 because there is a more long term strategy about “constructive modifiers”, for performance reasons.I’ve been informed of that two days ago.
Does anyone know what is that constructive modifiers strategy and what it would bring from user perspective? Only performance boost or maybe something more?
Although I am as sensitive as any software developer could be about the issue of code complexity, I’m reluctant to see existing features taken away from Blender when this “breaks” existing projects that are out there.
For instance, as I noted a little while ago, “Stride” simply vanished one day, because someone felt that there was a better way to move a walk-cycle along a path. And certainly, there is. But removing that feature broke several of my projects, which simply didn’t need too-close accuracy. “Stride” was simple, convenient, and good enough for my purposes in those projects, all of which “broke” when it was removed.
We’ll have similar backward-compatibility issues when Scenes are removed in the next release: what will quickly-and-easily replace them for existing projects? Will a script be provided? And, so on. There are people out here who are building assets in the existing systems. If you “break” something, even if “what you break it with” is arguably “better,” you still … “broke” something.
Scenes are still there in 2.8 …
With backward compatibility blender dev’s do their best to maintain it, at some point it’s not a big deal for users to stick to a working blender version until their project are finished .
It’s always sad when a feature is removed, but if it’s hard to maintain , it’s better for everyone that devs work on something new and better than to spend time maintain something that is not going to evolve that much.
With blender internal it’s obvious, many projects will broke , especially NPR ones where BI was still a very valid option. Now for these project, it’s better to stick to 2.79 or investigate if it’s worth to switch to Eevee.
These compatibilities issues append in every software including commercial ones. It’s sad but it’s also necessary when you’ve got limited resources.
From, that documentation, it just looks like a way to qualify modifiers from Generate category.
According to discussion on d.b.o, the author of the patch used instances system to produce that geometry.
And it looks like guideline for 2.8 is to use duplicators instead of modifiers for that type of work.
Everything in this video can already be accomplished by using current tools.
Screw modifier or array modifier using an Empty as origin or Dupliframes along a curve or a bevelled curve…
So, it is not a big loss.
Anyways, with “everything nodes” project, it will be easier to produce that with a nodes set-up less complicated than this modifier.
But wouldn’t duplicators approach prevent further modifications (like boolean, weld vertices, deform modificators, UV modifications) on mesh since there wouldn’t be unique data to perform operations on?
Everything in this video can already be accomplished by using current tools.
Yes, i know that there are workarounds. But they are not so easy/quick to set up and sometimes they just don’t work nice.
It is the case.
Currently, duplicators have to become real objects to do that.
So, probably current array modifier or particle instance modifiers are making a kind of conversion.
It probably adds a level of complexity in the support of such modifiers.
In context of nodetree editing, the step will probably be handled just by one or two nodes for all cases.
A modifier node will probably correspond to simplest operation possible.
The amount of combinations supported will define the amount of cases supported.
You will probably be able to create dozens of simple nodetrees corresponding to dozen of cases.
And each of these simple nodetrees made 4 or 5 connections will probably look simpler than this modifier with more of a dozen of buttons.
What will make circular array modifier performance more an issue than regular array ?
At some point performance could be an issue, but not being able to do things a far bigger one.
The BF has long been hesitant to add tons of new modifiers in general because the ultimate goal is to move the system over to being node-based (as part of the Everything Nodes project).
The BF even had the guy who did the animation nodes addon for a week (as part of the Code Quest) to get a start on it. There have been exceptions though for certain important features (such as Data Transfer).
C’mon everything node is as far goal (according bf) than - if ever - users will have to wait a decade, but what until then ?
The same goes with boolean, with carve removed and bmesh still in so bad shape than working cases are nearly edges ones.
I know Howard T and Ideasman are working hard on it, but until then be prepared to huuuge amount of users complains about issues while doing even simple cube operations.
This also means that every “hard ops” addons currently on the market will fail miserabily in a near future (2.8 release).
It is probably not so far. A prototype was already done.
What makes it a far target is simply that is a big task and basics of 2.8 have to be solid, first.
Currently, 2.8 is an alpha. Modifiers effects are not visible in edit mode. Libraries will be updated.
Many old features need to be restored. Many new features need to be completed.
For example, grease pencil have been merged and people already feels a lack about creation of repetitive actions.
2.8 is still crashing too much to have status of a beta.
So, even if you retire “everything nodes” from the equation, you will have months to wait to accept new modifiers.
Ideasman is not just working on boolean modifier. He will handle creation of all new manipulators stuff corresponding to 2.8 paradigm.
And there are huge projects that are waiting to be merged into 2.8 (fracture modifier, mantaflow, etc…)
So, how can you conclude that reviews of a circular array modifier that does not do something new should have priority in developers schedule ?
Do you really prefer insertion of a modifier that would be obsolete in two years or a refresh of Curve objects for the next decade ?
well actually in the last Blender Today Pablo said that Jacques Luckes ( the dev of animation nodes, and the one who made the prototype of particles system in nodes ) will start working in September ( or October ) at the Blender studio if i remember correctly
the 2 days per week is for interactive mode, and i think it’s only for Benoit, apparently Dalai Felento will also work on that, anyway, we will have some news about those project in September @07:35