Static override won't make it to Blender 2.80

Bastien Montagne commited his work on static override, unfortunately it won’t be officially part of Blender 2.80 as it is not ready yet, BUT you can try it by enabling --enable-static-override at startup :slight_smile:

https://developer.blender.org/rBfbf4c11960db62a27876e1d791d3293071e26c76

It’s a bit sad to see it postponed, but maybe it’s more clear like this…
As anyone tried it ? is it still possible to use them on some case or it’s too WIP to be useful at all yet ?

Before anyone excoriates the devs. over this decision, keep in mind that the commit does not remove any code related to static overrides, but merely hides it until it’s considered production ready. It will even keep your current static overrides in place if you’re already making use of it.

Still a bit of a bum deal to not see it officially supported for the 2.8 beta, but the todo list is quite long and it is keeping Bastien from doing much work on it.

3 Likes

Only in beta or also in the final official blender 2.8?

Hum, if beta means polishing / bugfix before release, maybe this won’t make into 2.8 official.
I’d like to have a bit of feedback on how it’s usable … If I understand correctly static override is a replacement for armature proxy , but this also apply to any kind of data (nodes inside a material, modifiers ? ) so I’d like to know if anyone has tested them ?

Yep beta means feature complete, mainly bugfixing. A bit tedious, since indeed 2.8 was meant to replace the proxy system which is still good, but has many limitations. That means static overrides won’t be released before 2.81, so we probably have to wait one more year or so… this will certainly affect some animations studios that had planned to switch to Blender 2.8 (currently using Maya) because of this.

1 Like

I honestly didn’t really expect it to be in 2.8 at this point. Better focus on making 2.8 with the existing features stable and include it in 2.81 or 2.82. And @lucky - judging from the release dates of 2.7x, we won’t have to wait another year for 2.81 once 2.8 is out.

I don’t like this rush for beta.
They can’t have a feature complete 2.8 in time. Just don’t publish a beta.
What is the point to publish a beta about half of workflow in 2.8.

I sincerely don’t think that big holes in 2.8 workflow will be filled before 2 months.
If beta is postponed to Christmas , things could go smoothly.

Now, we are running for a beta with missing features that will be named 2.80 (who was supposed to be a stable release). So, again, that will be confusion everywhere just to satisfy sponsors that don’t care if 2.80 will be a good release or not; but just want something to attach their name on before the end of the year.

Naming was clear for alphas but for betas : it should be stupid.
Sincerely they could not name it 2.8 beta 1. Or release a 2.8 alpha 3 for blender conference.

They may make a reliable release for 2.85 or 2.84. That will be a better score than 2.57. But that is not more serious.

4 Likes

Hm, You are not the only who is feeling like things are not going the way it was :frowning:

1 Like

@Stuntkoala Well we’re going a bit out of the main topic, that’s right 2.7x releases were more frequent, 3-6 months on average. But that was for 2.7x series, while 2.8x versions are a technical leap away from it. More features = more bugs. Of course i’m not 100 percent sure, but I expect that making it stable will probably take twice the time necessary for 2.7x versions, at least for the first versions (2.81, 2.82…).

1 Like

Well, the BF have been missing targets constantly since the 2.4x days, but it doesn’t mean features won’t ever make it in. I understand the desire to get 2.8 into people’s hands as quickly as possible when noting the nearly year-long wait, especially since they indicated that it is only the first in what appears to be a planned 2.8x series.

In addition it’s been proven before that longer release cycles don’t always mean a more stable and bugfree release. It’s also been shown that the lack of static overrides initially will not make 2.8 unusable for all cases as already seen with 2.79.

Could somebody explain what static override is what it is good for?

@lucky Roger that :wink:

@Lumpengnom This should be helpful: https://developer.blender.org/T53500 and this: https://www.youtube.com/watch?v=X_-cKpV6Reg

1 Like

Did I talk about asset engine branch ?

I am not talking about making a bugfree 2.80 or being just disappointed to see a feature reported to a next release.

I am talking about consistency of workflow in future release.
Renderlayers and collections are organized the way they are in 2.8 to work with overrides.
Do you remember first Dalai’s videos about 2.8 viewport ?

Linking, Compositing, simply Scene Management will be a pain in the ass in 2.80 without overrides.
The fact that BI artists are suffering to make 2.8 usable doe not mean that other blender users are masochists.:stuck_out_tongue_closed_eyes:
There is no problem to have everything nodes or not all active tools in 2.80. For, those cases, it don’t make 2.80 worst than 2.79.
But overrides were supposed to fix what is really painful and not reliable in 2.79 data management.
And they should compensate the lost of layers bits.

Making an effort to clean bugs from renderlayers and collections system with a part hidden to user for 2.80 beta to redo same thing, months later when feature will be revealed. That’s what I call a waste of time.

1 Like

As far as I can see noone said static overrides won’t be in 2.80, Bastien only said:

That feature will not be ready (or at least, not tested enough) to be officially part of 2.80 beta

Keep calm (and use the command line option if you need static overrides right now)

3 Likes

Here is the Roadmap:
https://en.blender.org/index.php/Dev:2.8/Source/Assets_and_Static_Overrides/Roadmap_October_2017

Edit:
Oh wait. Is October 2017?
Anyway… I trust that Bastien can finish the work on time, best wishes for the project! :slight_smile:

1 Like

That feature is supposed to handle complex scenes.
That would not make sense to avoid or hide it in beta-testing phase and make it happen in final release.

Hiding stuff and making feature accessible through a command line that makes sense with alpha. Like it was the case for COW.

If they were coherent, they would continue alpha phase.

To me it makes perfect sense to hide it if it’s not ready for public consumption. There’s no use in having a bug tracker swamped with redundant “overrides don’t work” or “Blender 2.80 sucks because it broke my scene” reports.
If you know what you’re doing or are willing to beta-test you can always enable it with a command line option. They didn’t remove the code.

I am OK with that. I am just against the idea to open bugtracker and send bugreports.
If there is an override accidentally added to start-up.blend causing a bug, people will send bugreports without having any clue what’s going on. That’s not better.

If someone without further knowledge of static overrides manages to accidentally link a file and apply a static override (which is now only possible with the command line option active in the first place) and save this as a startup file, hats off!

Maybe there should be a badge added for people who can achieve that :wink:

1 Like