For those unfamiliar with Blender's versioning, the major number is effectively meaningless. The 8 is effectively the major number and the 2 the minor.
Anyway the big items in this release IMHO are:
- preliminary support for the Pixar USD format ( https://graphics.pixar.com/usd/docs/index.html ) which is gaining large traction in film studios, gradually in game engines and is the format of choice for Apple's AR ecosystem
The combination of both which means that Blender will be easier to integrate in existing pipelines rather than being a very interesting curiosity for large studios with preexisting pipelines.
Blender is certainly very powerful, and with the 2.8x releases, I think they're really opening up appeal to a larger set of artists and studios.
Just recently been talking to some large studios that are actively considering adding it to their toolset.
I don't sculpt much anymore but from talking to people who do it seems like zbrush is still more performant with better tools for sketching out ideas as well but with blender you get the convenience of not having to jump between applications.
The grease pencil has been around for longer than 2.8, but it got some serious love recently. The Blender Institute even made a 2D movie with it (Hero) as a showcase for the improvements.
Zbrush is it’s own thing. Nearly all 3D package can (and have) produced the equivalent. What you have with Zbrush is another way of looking at how to do 3D illustration and as a side effect 3D sculpting.
So, blender was on par already for quite a while. And since the version 2.8, it seems that they’re more than on par with the rest of the industry.
Honnestly, it's mostly the UI revamp that put Blender up to big gun: a familiar interface mean that every artist trained on other software can "easily" transfer. Sculpting improvement, are, well, an open discussion. Poly modelling with subdiv is still better in Mirai, a software dead for nearly 20 year now for example, and lot of artist using nurbs still miss Softimage 3D 4.
Thanks for pointing these out; I've avoided using Blender for sculpting for a long time since the performance wasn't even close to ZBrush and it didn't have equivalents for Dynamesh/ZRemesher. Maybe it's time for another look.
I have used it for minor sculpting jobs, and found it very agreeable. A bit buggy in the version I was using (problems with updating previews) but will definitely use again. Adaptive subdiv worked as advertised.
Why are software people so parsimonous when dealing with versioning?
That "." in versioning scheme has a purpose, but it is completely useless here. You might as well make the version 82 (or even better 8.2) because the "2." is meaningless. The "." allows you to differentiate major, minor and patch versions.
Blender should be using 8.2 instead of 2.82. That helps with legibility and understanding to the user. Remember, versioning and tagging your commit is for the user, not for the software developers.
Let me make my point clear by exaggerating the issue at hand... Imagine if Blender treated version 2.8285218588190159 as "major" version 9, the last digit. The preceding 5 have a chance of changing may be once a decade.
Well, it is an end user application, not a library. As for 79 to 80 being a major change, it was probably a coincidence which had nothing to do with 7 and 8. We might see the next major update at version 87.
> For those unfamiliar with Blender's versioning, the major number is effectively meaningless. The 8 is effectively the major number and the 2 the minor.
According to semantic versioning this would look like Blender v2.8.2.
According web browsers versioning it will be Blender 28.2.
No, semantic versioning applies a specific meaning (that’s what the ‘semantic’ bit means) to the major version number. If the 2 is meaningless then it isn’t a Semantic Versioning major version number.
I think they are very much complimentary. This vastly oversimplifies things, but you can can almost think of gltf is to USD like PNG is to a Photoshop file.
gltf is meant to be a 3D publishing format, whereas USD is meant to be an asset interchange format between DCC applications. gltf is very minimal in the amount of runtime processing required to interpret and display it (much of gltf can more or less be directly mapped into GL buffers), whereas USD includes an extremely powerful schema and composition system that is highly expressive but much more complex to interpret in its fullest form (meant for sending entire editable scenegraphs between, say, Maya and Houdini and Blender and Presto). Both formats are really great at what they’re meant to do.
I was somewhat surprised that Apple picked USD as the basis for their AR stuff, since gltf would have seen like a more natural fit. Maybe the fact that USD has taken the animation/VFX world by storm (many studios are shifting from proprietary internal interchange formats to USD en masse) helped Apple pick.
Thank you for the response and also very cool that the industry is moving towards open source formats. FBX is such a nightmare I'm happy to have moved all my assets to gltf.
Would be nice if Epic included a proper gltf importer in UE4, there’s an open source one but it is functionally limited compared to Epic’s built-in importers.
Blender does a good job of exporting FBX, but it’s nowhere near perfect since they can’t use Autodesk’s proprietary SDK.
There is one. Has been for a long while (1.5 years or so) if you signed up for the Unreal Studio beta and all of the Unreal Studio stuff came to vanilla Unreal Engine in 4.24.
USD is a much more complex beast with powerful composition workflows that allows for meeting the needs of large productions.
Gltf is more of a distribution format at the end of a production like this.
So in this regard they're complementary. USD can also be extended to read other formats like alembic and obj and present it as if they were USD data at runtime. A gltf plugin could be made for USD to allow gltf to act as a leaf node.
There is also a packaged variant of the USD formats called usdz which is what Apple uses for their AR ecosystem. This can be seen as competitive to gltf since they are both now distribution formats and not production formats first.
with the advent of so many open source libraries for physics, maths, geometry, rendering, whatever, blender seems to be the right sink to aggregate all of them.
I would like to port OpenFOAM over to Blender. It’s very powerful software but a mess of dependencies and rubbish documentation. An implementation within Blender would make life so much easier.
You have to make due with 32-bit floating point accuracy for any vertices defined in Blender for the geometry to be passed along to any external libraries. In a prior gig where Blender was the primary development environment, I needed to do all kinds of gymnastics (converting floating point numbers provided by the user in the gui to strings then to Python floats or sometimes 32-bit or 64-bit numpy objects, then to the external package and back) in order to maintain double precision accuracy. Anything created or stored as a Blender FloatProperty is a 32-bit value on the C-side. But if you operate on that FloatProperty object within the embedded Python process you are operating on the 64-bit representation of the 32-bit pattern, since Python floats are all 64-bit values.
I heard more than once during that gig that “Blender is not CAD” even though we were doing everything possible to bring it closer to being so.
But with vertex values, those are created directly in Blender’s C layer, so no possibility to make those values have 64-bit accuracy if that is important to your application or external library.
I am in agreement that Blender would make a fantastic environment to pull together many open source scientific and engineering libraries, but the vertex accuracy is the one major drawback there.
This is very informative. I would think at the very least Blender would allow far more convenient means to construct a blockMeshDict when assembling simple geometries.
I think that greatly depends on Blender further acquiescing to some industry expectations:
- having a stable plugin API that is not Python based is a must for many studios that are working with large computations. A stable C or C++ API is a must for them, versus having to patch and recompile the entire application from source.
- Allowing the plugin API itself to not be beholden to GPL. This stops a lot of commercial plugin developers from supporting Blender.
- Better large scene performance. Right now blender absolutely chugs compared to commercial apps when your scenes get larger
- better undo performance because it's effectively saving a copy of the whole file again per undo.
- potentially more ingrained support for Pixar's USD toolset including a Hydra stage view. Which would open up access to a lot of commercial renderers, but also offload large scene handling to the Pixar stack instead.
The leadership have been resistant to a lot of these over the years. But they seem to be coming about to the value of playing well with existing toolsets rather than being the do-it-all that doesn't fit in well.
I am hopeful with their current trajectory after the revamp of the 2.8x series that it'll see further advancements in the areas I mentioned.
> - Allowing the plugin API itself to not be beholden to GPL. This stops a lot of commercial plugin developers from supporting Blender.
Chaosgroup solved that problem by using the process boundary. They have an integration plugin in GPL and then execute a standalone version of their renderer that they offer separately.
Which works fine for a renderer where you're typically serializing the scene and transferring it over anyway.
It's not as tenable for things like deformers etc that need to feed data back in to the scene every frame. Well.. at least not without severe performance repercussions.
How does jackd manage multi-process realtime audio (or e.g. ReWire on Windows)? Maybe there's a way for Blender to do the same thing, at least on UNIXy platforms.
As long as it can be streamed or batched you can get pretty much the same throughput with IPC. Only latency suffers slightly (microseconds, still within a frame budget even for realtime use), but you only pay that latency overhead once per batched action.
It gets some criticism for it, but, in my opinion, it has one of the most innovative/powerful UX of any software I've used.
Some highlights:
- Any panel can be positioned/sized however you like
- You can create custom named layouts for your own common workflows
- Fully extensible via Python plugins (create new UI panels, menu items, hotkeys, etc.)
- Anything you can do manually can be scripted with python
- By default, (although this has changed some) the more-frequently-used hotkeys are single-key. And of course it's all configurable and (if I remember correctly) they have presets for matching other apps like 3ds max / maya.
- on load / "new file": it loads [something like] "default.blend" instead of a hard-coded set of defaults, so that you can configure its definition of an empty file (which IIRC also includes the default layout configuration). To make it quick+easy to change, you can set with menu option [File]+[Save Startup File].
- Windows can be broken out and dragged to a separate monitor
- Lots of highly-specialized UI widgets. e.g. inline ranged slider that captures the mouse on click and adjusts the value as you move the cursor, has a "progress bar" to visualize the percentage, allows keyboard entry if you single-click instead of click+drag, has arrows on left and right that can be clicked to step forward/backward, has label inline with widget, and has description on mouseover
- Generalized interactive timeline for animation and sequencing
- Powerful node-based editors for shaders, textures, etc., with nodes for each stage of the pipeline and utility nodes to apply transformations (e.g. add a node for a source image, draw a line from the image's color output to the input of a "brightness" node, etc.)
And not only can you use it for the obvious 3D tasks, but it can be used as a non-linear video editor (including things like cross-fade of audio and/or video, video superimposition, textual overlaying, cropping, stretching, mirroring, color manipulation, option to use 3D scene output as video input, etc.), shadeless 2D raster/vector animator, 3D printing, and probably other things I don't know about.
I prefer Cinema4D UI over Blender. It does all the things you listed and then some.
Blender UI is great, but Cinema4D UI is arguably better. I've used both for 10 years.
I think most engineers and designers forget that they're just tools. Vim or emacs? PyCharm. Whatever works for you. Stop letting tools define your craftsmanship. This comment reminds me of pixel peeping that most enthusiast photographers do...comparing MTF curves for days. How about going out and taking pictures, learning composition and narrative, story telling and photographic experimentation? But they're too enslaved to their tools.
You may be right but keep in mind that there are a lot of talented people that cant afford paying for software such as Cinema4D and that's the beauty of Blender you have access to 3D software with good amount of possibilities without paying anything and the community is pretty huge and getting a momentum
The Houdini UI is nothing short of absolute genius.
I don't see Blender ever competing with Houdini. Like...ever. Because, it is fundamentally a different take on 3D content. It does the same thing at the end (3D content), but the way it does it is different (procedural). Better IMHO, but I could be biased.
Does that mean Blender has no place in the sofware ecosystem? No. Can we me a bit more pragmatic, stop horn-tooting and objectively look at the 3D software landscape as a whole? Yes.
Houdini is nice peace of 3D software they are going for a lot of years now leading to 90s good that they added some affordable licensing for indie artists recent years but again for starter 3d artist Blender is best choice after that its up to the person what direction he/she will choose.
> Anything you can do manually can be scripted with python
Moreso - the tool tip for each button / text box lists the python code needed to call that function / edit that value - so it’s not just “anything that can be done manually can hypothetically be scripted”, but “if you can do it manually, then you just need to look at the tooltips and write them down into a text file, and you’ve just written a script to automate your workflow”
While not all the new features will be in this release, the rate of improvement for Blender's sculpting tools has been astounding. For example, the new cloth brush:
I use Blender to make videos of fluid flow to make my teaching more accessible. I absolutely love it, I wish CFD tools had half the polish and capability.
I’m going to do a summer workshop for my colleagues so they can start to make animations of their own, all these new usability features are very much welcome.
I've long wanted to play with fluid simulatuons, but haven't had time for a 3D gfx hobby for a while. Could you recommend a good tutorial or set of documentation for a starting point with Blender's fluid dynamics?
This new version of Blender comes with a new fluid solver called MantaFlow. There should be tutorials popping up on YouTube as I type. I use the FLIP fluid add on which comes with good documentation.
Note that MantaFlow also has a FLIP solver, which is a combination of a volume and particle solver. This is nice because you can simulate how a fluid changes into a foam for example.
I’m also teaching fluid dynamics, and use Blender quite a bit for geometry work. Would love to hear more about your use of Blender for visualization if you’re willing to share.
We're very excited about this new release. I'm pipeline lead at Tangent Animation. Blender was used for "NextGen" and our future projects. I may answer how it is to be part of the development (Blender/Cycles) while producing features, but better yet you can talk to us at the SparkFX in Vancouver if you happen to be there.
Me and my kids have been using it routinely since 2.80 (thanks to the shift to saner mouse button defaults and other UX tweaks), and there are loads of great YouTube tutorials out there these days, so I’d say it’s really helped 3D rendering become mainstream.
Moreover, they also support other FOSS too, for example Krita. I hope these companies would support GIMP as well, and some FOSS video editing tools, like Shortcut.
I think Maya and 3DsMax will have the most difficult future. There are almost no releases of new functionalities and bugfixes from Autodesk while the price is high. And Blender can do what those programs can.
68 comments
[ 3.1 ms ] story [ 187 ms ] threadAnyway the big items in this release IMHO are:
- preliminary support for the Pixar USD format ( https://graphics.pixar.com/usd/docs/index.html ) which is gaining large traction in film studios, gradually in game engines and is the format of choice for Apple's AR ecosystem
- coming in line with the VFX reference platform ( https://vfxplatform.com/ )
The combination of both which means that Blender will be easier to integrate in existing pipelines rather than being a very interesting curiosity for large studios with preexisting pipelines.
Blender is certainly very powerful, and with the 2.8x releases, I think they're really opening up appeal to a larger set of artists and studios.
Just recently been talking to some large studios that are actively considering adding it to their toolset.
An overview of some of the major features in this release with accompanying videos can be found here : https://www.blendernation.com/2020/02/14/the-five-key-featur...
So, blender was on par already for quite a while. And since the version 2.8, it seems that they’re more than on par with the rest of the industry.
https://www.blender.org/download/releases/2-81/
https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/S...
It was almost all focused on sculpting improvements, adding a voxel remesh workflow.
An informal history can be found here https://docs.blender.org/manual/en/latest/getting_started/ab...
But Blender 2 is where it eventually went open source so I tend to read the version as "Blender2 82" vs "Blender 2.82"
That "." in versioning scheme has a purpose, but it is completely useless here. You might as well make the version 82 (or even better 8.2) because the "2." is meaningless. The "." allows you to differentiate major, minor and patch versions.
Blender should be using 8.2 instead of 2.82. That helps with legibility and understanding to the user. Remember, versioning and tagging your commit is for the user, not for the software developers.
Let me make my point clear by exaggerating the issue at hand... Imagine if Blender treated version 2.8285218588190159 as "major" version 9, the last digit. The preceding 5 have a chance of changing may be once a decade.
It's bad.
According to semantic versioning this would look like Blender v2.8.2.
According web browsers versioning it will be Blender 28.2.
According to how browsers version it would be Blender2 82
Ideally the initial 2 would be dropped off since it only has a vestigial reason to be there
gltf is meant to be a 3D publishing format, whereas USD is meant to be an asset interchange format between DCC applications. gltf is very minimal in the amount of runtime processing required to interpret and display it (much of gltf can more or less be directly mapped into GL buffers), whereas USD includes an extremely powerful schema and composition system that is highly expressive but much more complex to interpret in its fullest form (meant for sending entire editable scenegraphs between, say, Maya and Houdini and Blender and Presto). Both formats are really great at what they’re meant to do.
I was somewhat surprised that Apple picked USD as the basis for their AR stuff, since gltf would have seen like a more natural fit. Maybe the fact that USD has taken the animation/VFX world by storm (many studios are shifting from proprietary internal interchange formats to USD en masse) helped Apple pick.
Blender does a good job of exporting FBX, but it’s nowhere near perfect since they can’t use Autodesk’s proprietary SDK.
USD is a much more complex beast with powerful composition workflows that allows for meeting the needs of large productions.
Gltf is more of a distribution format at the end of a production like this.
So in this regard they're complementary. USD can also be extended to read other formats like alembic and obj and present it as if they were USD data at runtime. A gltf plugin could be made for USD to allow gltf to act as a leaf node.
There is also a packaged variant of the USD formats called usdz which is what Apple uses for their AR ecosystem. This can be seen as competitive to gltf since they are both now distribution formats and not production formats first.
It still is difficult to approach, but it has come a very very long way and is almost on par with commercial packages wrt usability.
I heard more than once during that gig that “Blender is not CAD” even though we were doing everything possible to bring it closer to being so.
But with vertex values, those are created directly in Blender’s C layer, so no possibility to make those values have 64-bit accuracy if that is important to your application or external library.
I am in agreement that Blender would make a fantastic environment to pull together many open source scientific and engineering libraries, but the vertex accuracy is the one major drawback there.
http://tkeskita.kapsi.fi/blender/SwiftBlock/docs/swift.html
- having a stable plugin API that is not Python based is a must for many studios that are working with large computations. A stable C or C++ API is a must for them, versus having to patch and recompile the entire application from source.
- Allowing the plugin API itself to not be beholden to GPL. This stops a lot of commercial plugin developers from supporting Blender.
- Better large scene performance. Right now blender absolutely chugs compared to commercial apps when your scenes get larger
- better undo performance because it's effectively saving a copy of the whole file again per undo.
- potentially more ingrained support for Pixar's USD toolset including a Hydra stage view. Which would open up access to a lot of commercial renderers, but also offload large scene handling to the Pixar stack instead.
The leadership have been resistant to a lot of these over the years. But they seem to be coming about to the value of playing well with existing toolsets rather than being the do-it-all that doesn't fit in well.
I am hopeful with their current trajectory after the revamp of the 2.8x series that it'll see further advancements in the areas I mentioned.
Chaosgroup solved that problem by using the process boundary. They have an integration plugin in GPL and then execute a standalone version of their renderer that they offer separately.
It's not as tenable for things like deformers etc that need to feed data back in to the scene every frame. Well.. at least not without severe performance repercussions.
Some highlights:
- Any panel can be positioned/sized however you like
- You can create custom named layouts for your own common workflows
- Fully extensible via Python plugins (create new UI panels, menu items, hotkeys, etc.)
- Anything you can do manually can be scripted with python
- By default, (although this has changed some) the more-frequently-used hotkeys are single-key. And of course it's all configurable and (if I remember correctly) they have presets for matching other apps like 3ds max / maya.
- searchable commands palette (press [space], start typing command name, press [enter] to execute command)
- on load / "new file": it loads [something like] "default.blend" instead of a hard-coded set of defaults, so that you can configure its definition of an empty file (which IIRC also includes the default layout configuration). To make it quick+easy to change, you can set with menu option [File]+[Save Startup File].
- Windows can be broken out and dragged to a separate monitor
- Lots of highly-specialized UI widgets. e.g. inline ranged slider that captures the mouse on click and adjusts the value as you move the cursor, has a "progress bar" to visualize the percentage, allows keyboard entry if you single-click instead of click+drag, has arrows on left and right that can be clicked to step forward/backward, has label inline with widget, and has description on mouseover
- Generalized interactive timeline for animation and sequencing
- Powerful node-based editors for shaders, textures, etc., with nodes for each stage of the pipeline and utility nodes to apply transformations (e.g. add a node for a source image, draw a line from the image's color output to the input of a "brightness" node, etc.)
And not only can you use it for the obvious 3D tasks, but it can be used as a non-linear video editor (including things like cross-fade of audio and/or video, video superimposition, textual overlaying, cropping, stretching, mirroring, color manipulation, option to use 3D scene output as video input, etc.), shadeless 2D raster/vector animator, 3D printing, and probably other things I don't know about.
Blender UI is great, but Cinema4D UI is arguably better. I've used both for 10 years.
I think most engineers and designers forget that they're just tools. Vim or emacs? PyCharm. Whatever works for you. Stop letting tools define your craftsmanship. This comment reminds me of pixel peeping that most enthusiast photographers do...comparing MTF curves for days. How about going out and taking pictures, learning composition and narrative, story telling and photographic experimentation? But they're too enslaved to their tools.
I guess that too can be a hobby?
But I found this horn-tooting about Blender and saying that its superior to every 3D software out there is a stretch if not flatout wrong.
Ever used Houdini? Yeah, it's not totally free but it's free for non-commercial use. It will blow your mind what it can do: https://www.youtube.com/watch?v=MIcUW9QFMLE
The Houdini UI is nothing short of absolute genius.
I don't see Blender ever competing with Houdini. Like...ever. Because, it is fundamentally a different take on 3D content. It does the same thing at the end (3D content), but the way it does it is different (procedural). Better IMHO, but I could be biased.
Does that mean Blender has no place in the sofware ecosystem? No. Can we me a bit more pragmatic, stop horn-tooting and objectively look at the 3D software landscape as a whole? Yes.
Moreso - the tool tip for each button / text box lists the python code needed to call that function / edit that value - so it’s not just “anything that can be done manually can hypothetically be scripted”, but “if you can do it manually, then you just need to look at the tooltips and write them down into a text file, and you’ve just written a script to automate your workflow”
( https://twitter.com/pablodp606/status/1223663016811618307 , https://twitter.com/pablodp606/status/1223060180344147970 )
Available as an experimental build here: https://blender.community/c/graphicall/Sjbbbc/
I’m going to do a summer workshop for my colleagues so they can start to make animations of their own, all these new usability features are very much welcome.
A truly incredible open source project!
FLIP: FLuid Implicit Particle
https://nbviewer.jupyter.org/github/nolankucd/MEEN20010/tree...
https://youtu.be/iZn3kCsw5D8
- How could one build new and better 3D software when competing with free and good enough?
- Does blender as a business generate good income for its developers? If you look at their Development Fund [0], it says $115k/mo for 20 developers.
- What is the extent of contribution to Blender from unpaid contributors?
[0]: https://fund.blender.org
It’s happening, you have game studios like Ubisoft throwing money at the Blender Foundation and switching to it.