Is anyone familiar with the new FBX file format? Our developers could use your help!
Ton Roosendaal writes:
Hi all,
Here's notes from today's meeting in irc.freenode.net #blendercoders.
1) Projects for 2.70
- Sergey Sharybin has a big commit waiting that fixes most of the reported regressions related to his work on threaded object updates.
- FBX woes: Autodesk is fading out the FBX version we use, attempts to support the newer versions (7.3/7.4) run into troubles because a lack of public specs. There's some hidden checksum that validates files - or so. Bastien Montagne and Campbell Barton work on it. Help welcome!
- A lot of time was spent on finding out how to move on with UI work with adding 'tabs' in regions that have too many button panels. We'd like to get some minimal guidelines, so other module teams can handle tabs in their own editors. Jonathan Williamson confirms this is a 2.70 target still, and he'll handle a guideline a.s.a.p.
- Tamito Kajiyama proposed to update the Freestyle API, but it would result in breakage for old scripts....
- Meeting agrees on moving to "BCon 3" - the maintaineance/bugfix period, no new branches or big new features added. But we accept as exception the above two topics (freestyle, tabs).
2) Other projects
- New add-on: Edit Add-on Sources.
-Ton-
26 Comments
I should jolly bloody well hope that fixes are coming for the thread-updates problems. I am currently sticking to the immediately-prior commit until there is a fix for this bug.
What's with the harsh tone there? These guys are trying to fix bugs as fast as they can do them, as best as their situations allow to get to them. All without your direct involvement, mind you.
The Blender builds that are posted on the build blogs or graphicall are considered development or beta. If you want a stable release than you download 2.69 and stick with it until 2.70 comes out March of this year.
Build bots or other daily builds are for people who want the bleeding edge of Blender and are prepared to put up with things breaking. Or who want to test and find bugs for the developers to fix.
The whole point of merging stuff with trunk before a major release is for this very reasons. To get more people to test and use and find all the major show stopper bugs before a stable release is put out there.
I find it a bit disingenuous on your part that your don't know that any Blender build that is not a majored numbered release (2.69,2.68 etc) release is in beta and considered unstable.
This is why Git supports branching and merging. See my comment below about this. Try not to limit yourself to SVN-style thinking.
branches are for experimental unstable work too. Actually branches are the most unstable of all since they are not integrated to trunk at all until there is a pull request.
“Trunk” is an SVN term. In Git, there is no such thing. Branches are for whatever you want them to be.
you know it is a free application right,i,m sure there doin the best they can. most of them dont get paid to supply you with a great program to do whatever it is you do.patience my son ,paaaaatience.:))))))
Yes, it’s a free application. And some of us contribute fixes for free, too.
And it is now FIXED!
The bug turned out to be tickled by using the solidify modifier.
Don’t you think Sergey & Co are great? :)
By the way, I think the developers are still a little timid about making use of Git branches. With SVN, it was easy to branch, but much harder to merge, while Git makes merging a lot less painful. Maybe something like the threaded-object updates could have been done on an interim side branch until it was stable enough to go into the mainline.
Maybe we should have a better compatibility with ABC(alembic). Autodesk is niggard.
Yes, better compatibility with alembic is desirable, and it is a very wide format, particularly with film. But FBX is still highly preferred in the graphics industry--it's pretty much standard with game development.
With games being one of the largest entertainment industries in the world, it means Blender stands a lot of business there, thanks to simple features like updated FBX support.
If we're expecting Blender to play well with others, we're better to see Blender support a format that can literally make-or-break many people's adoption towards Blender.
But, of course, easier said than done.
i hope they didn't put off custom normals, I was looking forward to that.
Me too, really needed for building modules that fit perfectly together ... e.g. for kits for making game levels.
The new Edit Add-on Sources is something I needed like last month. I guess my hoping was so strong, it generated the idea into another developer's head!
Good luck with getting to your next checkpoint, Blender Foundation, and thank you.
Very interesting!
The Edit Add-on tool is exactly what I've been looking for!
So, the volume stuff is all working, and pretty dam awesome - I have 'wasted' quite a few compute cycles rendering some suitably crazy stuff as I attempt to push it to the limit and break it (Thus far, only sticking the camera in the volume causes total failure. Other than some occasional glitches with small angled polygons everything else is perfect.). But does anyone know if we are going to get the capability to feed the smoke simulation into cycles to drive the density this release? Kernel density estimation from particles would be equally awesome (That plus the emission shader on volume could be spectacular - sparks that genuinely emit light!). Whilst I certainly appreciate that getting feature parity between Cycles and Blender internal on the GPU is hard work, shouldn't it be a relatively simple case of creating the right interfaces to the preexisting code for the CPU? Or am I missing something?
Probably I'm missing something here, but isn't the FBX SDK free?
http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=10775847
Maybe free, but not Open Source?
surely not, but the problem developers are facing here seem to be, lack of information on the specification of the format.
What sounds strange to me is that, being free, the SDK should be accessible to anyone.
Perhaps it doesn't describe the format in full? ...I don't know.
It’s freeware, not free software.
Yes, I know that difference well.
But, on the other hand, Blender developers seem to be having problems understanding the format
So, if the specs are freely available, I don't know how's that possible??
That's my point
The point being there are no specs available.
ok, I assumed that the file format specification would be given along with the SDK.
Thanks for clarifying
About FBX, have you considered import/export for FBX ascii? Text files are easier to reverse-engineer than binary files. You can then use the free Autodesk FBX converter to convert to and from binary.
I think that’s already been done, but some don’t consider it enough.