Well done article on how to improve Blender to make it fit the industry.
I would add another point to this post is an external SDK/API to make communication easier between application or being able to develop plug-in for it more easly (Blender team if you read this .. cheers 
)
For the OpenEXR / Nuke point … please please do something about it !
http://3dsoul.wordpress.com/2010/01/17/5-things-blender-should-do-to-be-succesful-in-the-industry
[...] actually I think this could be part of a solution about the point I added to his list asking for an external SDK/API. At least for the special effect [...]
“Do you get my point ?”
Sure. It would be a great addition to Blender. Here, Softimage XSI and Houdini’s external APIs have been frequently used to fluidify the workflow and help interoperability.
Thanks for your answers!
and about the Nuke integration, if at least the EXR could not just be output upside down, it would save you from a stupid flip node in Nuke or even AE which is not really consuming, I know, but still when you have a big script, if you could save that from computation it would be nice
Ton gave kind of a reason about this issue at the “Blender conference” but I’m sure there is a solution somewhere
“(I thought Blender 2.5 was now “full python-scriptable”)? The way you can (or can not…) share plug-ins?”
And this is awesome, don’t get me wrong ! every single application should be like that. It got a wonderful “internal” API now.
I’m more talking about an external api though. Like for example if you would like to develop an external application which interact with Blender, as you would do with Max or Maya. If it’s possible now, then I misunderstood something.
The only C plug-in you could develop as far as I know was image plugin and filter plugin (for sequencer).
But let say you want to do a “FumeFx” or “Krakatoa” kind of program which bind with blender, I don’t see any way to do that except by getting your hands dirty into Blender code and recompiling the entire thing everytime.
Which in basics it’s not a big deal, but still if you had to recompile maya or Max each time your company is doing a proprietary plug-in your engineer would get crazy by the end of the day.
The only kind of things that the Py API allow you today (and once again this is my understanding of it, I’d like to be proven wrong) is creating an export for an external render which get a better integration into Blender UI and internal functions. Which is actually really good ! but the other way around is not possible.
Maybe a Py blender lib would do it. so in maya you would be able to do something like “import blender”, but even that would limit the dev to py.
Do you get my point ? Anyway, I don’t think that such a thing would come any time soon…
pssst… “improve Blender to make it __fit__ the industry _needs_.”
(ou alors j’ai pô compris la private joke
)
+1 for better nuke integration. As I commented on the original post too, it should not be a big deal to improve interoperability with such a big compositing software.
Now the question is how hard is it to implement it?
—-
About plug-in development in Blender: I wonder what you mean by “making it more easy”?
I am not used to blender’s python development and I’m curious about your thoughts about it. What is your main complaint about it? The way the internal python API is organized and the freedom it gives you (or not) to script anything (I thought Blender 2.5 was now “full python-scriptable”)? The way you can (or can not…) share plug-ins?
This last point interests me more. For example, I know that in Houdini you can package your scripts/shaders/models/etc. into “digital assets”: something you can easily share with others. In Softimage XSI, plug-ins can be shared through the “workgroups”: a directory where external plug-ins are referenced.
Are there such easy plug-ins sharing mechanisms in blender?
[...] This post was mentioned on Twitter by François Tarlier, François Tarlier. François Tarlier said: New post: 5 things Blender should do to be succesful in the industry (via 3dsoul) – http://tinyurl.com/ydjs7ll [...]