Blender 2.62 is still on schedule for release at the end of this week.
Ton Roosendaal writes:
Hi all,
Here's the summary of today's meeting:
1) Blender 2.62 release
- Jens Verwiebe solved issues with linking Lux and Cycles together with Blender, was a conflict in namespace caused by openImageIO library (OS X only).
- Jens also has a patch that bypasses reading movie files with QT in 64 bits OS X, FFMpeg is much faster.
- A discussion went on whether to wait a week with the release or to do it this week. Everyone agreed on just going for it, but spend another 3 days on bug fixing at least.
- So: this thursday - CET daytime - a call for building releases will be sent out. Ton will check with platform builders if they're available (Nathan, are you? :).
- Release log in progress, please check if your work is there, add cool images!
- Several complaints came in about hidden GPU option in Cycles. Brecht will turn this on by default in User Preferences, so the menu to choose CPU/GPU is visible for everyone from scratch.
2) Other projects, 2.63
- Focus for 2.63 is still for BMesh. Campbell likes to get Brecht and others to do final review before deciding to merge. Next sunday we could decide the final branch merger date though.
- Lukas Toenne will have his group node patch ready for 2.63, seeking for reviewer(s) still.
- Nicholas Bishop has patch ready for an "on-surface brush" for sculpt. Comes from Jason Wilkin's GSoC project.
Thanks all,
-Ton-
61 Comments
OIIII! On-Surface for Sculpt, awesome - that means we could possibly mod that for TEXTURE PAINT as well?
“on-surface brush”? Awesome, silly what makes me excited these days but it really has potential!
and open cl ? ):
Please guys, try to remember that Cycles is in it development phase. Whatever we can use of it already is bonus. Tough tease, I know... :D
The open CL support as far as I know is an ATI issue not a blender development issue. As in ATI need to release drivers that support Open CL better. I think they are slowly moving on doing this. There is more information about it on blenderartists.
I downloaded on of the more recent Cycles, and OpenCL worked on my Mac, where previously it did not, so headway is being made, either by Blender or ATI.
Hello to all. Firstly big thanks to Ton and the Devs who are working so hard. The new UV tool is gonna really help. I have a little worry though.
I downloaded the last RC and I was quite surprise by the number of black and white dots that it produces. I know that this bug was reported but seeing that maybe a final release might be schedule this week I am wondering they have had enough time to tackle this problem.
The scene I tested was done in 2.61 and worked really great. Only a few black dots was there. But this time the whole screen was full of black and white dots with 2.62 RC.
If you have a test file that can be used to reproduce this problem, it might be worth submitting a bug (or attaching it to an existing bug.)
B-B-B-B-B-BMESHHHHHH! HELLLLL YEAAAAH!
Hi, everyone is speaking about new Tools and so on. We need the abillity to load Texture Animations in Cycles(tex. as image sequences) and we need a way to render with ATI Cards too. both are very important and not other stuff...IF you do VFX work you need Image sequences as Texture to recreate the correct Lighting and Reflexion on an Object with moving camera. THATS very Important!
if you wan't so much do real vfx get a real tool for it, not blender
The aim of Mango being to prove that Blender is VFX ready...
yes in deed but something is missing. and thats important. please watch vimeo link above
I really agree about the urgent need for image sequences as textures in cycles..
I like it^^ and sorry i dont wanna fight with you but i know you know not enough about blender or VFX or real tools iam working in VFX industry. sorry dont speak about things you dont fully understand. one of my examples: http://vimeo.com/35428634 its made with blender.
I agree with you Alexander,most of those guys who just consider Blender as a "b class" tool for VFX work just aren't aware of the full potential of the software and they're ( oftentimes) amateurs impressed more by the "glam"- and "pro- thing of the commercial apps,rather,than by their real potential.
I do know,me too,that Blender is capable of producing high quality VFX content,when in the right hands,and a good example for this is your "Cyborg VFX Demolitions" work on which I congratulate you.Peter
thx
cycles open cl/ati isn't coming for at least half a year, since it isn't something trivial at all...
great work devs!
That's the Blender Development Fund paying off. :)
On-surface brush? Oh, yeah! That's awesome! It's the little things... :D
Just a quick question, folks, because this is bothering me as I speak: Is anybody else experiencing any trouble using the Alt+C "Convert to..." function in any of the Blender 2.6x builds, whether by hotkey or by menu selection? I've been running into a crash every time I use it Blender crashes on Alt+c operation. The particular build I'm using is the official Blender 2.61 (r43615), 32-bit.
This is what I do:
- Start-up Blender and delete the default cube.
- Add a Surface NURBS Sphere object (or any other curve object).- Try to convert it to a mesh using either Alt+C or the Object > Convert To > Mesh from Curve/Meta/Surf/Text.If the problem isn't just on my end here, Blender should crash. If anyone else is experiencing this too, then please let me know so that I can properly report it as a bug. If nobody else's really experiencing this, I'll investigate my computer. But I noticed that this issue wasn't resolved for me with the recent Blender 2.62rc1 (Windows 32-bit) either. And I can vaguely recall this being an issue with Blender 2.60 as well. Though, oddly enough, when I convert a simple Mesh object (like a circle) into a Curve object using Alt+C, and then convert that Curve object back into a Mesh object, Blender doesn't seem to crash. Also, this doesn't seem to be an Add-On incompatibility issue, as even when loading default factory settings, the Alt+C function still crashes for me.
I know this isn't the place to be addressing bugs here and I hope I don't inspire a list of folks complaining about bugs here, but I need to know from the public here if this just isn't something I'm personally experiencing and no one else is before I properly report it as a bug.
wait a week and try it again.
...and it will STILL crash again...
...unless he downloads the latest version :)
Crashes and hangs are the most serious bugs. I'd go ahead and file a bug. It may or may not be related to your system, but the devs would probably like to investigate.
FYI, I run Ubuntu 10.04 64-bit with 2.61 - the bug doesn't occur on my system.
No crashes with the 32 bit for Mac.
I'm using OsX lion (on macMini) so it may not help you but anyway. I tried it with 2.62 RC1 (2.61.4 v43946)
And it work fine. It gave me a clean topology.
2.61 on XP 32bit no crashing here.
It must be something on my end, then, though, I'll still check for it in other builds. Thanks, guys.
I just dont get it, They are about to start a big VFX project and they focus on BMesh? That sounds like nonsense to me.
They need it in blender. It is almost finished. It is holding up the development of other parts of blender, so no, it's not nonsense to spend some time getting it all working before they move onto other goals. There are detailed threads you can read, on blender artists, if you would like to keep abreast as to why and what they add into blender.
This is mostly about programmers and development cycle. Until now BMesh was out of sync with the trunk because a lot of the features from the trunk didn't work with BMesh. But now BMesh and the trunk are much more better synchronized than they used to be so this is a golden opportunity to merge them. Keeping them synchronized means extra effort and also many new features will be delayed because the developers have to check and make the features work for BMesh too.
But since at this moment in time, BMesh has almost all the features that are included in the trunk working it's easier to merge it with the trunk.
Ofcourse, BMesh isn't directly required for Mango, but it's been sitting on the shelve for a long time and a lot of people want to use it. Every week, when developer meeting notes get posted, most comments have been about when BMesh will finally be included. I don't understand, because I don't really know what BMesh is about and haven't taken the time to look into it, but most people here seem to think it will be awesome. So, there is a big market in the Blender community for it and kudos for Ton et al. for taking that seriously!
yay its getting better it would appear used to be a maya user now an official blender 2.6 user as for open CL settings use and Intel Hd Graphics card
Multithreading support for fluid particles! That sounds interesting too... I'll finally get to use all the cores!?
Awesome work everyone!
Great news! Awesome job guys, big thanks to the developers for working on this project :)
Does anyone know the projected timelines for the GSoC Onion (sculpting) and/or Skin Mod work? Sculpting features is what's most exciting to me. Can't wait for Unlimited Clay, Onion, and the Skin modifier.
Unlimited Clay is waiting for BMesh, so once that is implemented, Farsthay can begin work on it. He has done some very impressive things with 3D Coat and they will make Blender OH SO Much better too. I can't wait for that either!!
Any chance of getting the render preview function back? (Used to be Shift+P in Blender 2.49.)
I've been quietly hoping for it since 2.5. We used to use it for a "live" camera preview on our fisheye camera rig.
(I realize we can do this by switching to cycles, but our render farm is CPU based and it's going to be a while before we can upgrade to a GPU based system. If the materials were unified, this would be a viable option.)
Maybe there's another option (aside from constantly hitting F12).
Here's the new deal: before you hit F12 to render go to the UV/Image Editor. Your first render by default will be in Slot 1, you'll see this as a tab between Render Results and RenderLayer. For your next render choose a different Slot. Then you can jump between them with the J key, or alt-J to go backwards through them.
Thanks for the info, Pam. I didn't know about the slots for use as a comparison tool, so that's good.
We've been doing something like this already by making a UV/Image window in the corner and updating it with F12. It would be nice if it could update more automatically and scale to the "preview window" size instead of a full resolution render.
Maybe I can write a plugin that does it...
well if i wasnt dissapointed before with 2.6 i am now, i cant believe that you are yet again cuttinf AMD and ATI GPU's out, this is a very important part of cycles...the GPU rendering, and so far only the people that have nvidia cards have been able to use it, i was really hoping brecht wouldv'e got his arse in gear and sorted out the code so that the other half of blender users can also enjoy cycles, luckily i have an 8 core Bulldoser CPU which handles cycles pretty well, but i know my top of the GFX card could handle it even better.
well i suppose i should stop moaning before the nvidia fanboys start menstrating (no offense to everyone who owns an nvdia card, that jab was only for the ones who think its the only card in the world worth buying)
well at least i can look forward to trying out some ngon modelling :) is there any notable performance improvements to cycles in this release, i heard there would be but what i can read here doesnt mention it :L
My understanding is that Cycles will eventually support most major chipsets. The devs have to start somewhere and Nvidia is first because they made development easiest with Cuda. Tell ATI to do the same, eh? :)
OpenCL in Cycles has nothing to do with Brecht or his implied laziness. ATI has failed to release new OpenCL drivers that would allow the Cycles kernel to run. As it is written, the kernel for cycles runs off of one unified set of directions that works on both CPU and CUDA, but without the need for and exclusive CUDA calls. Development is being held up until the OpenCL standard is mature enough to run without a special branch of code, which would just mean more problems and maintenance down the road just to keep ati cards working.
Also keep in mind that Cycles is still an alpha piece of software. The fact that people bitch about it shows how spoiled some of us are concerning immediately available changes due to the open nature of Blender development.
People seem to forget that indeed, Cycles is still an Alpha or maybe a Beta version available in trunk but the Mango project is meant exactly for the purpose of developing the Cycles rendering capabilities (and the tracking system etc.) Do suggest options you'd like to have in the renderer but come on. Give the Devs a chance to code it.
glad you understand the basic concepts around being polite in your comments.
Particularly liked the 'wish Brecht would've got his arse in gear'. Maybe this site should only allow comments from those who have passed puberty, whatdya think?
baking with Cycles? please :)
thanks
What about having backward compatibility. Say run a batch script of some sort to convert all the Sintel scenes that were done with 2.5 to make it work on 2.6. It's kind of irresponsible or rambo-programming to have the Sintel scene files not working even among the 2.5 releases, let alone 2.6.
Sintel will never render with new releases, mainly because the render branch was a hacked together mess, which led to starting over with cycles. Many of the tricks used don't exist in the current BI. Parts of Sintel have been updated to work with newer versions, but if it were as easy as a batch script, it would have already been done.
so in other words, Sintel doesn't show the actual "real" potential of Sintel because the Render branch was never merged into trunk?
"Real potential of Blender internal renderer" I meant :P
Pretty much. You wouldn't have wanted the render branch anyway. It was crashy, patched together, slow, and inaccurate. Not to say it wasn't a monumental effort by Brecht, but it should say more about the state of the code of BI (and the need for a modern overhaul) than anything. Seeing the progress made on Cycles has been fantastic over the last year or so, and if nothing else I'm glad it took Sintel to realize what was needed for the future.
Awesome! Excited for BMesh! Bmesh is probably my second most anticipated blender development. Second to Phymec tools. Unfortunately, there's no telling when or even if Phymec Tools will ever be released :(
I'm always amazed how people dare to moan about Blender development.
The Blender guys doing a great job with a lot passion and releasing Blender for free. Though there are still people who seems not to appreciate the hard work and instead complaining about missing features.
Damn guys, Blender has a monthly update cycle and bug get fixed within of days in most cases. They working their a$$es of to get new stuff into the trunk. Even commercial software isn't that fast. And still some people are not pleased...
How much of you guys who complaining donated to the Blender Foundation?
+1 for agreement. Very well said!
Merges always seem to be a big job for them, though. From my outside view, I’m inclined to blame it on the use of Subversion (SVN) for version control. SVN makes it easy to branch off, but not so easy to merge the branches back again. If they used Git (like the Linux kernel and a lot of other large projects), I daresay they would find merges much easier to manage. Which means they will do them more often. Which means we might already be seeing experimental, unfinished BMesh code in trunk by now. Which means more people will get to play with it. Which means the bugs will be shaken out sooner. Which means ... you get the picture.
I am pleased with the way that releases are being described, managed and published. There will always be fights about which features should be in or out of a particular release but it is really good to see a formal pattern becoming established with some declared timelines and focus for each new version and the associated release note wiki pages etc. My expectations are clearly set when I look at these Development Meeting Notes and if a feature slips to the next release because the developers say they need to do some more work on it that's okay with me. Over the last year or so this improved management and communication has increased my trust in the release mechanism and in my opinion this is the proper way to keep Blender users informed and on board.
TY
Jens Verwiebe
Yeah, I am so happy with the fact that Bmesh is almost ready to merge into trunk. So many tools are on hold due to this feature, so it can only be assumed that once in and stabilized by the core devs, that many new and exciting tools will find their way in.
If I am not misunderstanding anything either, the next release will have a shorter release phase as the main focus will be Bmesh and getting it stable. Then the devs can focus their attention on other areas of importance for them. OH if only I could code... this would truly be tempting to be part of. Good luck devs.
P.S. good to see that CGsociety has given the word out about Mango on their front page news section
http://www.cgsociety.org/index.php/CGSFeatures/CGSFeatureSpecial/mango
Looks like a great update (as usual). Apart the biggies, the drag and drop parenting and the After Effects export are really useful. There is an useful add-on out there for export to Apple Motion - be nice to see that in trunk one day, as Motion is more accessibly priced. Blender is such a gift, one can only marvel
This will be my most waited version of blender!
Thank you very much for all the hard work. Blender is just awesom !
If you like, you can view this little 1 mn 55" done with cycles and some post prod (http://vimeo.com/36542191).
Can't wait for this week's release of 2.63.