Here are the notes from today's meeting in irc.freenode.net #blendercoders.
1) Upcoming 2.76 release
- We are mostly on track, but the Bug Tracker needs more love (150 open reports at the moment). Everyone is welcome to help out here.
- Bastien Montagne intends to merge his file browser work next week.
- Kévin Dietrich gives status update on OpenVDB Might not make it into 2.76. work : It is still pending review and needs a decision on library updates.
2) Current projects
Lukas Stockner keeps working on improved Cycles Portals.
For people who haven't read it yet, these are the plans for the Blender 2.8x project.
Meeting was short, people are having fun at SIGGRAPH I guess. :)
Also, don't forget about the Cosmos Laundromat online premiere tomorrow!
48 Comments
Well, the Blender 2.8 project sucks. :( We were fixing to get Ptex, OpenVDB and others and now it looks like it will be a year from now.
I'm sorry, but you're dead wrong here. For once, I'd say they're on the right track.
Ptex is dandy and all, but it hasn't really taken off as we all thought five years ago, and today, it's not really used much in industry. Even if it finds better place within industry pipeline eventually, for now, it can afford to be placed lower in priority.
OpenVDB is used mostly in major feature films (people with cutting-edge rendering farms that pretty much nobody else has), and while I'm sure smaller guys can find use for it, it's still is a bit beyond the scope of most Blender users, so it too can wait a bit longer.
Again, just speaking in terms of project priority here. With so many projects, but so few developers and limited resources, one has to prioritize.
What CAN'T wait, however, are things that have been waiting far too long in Blender:
• UI work: wrap up Python configurability project, make Workflow based configuring possible
• Viewport project, including a PBR quality engine/editor that could replace BI and GE render.
• A better designed integration of physics simulation in Blender
• Asset managing and browsing, linking, references, external files in general.
• Integration in non Blender pipelines.
And since they started it, they might as well finish the meatiest initiative set out by Project Gooseberry:
• Don’t add the half finished Gooseberry targets but take the time needed to code it well: Particle nodes, hair nodes, simulation nodes, modifier nodes…
Blender has long needed tighter internal integration and better integration with industry pipelines. As Blender grows more and more, these simply just can't wait anymore.
And in terms of new features, it's better to focus on features that are industry-relevant now (PBR viewports, customizable UI, asset management), rather than the doodads that the hobbyists want (Ptex, OpenVDB) more than the needs of the working Blender professional.
That is, if Blender wants to get even more serious about becoming a viable name in industry pipeline. This kind of professional focus will actually HELP towards the community's wishlist.
A better undo system is really needed too. I can't see many professional studios using Blender if the undo breaks every time they hit the tab key.
@Joe S.:
Yep, exactly. It's such little things--or seemingly little things--as that which we've been missing in Blender for so long, that have really added up over the years. A better Undo system. Editing-persistent modifiers. Customizable UI. Etc.
+1 for that. Not a fan of having to save before I undo incase it crashes. Try mashing the undo button to undo a load of changes and you no-doubt know what I'm on about...
@Brian Lockett I agree about Ptex, but OpenVDB is something important, because its a better way to import simulations from other softwares such as Houdini, Realflow... :D
Again, just speaking averages here, how many Blender users will be importing simulations from other software like Houdini and RealFlow anytime soon? Though, I'm not saying that OpenVDB isn't important. Heck, I like OpenVDB.
I'm saying that, because so relatively few Blender users will even utilize OpenVDB the way a bigger company will (you know, someone with a LOT of computer power to process the processor-heavy simulations that Houdini and RealFlow specialize in), it can afford to be postponed in priority.
Besides, Houdini and RealFlow are highly-specialized software. If you're working at a studio that's using Houdini and RealFlow, chances are, they're using other industry-pipeline software, too. Not many people own Houdini and RealFlow at home.
And think of it this way: What's the point in adding OpenVDB to Blender if Blender still stutters and crashes with million-poly meshes? ;)
Better to stabilize Blender first, polish it up internally, and focus on the more immediate issues first, THEN you'll have room for niceties like OpenVDB.
Actually, the point might be to identify the pain points with actual user data, and usage, not just test cases that come from other programs. So, you can see how it reacts not just in loading the files, but also in use in Blender when artist are actually modifying the data to suit their purposes.
This would help inform the structure they need for the internal data format efficiencies, rather than something that is implemented and then needs to immediately change after being polished for the big one year release.
Not sure if OpenVDB would be such a niche/un-used feature. I'm thinking it would be very useful for caching simulations. Users won't know they're specifically using OpenVDB, they'll just notice that the cache size has gone down from 10GB to 1GB, which, in turn, would be very handy on the rendering side of things, no doubt giving speed improvements and possibly even making such scenes renderable on the GPU... All big things from what I can see...
I generally agree with what you're saying though, focus on getting the core of Blender up to scratch, then add the bells and whistles afterwards.
"• UI work: wrap up Python configurability project, make Workflow based configuring possible
• Viewport project, including a PBR quality engine/editor that could replace BI and GE render.
• A better designed integration of physics simulation in Blender
• Asset managing and browsing, linking, references, external files in general.
• Integration in non Blender pipelines."
Agreed on this, all very good suggestions for areas of focus for Blender.
But above all, what personally I feel could make the biggest difference for how Blender is seen professionally is asset management. I use Blender professionally and my job involves maintaining a stock library of 3D assets I've had to create and reusing them regularly for renders. About 10% of my job is 3D modelling, the other 90% is importing 3D models and arranging them, so any time which can be saved in this area will have a huge effect on my workflow overall.
The 3D models I've created over the last 2 years have been catalogued and stored in an organised folder structure by type, multiple variations are stored, there are blend files with just different material options and whatnot. Each product has many many different options and can be used in a large number of ways, there's no way you could create an automated system which would cover all the ways in which they could be put together to create a finished product, and every finished product is customised.
In the office I work in, everything is high pressure and fast paced, there's no 2 week deadline, sometimes I'm lucky to have 2 hours to pull something together, and occasionally as low as 20 or 30 minutes. Speed is critical and the faster I can go from combining existing assets to hitting 'Render', the better. It's about giving previews to customers of something before they order it, and the customers we have here are all corporate types with low tolerance for delays.
So for me personally, the smoother the system can be for quickly dropping assets into a scene to do a render, the better!
For me a dream come true would be some kind of "Configurable Asset" feature, where I can create an object that has predefined variables (like how a node group can act like a custom node) that control the object's appearance/shape/etc.
I've half done this so far by creating assets which have modifiers and shape keys to change dimensions and number of repeating sections, and other such things. This works well in some objects and allows me to just drop something in, change some numbers and get a customised asset quickly. It can be time consuming setting this up once, but the time it saves me during the course of a day makes it worth it, every time.
What would be nice is a more streamlined workflow in this area. Some kind of 'variables' tab for objects or mesh data. Where you can create variables such as a material variable, which could have a range of preselected materials to choose from, or a numeric variable, which could be used in shaders, modifiers, constraints, etc. Maybe preset configuration for hiding and showing different vertex groups, so you can have multiple variations of the same thing available, and not have to totally redo all the customising for the object just to change from type A to type B.
I know I can fudge 60% of this already with shapekeys, drivers, and just changing properties of modifiers/shaders myself, keeping my materials list organised, etc, but an official system for this could save me valuable time and make life very easy.
I'd pass up further performance optimizations and modelling features and other stuff for a system like that.
I'm in exactly the same situation: a big library of company products/assets in separate blend files, all of which use the same linked materials in a separate materials library file. My biggest annoyances are:
1) If I do a traditional Ctrl+C copy from one instance of Blender, and paste the object into another instance of Blender, the object loses its link to the materials library, even though that material is already pre-linked and available in my new file. If the object has several materials, I have to manually reapply all the materials to use the linked library versions. Only by Appending items to my scene can I be sure the materials remain linked, but then that frequently means appending the wrong item because...
2) ...when I Append an object, the browser cannot show thumbnails of the individual objects in the selected blend file, which seems a bit daft.
Do you ever use DAZ Studio?
I would generally agree with you, but I have a few issues. First, Ptex support is supposed to be all but done in the initial implementation. And it has been a target for the last 3 releases, at least. If all they were needing were time to finish up, then extending it for the next release 3 times should have been enough, unless the work is simply bigger than they thought, and they have to change their plan. Which means they aren't very good at judging how long these features are going to take.
Also, they are talking about some radical changes to the display system, something that will directly affect the Ptex implementation. If they don't get it in before they head for the 2.8x release cycle, they may have to start almost from scratch. And I noticed Ptex didn't get much attention.
And I don't really care about industry standards for my own use case, I do care about convience. And Ptex could be a major convenience for my own workflow, and could convince me to switch from Mudbox to Blender almost full time.
And Ptex is just a poster child for several features like this. This is my concern, that all the work they have been doing to get this stuff ready is going to be invalidated. Not to mention it will be a year that we will be stuck with the current pain points.
Such as FBX issues with animations that still don't work well with UE4 and others, which you may have noticed weren't really talked about.
So in theory this stuff all sounds good, but in practice I think they need to get these features they have been promising for the short term into a release before they start working on all the experimental things that they tested for Cosmos' Laundry Mat. Its not a bad idea, but the timing is wrong.
I get your point, but I'd still say, Why put fancy gold rims on the car, if the car's engine is long overdue for a tune-up?
If Ptex isn't all that relevant or prevalent in industry right now, and there are some issues in Blender that are a decade old now, what's the point in delaying those other long-awaiting issues, for a feature that, frankly, isn't all that urgent to have right now?
I do understand your sentiments of following through with the swing. But sometimes, it's better to stop mid-swing and adjust for another swing, rather than sending the golf ball off with a bad shot.
But yeah, as a UE4 game developer myself, I most certainly feel you on the FBX issues with animations not working well with UE4. I use Maya LT with my game dev, just because I simply can't wait on Blender development.
I would also like to point out that Blender users are used to half baked solutions and can work around any issues that arise while we wait for fixes. We can't even use the tools, or experiment with how we would like for it to work if it isn't in a build.
But now that I think about it, this just means I will probably switch to using alpha builds rather than release builds for a while. :(
@BILLDSTRONG
Unfortunately, that's my plight with Blender. Workarounds are time-consuming, inefficient, patience-testing, and often times, with results not as good as a solid solution would provide.
And many times, solutions get left as half-baked simply because new initiatives pile on before finishing out older ones. Bug fixes are frequent, but actual improvements are infrequent.
So, Blender starts to suffer on two ends: Struggling with adding new features and struggling with improving old ones.
Modifier nodes - I am getting wet dreams!
I am curious how long it might take to arrive
Lol - "future Blender sucks, coz it'll have features that 'not-as-future' Blender won't have"
Wow, dude - just wow :-d
No, let's be clear, I am very much talking about the wait, not about the features. I agree and am excited about the features, but there is nothing new in the listed features, as all of them have been announced and written/blogged/talked about for at least the last 6 months. And I even agree they probably need to take that time to do many of those features.
I just don't agree that the features they have said were almost ready to be put in need to wait a year so they can all go in at once. This I find to be disingenuous.
The way I read Ton's recent post on the dev blog, the whole point of chilling on the new features right now. Is to re-group. Frankly, as exciting as it might be to have a new release of Blender every 2 months or so with cool new features, what's really been long overdue for some time is some fairly fundamental refactoring of the entire project. I'm talking for example about the dependency graph here, and to a slightly lesser extent, updating the base level of OpenGL support. You can't do this sort of deep core restructuring whilst you're constantly piling on new libraries and features every couple of months, all the while sitting on a pile of bugs that always seems to hover around 100-150 reported issues in the tracker - it's untenable. Every Blender user is going to have some pet new feature that they've been gagging to have implemented, that's going to make their lives so much easier, that they were promised, blah blah blah - openvdb, opensubdiv, ptex, whatever. I'm looking forward to all of it, make no mistake! But the BF have to care about the Whole Project, not just the latest shiny new library. And unless they start taking the time to refactor everything now, all of these cool new features are going to be sub-optimally smooshed into a code base that's already inadequate for future orderly expansion. If this comment thread is in anyway representational of the Blender community at large, I wouldn't blame Ton & Co for completely ignoring everyone in the 'community' for the next 12 months. Reading Ton's dev post again, it sounds like that's not a world away from what's going to happen. Very select input, by invitation only, from level-headed players.
Blender desperately needs a better undo system. Why isn't this a priority?
I've complained over the years about adding or improving this and that feature, but Ton and the rest of the Blender crew, have always surprised me and have created my favourite software, one that I love to use, and that has changed the industry for years to come, so I only have to say, congratulations to the Blender team and do whatever you think is better for improving Blender
I agree that we users can be quite demanding at times. I agree that Ton and the team are doing a great effort. I agree that Blender can be nice to use. I don't, however, see where you're coming from in saying they've "changed the industry for years to come,"
Just how, exactly? Blender's been an interesting concept, the best free option, and a curiosity that has seen some praise here and there, but nobody in the industry does anything differently thanks to Blender. If anything, I'd say that's still the promise of Blender still in waiting.
Blender's a good, useful tool, but if we're going to talk about industry here, we have to be a bit honest with ourselves here. We can't take things like the BIG community of Blender as sign of success in the industry--most of this community are not industry professionals.
The potential for industry success is there, but its current reality of industry success is much humbler. Thus why some of us are rooting for greater focus towards professional direction with Blender.
Though, like you, I do respect what Blender Foundation's doing overall. And it does seem that the team are starting to want some better industry focus with Blender.
Nicely said Brian. It's always nice to get a dose of well-reasoned perspective around here ;-)
What Blender lacks, that would boost its acceptance enormously,
is a focus on representing human(oid) figures:
mesh, rigging, textures, morphs.
Has Ton ever considered an earnest collaboration with the MakeHuman team?
How would that exactly boost its acceptance enormously?
Blender 2.4x used to implement MakeHuman inside Blender. I don't recall the world rushing in line to use Blender then.
And since there are dozens of ways to import humanoid figures into Blender (MakeHuman, DAZ 3D, ZBrush, free BadKing human models, etc.), I fail to see how exactly this will so drastically change Blender's fortunes.
Blender 2.4x used to implement MakeHuman inside Blender? Really?
And THEN what happened??
Are the people involved still on good terms?
Personally, I'd start banging my head on the desk if the Blender team wasted any more time on squidgy things like human figures and woolly sheep. All of us who use Blender for architecture, product visualisation, scientific and technical illustration couldn't care less about humanoid figures.
Hi Brian.
Well, I think your concept of industry is partial (or mine perhaps). of course it has changed nothing for Pixar, 20th Century Fox, EA or the like. but there are thousands of small companies, studios and individuals that have acces to a proffesional free 3d creation suite. I can do Archviz without spending 3000$ in software and thats a game changer for a lot of people.
blender may have it's flaws and things people can complain about but what software doesn't? or really what in general doesn't?
they've been doing a great job so far so it's easy for me to trust them to keep on doing a good job regardless of what they decide should/shouldn't be done next. i'm sure they'll keep doing a great job because that's just what they do.
I agree, but still, constructive criticism is what fosters improvement--esp. if community is the heart off the development. Open-source, open community.
Though, I don't think anyone's just focusing merely on Blender's flaws--just keeping perspective about where we are, and where we could head, with good opportunity to do so.
Blender does plenty good, and there's much to be grateful for, but it also has issues that have remained unaddressed, even since its first release.
The job of sincere, careful criticism is to help ensure improvements are not postponed for, oh, another 10 years.
OpenSubDiv: 3.0.2 built from Git on Debian.
Blender Player set to OFF in the build to clean up the errors.
Compiling OpenSubDiv Clang/LLVM 3.6.2 pumps this out to console:
../../lib/libbf_intern_opensubdiv.a(opensubdiv_capi.cc.o): In function `OpenSubdiv::v3_0_2::Osd::Mesh::Refine()':
/home/mdriftmeyer/Projects/Blender/blender/intern/opensubdiv/opensubdiv_capi.cc:(.text._ZN10OpenSubdiv6v3_0_23Osd4MeshINS1_17CpuGLVertexBufferENS0_3Far12StencilTableENS1_12OmpEvaluatorENS1_12GLPatchTableEvE6RefineEv[_ZN10OpenSubdiv6v3_0_23Osd4MeshINS1_17CpuGLVertexBufferENS0_3Far12StencilTableENS1_12OmpEvaluatorENS1_12GLPatchTableEvE6RefineEv]+0xa6): undefined reference to `OpenSubdiv::v3_0_2::Osd::OmpEvaluator::EvalStencils(float const*, OpenSubdiv::v3_0_2::Osd::BufferDescriptor const&, float*, OpenSubdiv::v3_0_2::Osd::BufferDescriptor const&, int const*, int const*, int const*, float const*, int, int)'
/home/mdriftmeyer/Projects/Blender/blender/intern/opensubdiv/opensubdiv_capi.cc:(.text._ZN10OpenSubdiv6v3_0_23Osd4MeshINS1_17CpuGLVertexBufferENS0_3Far12StencilTableENS1_12OmpEvaluatorENS1_12GLPatchTableEvE6RefineEv[_ZN10OpenSubdiv6v3_0_23Osd4MeshINS1_17CpuGLVertexBufferENS0_3Far12StencilTableENS1_12OmpEvaluatorENS1_12GLPatchTableEvE6RefineEv]+0x196): undefined reference to `OpenSubdiv::v3_0_2::Osd::OmpEvaluator::EvalStencils(float const*, OpenSubdiv::v3_0_2::Osd::BufferDescriptor const&, float*, OpenSubdiv::v3_0_2::Osd::BufferDescriptor const&, int const*, int const*, int const*, float const*, int, int)'
../../lib/libbf_intern_opensubdiv.a(opensubdiv_capi.cc.o): In function `OpenSubdiv::v3_0_2::Osd::Mesh::Synchronize()':
/home/mdriftmeyer/Projects/Blender/blender/intern/opensubdiv/opensubdiv_capi.cc:(.text._ZN10OpenSubdiv6v3_0_23Osd4MeshINS1_17CpuGLVertexBufferENS0_3Far12StencilTableENS1_12OmpEvaluatorENS1_12GLPatchTableEvE11SynchronizeEv[_ZN10OpenSubdiv6v3_0_23Osd4MeshINS1_17CpuGLVertexBufferENS0_3Far12StencilTableENS1_12OmpEvaluatorENS1_12GLPatchTableEvE11SynchronizeEv]+0x5): undefined reference to `OpenSubdiv::v3_0_2::Osd::OmpEvaluator::Synchronize(void*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
source/creator/CMakeFiles/blender.dir/build.make:310: recipe for target 'bin/blender' failed
make[2]: *** [bin/blender] Error 1
CMakeFiles/Makefile2:7061: recipe for target 'source/creator/CMakeFiles/blender.dir/all' failed
make[1]: *** [source/creator/CMakeFiles/blender.dir/all] Error 2
Makefile:146: recipe for target 'all' failed
make: *** [all] Error 2
Is this something I can control on my build of OpenSubDiv to fix, or is it a combination, or just blender?
Ever heard of bug tracker? Unlike news site its the one people are posting their bugs for devs to look at and yes, compiling bugs too.
The bug tracking system is a PITA if you want my opinion. Having gone that route and then being told earlier on OpenCL that compilation is not a bug only to find out the current branch they compile against is outdated for the public I'm not too impressed with their triage.
So finally PBR in 2.8, awesome :) ...... , 2.6 very soon and the premiere tomorrow, I really love Blender....
Lack of Alembic support, cycles shadow catcher shaders and multiple focal length (zoom) tracking are what I have seen hold back blender from being used in professional pipelines, but no, let's focus on viewpoint shaders and best of all game engine updates.
BGE is seldom used by anyone, and when it is its only for minor projects, testing, and hobbyist learning. Wouldn't it be better to let people who want to learn, learn on other freely available software like unity or UE?
Focus on Blenders integration with other software, not relics like BGE.
Unity and UE4 are proprietary software not "libre software", bad idea using them for science projects (maybe good idea for games) and only UE4 works on GNU/linux.
Ok, I understand that stance with Unity, but why UE4? The source is open, though it isn't libre, and it doesn't have a cost for the education community. It also doesn't have a cost for open games, or free games, nor for Architectural Visualization or film projects.
And its plugin architecture allows you to develop open source licensed plugins. You can even modify the Engine itself for your purposes, and post changes for others to use in commercial projects, without having to pay a dime, as the onus is on the commercial project.
If you are working on a commercial project, then you probably weren't looking at Blender anyway.
A lot of other industry professionals don't know how fast Blenders motion tracker is.
In film, often we are asked to track almost untrackable shots. Sometimes without focal length, film back and distortion grids. What makes 3de so great is its parameter adjustment editor (neat graphed lens solving). On easier shots syntheyes is great for its speed. I'd love to be able to incorporate blender into the pipeline, but it is still lacking important features.
For smaller projects I'd love to simulate in real flow, animate in maya, and render in cycles. Just look at Arma studio's coke advertisement work recently featured on CG society. Some really great work, shows off cycles too, but the poor people had to hand key frame the visibility of meshes exported from real flow because they couldn't properly import the mesh cache. For every damn frame.
They are trying to factor the game engine stuff to be usable in Blender proper, this I can agree with. Also, PBR has hit the industry by storm so focusing on that to keep afloat with all the other DCCs is important, especially since the game industry has adopted in in every current gen Engine.
Lack of Alembic support, Ptex and other things that have been just on the horizon are indeed holding back this software. But the viewport stuff is important if they want to make things like sculpting performance and competitive with the other DCC applications. And it will also help with your Cycles viewport accuracy.
Why do you assume that Alembic support isn't in their plans? They listed "Integration in non-Blender pipelines"--that could very well mean focusing on Alembic support. Seems like the FASTEST way towards such means, if you ask me, but we'll have to wait for further details there.
Also, viewport shaders (as in real-time PBR viewports) is something you don't want to fall behind on in adopting. It's becoming standard now across industry. Just about everyone and their mom have PBR viewports now. It's time.
Hm complete rewrites while keeping general functionality. Might fail too. I've seen it happen to other code projects.
Code evolves with reasons sometimes they are forgotten in the the new code project. And you end up reinventing everything bug tracking everything new bugs etc.
In essence windows 10 is just evolved improved Windows NT 3.51 marketing made all versions new products but in between versions most code was reused and with more bug fixing
Perhaps go on with 2.7x series but tackle the hard parts replace BI for a bpr render.
Dedicate more time to bullit engine. And keep improving cycles and render speed.
... i was just thinking...
if i could get people to critique my artwork like they do things like this i'd be the best artist ever.
http://daedaljs.deviantart.com/gallery/ if you want to have a go and tear me a new one.
Join Polycount and post your work there.
http://www.polycount.com/
No offense to DA, but deviantART is not the ideal hub for exposing your art for critiques.
You'll get more friendly praise from other deviantARTISTS than you will constructive criticism from folks a lot more serious about taking their art to the next level.
Plus, the learning resources available at Polycount are invaluable.
not sure why you thought you needed to say no offense to DA for that... it's kind of obvious.
is polycount good for 2d stuff too? i do more 2d work than 3d work.