Both Vieport compositing work (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.74/UI) and new hair dynamics (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.74/Particles) started in Gooseberry and was later merged into master, as will Alembic stuff, most likely. That´s only the stuff I can think off the top of my head. So where development happened doesn´t always matter. Sure, there are things that won´t be merged, but so far, it´s been a very productive movieproject, developmentwise.
Blender 2.74 included several things from Gooseberry. Hair improvements, Cycles improvements, cavity masking, viewport AO/DoF, are examples off the top of my head. In contrast I can’t think of anything that Gooseberry has held back in master. Given how salty you are over it, I genuinely thought you’d at least have one example already in mind.
The targets for Gooseberry are mostly general improvements, so I don’t know what the point would be to segregate developers to eliminate that pesky 10% anyway. If Aligorith commits an animation editor improvement based on Gooseberry feedback, it seems like a good thing to me.
Gooseberry has like seven devs listed on the team, btw.
@BTolputt, not going to answer on all of your arguments (think this time is better spent on something else), but just regarding the 10% thing: If you want to get a real, meaningful percentage on how many commits were made to gooseberry from non-BI devs, you had to separate real feature commits from “Merge branch master into gooseberry” commits which take about 10 seconds and which are often made from non-BI devs. And still, this percentage would be rather meaningless, since a commit can be a one-line change or a thousand-line change.
Note: At this state I’d propose to split the discussion into 2 separate threads again as most of the discussion here is off-topic.
My fear is viewport FX following the bmesh way (done after too long delays, full of stressful waiting)
I cannot stress more how a stronger viewport is a must have for blender and how all users will benefit (sculptors, poly modellers, animators etc.). I think is a priority, more than other project.
This is kind of an empty argument. How many Blender developers solely work on anything? Most of them work in a lot of different areas on Blender (an impressive feat in its own right). Sure some devs have certain segments of the code that they’re more comfortable with than others, but even module owners make significant contributions outside of their area. This isn’t a Gooseberry thing. It’s an overall development manpower thing. We’d have it with or without Gooseberry.
And a separate note: Something that isn’t acknowledged enough is on the softer, less immediately tangible benefits our developers get from open projects like Gooseberry. There’s incredible value in seeing how the software gets used in the field. Cycles is a testament to that. Improvements to the motion tracker are as well. So are a myriad of other Blender developments that came to bear after an open project, but was informed by successes and failures during the project. You think that when hair is finally redesigned/refactored, the decisions about that design aren’t going to be more wisely informed by experiences had at the BI? Same with the viewport, animation tools, and so on. Many FOSS developers don’t get the luxury of long-term contact in the same room with other people using the software in their day-to-day. That experience is of unquantifiable value.
Is Gooseberry slowing down development in some parts of Blender in the near term? It’s hard to say definitively. Most of our developers don’t seem to think so… certainly none have stated that much explicitly. Will Gooseberry be an overall boon for Blender development in the general case? The current level of commits (on all branches) and the track record from previous open projects indicate that’s nearly a certainty.
Our benevolent dictator has heard our cries for help,
viewport project just got its own mail list,
Thanks Ton!
Here’s the link
http://lists.blender.org/mailman/listinfo/bf-viewport
And no, it wasn’t because of this thread. This the result of a recent Sunday Meeting that touched on the topic of viewport rewrite planning issues.
Also, it would be advisable to anyone here to not swamp it with feature requests right of the gate, its main purpose is for putting a cohesive plan together so they can get it done in a proper fashion.
So now we have an expected ETA for this? Maybe on 2.76/2.77 release?
you guys want an ETA, while there is not even a design document completed.
Give blender devs a break. 
Don’t know if you guys have seen it…
Mike Erwin has posted some updates on better viewport drawing of objects…
looks good…check it out…
Both Viewport and OSD have been given the backburner treatment during Gooseberry. SSAO and DoF are nice, but are candy when what is needed is a meal. They were relatively easy to add on top of the existing system, but the real changes that need to happen are going to take a total rewrite of most of the drawing code in Blender. Remember, everything including the panels/properties/text/etc. is written to be compliant with old OpenGL. On certain platforms (mainly OSX), you simply cannot mix newer profiles with old ones. Last time I asked, I was told that EVERYTHING will have to be rewritten, and will most likely be brought up to 3.2 spec.
Antony has mentioned to me that he’d like to do more viewport work (as that was originally what he signed on for, along with Mike Erwin) but got put on “general making the Gooseberry team happy” duty. And Ton seems to think that OSD would be useless for Gooseberry production (which is beyond my reasoning, considering that it exists solely to accelerate production animation pipelines, but I’m not up for having that argument with him again…). Sergey is also stuck in Gooseberry/general fixing mode, preventing him from working much on it anyway. So, while I don’t think it’s the end of the world, Gooseberry certainly is sucking time away from talented devs for the sake of working on some things that, in their own words, either will probably not make it to master because the underlying systems are too broken, or will require rewrites in the near future anyway.I’m all for Gooseberry, and hope it’s a success, but I’ve personally lost a lot of the goodwill I originally had for it. It would have been nice to have seen a lot of these big projects tackled prior to the next Blender movie. But at the same time I realize that Gooseberry is Ton’s baby, and that once that ball got rolling it wasn’t going to stop.
Are they still 2015 targets though (after Gooseberry ends), what is the timeframe between the first segment of Gooseberry and the second one? Otherwise Ton will have to explain why he himself mentioned them as targets on the Blender website.
By the way, Mike Erwin’s experiments look amazing, I really hope Psy-Fi can soon join in on the project.
In what context have you been told that? To my understanding, a large part of the work in the Viewport FX project was to create an abstraction layer so that everything doesn’t have to be rewritten. There’s also libraries like regal that emulate fixed-function OpenGL on a core profile. I don’t think it’s particularly beneficial to rewrite things that are not performance sensitive.
The conversation went something like “I remember someone mentioning a while back that UI stuff won’t be able to coexist nicely with viewport updates on some platforms, will everything need to be rewritten to get things properly updated” and the response was “Yep, all of it”.
EDIT: Dug up the logs.
1:56:43 PM mattheimlich_dt as I understand it OSX in particular is a problem in that respect
1:56:54 PM mattheimlich_dt mixing old and new I mean
1:57:02 PM psy-fi Yes
1:57:15 PM psy-fi Their drivers even have code paths that are buggy
1:57:31 PM psy-fi because they had certain use cases in mind only
1:57:57 PM psy-fi so doing OGL 2.1 + extensions for GL 3 can cause some issues
1:58:12 PM psy-fi unless you use 2.1 in 3.x way
1:58:20 PM psy-fi which is what we want to do anyway
1:58:40 PM mattheimlich_dt an GL 4 extensions will be needed for OpenSubdiv tessellation and displacement eventually as well, yes?
1:58:50 PM psy-fi Not sure
1:58:58 PM psy-fi ask sergey for details there
1:59:12 PM psy-fi generally if we have 3.2 working, then 4.x is not an issue
1:59:15 PM mattheimlich_dt at least, I haven’t seen anyone else supporting it without requiring DX11 or 4.0 compat
1:59:48 PM psy-fi 4.x has backwards compatibility with the 3.x versions
2:00:12 PM psy-fi they only broke things between 3.2 and 2.1
2:00:32 PM psy-fi And not exactly broke
2:00:46 PM psy-fi They can be compatible but you have to avoid certain things in the code
2:00:51 PM psy-fi Anyway
2:00:57 PM mattheimlich_dt what would requiring 3.2+ make easier?
2:01:30 PM psy-fi A lot of things
2:01:34 PM psy-fi geometry shading
2:01:38 PM psy-fi better shading language
2:01:43 PM psy-fi texture operations
2:01:46 PM psy-fi integer support
2:01:51 PM psy-fi multisampling
2:02:26 PM mattheimlich_dt any particular reason we don’t just jump on that? From the community polls it’s less than 5% of users who aren’t 3.2 compatible.
2:02:51 PM mattheimlich_dt and old Blender isn’t going anywhere
2:04:06 PM psy-fi No, I think we’ll jump to 3.2 after all
2:04:21 PM psy-fi By the time it’s ready we should be able to do it
2:04:36 PM psy-fi but that’s really of no concern to the average user
2:04:36 PM mattheimlich_dt would get rid of OSX woes too right?
2:04:41 PM psy-fi it’s just marketing
2:05:03 PM psy-fi woes can only be avoided by testing
2:05:09 PM psy-fi each driver has its own quirks
2:05:38 PM mattheimlich_dt I remember seeing that a lot of the actual interface relies heavily on the old immediate mode stuff, will that all have to be redone as well, or can that be separated out?
2:05:43 PM psy-fi Some of my days are like switching between two or three machines to make sure shaders work nicely everywhere
2:05:53 PM psy-fi and it’s going to get worse if we do everything with shaders
2:06:06 PM psy-fi No, all has to be redone
2:06:46 PM psy-fi anyways
2:06:47 PM mattheimlich_dt big job! Hopefully some time frees itself up after Gooseberry
2:07:02 PM psy-fi It will for sure
What are some things that probably won’t make it to master?
If all of this is needed just to keep Blender running on OSX, then I think Beerbaron has a point. Pull support for the platform and see if Apple cares about losing the entire creative market (because it’s all about mobile to them now).
What are some things that probably won’t make it to master?
I thought the Alembic work at least looked pretty sound because it was being done properly rather than shoehorned into the existing cache system (as originally planned)? That’s a big chunk right there.
Well, thanks for that. I guess “redone” either means the entire UI code is going to have a rewrite (big task), or he’s referring to mostly replacing explicit OpenGL calls with abstraction layer calls (which is less work but likely error-prone).
So, either I misunderstand the original Viewport FX intentions, or they’ve they changed their mind about their approach.
I didn’t argue for that. “All this” (moving to the Core Profile) is also necessary to bring Blender to mobile platforms and other ARM devices (raspberry Pi etc). You can only expect the Compatibility Profile on Windows and (most) Linux drivers. Supposedly, moving to the Core Profile could also bring better performance and stability, although I have never seen that claim substantiated in practice.
BPR; Why didn’t you just tell us at the beginning that this was to be another request thread for the BGE, we could’ve had most of the discussion in a different thread then (because I thought it was about the initiative to rewrite the viewport)?
Ace, it’s all related, and take a breath man.
U2 serious.