It seems that this release is taking some time to stabilize :) Grab it here!
You're blocking ads, which pay for BlenderNation. Read about other ways to support us.
About the Author
Bart Veldhuizen
I have a LONG history with Blender - I wrote some of the earliest Blender tutorials, worked for Not a Number and helped run the crowdfunding campaign that open sourced Blender (the first one on the internet!). I founded BlenderNation in 2006 and have been editing it every single day since then ;-) I also run the Blender Artists forum and I'm Head of Community at Sketchfab.
13 Comments
Ah, the joys of doing your own builds from source...
I spent the weekend figuring out why Collada imports would crash my Blender builds. Turned out it was linking in an obsolete version of libxml2 that I had custom-built from source for some reason I can no longer remember. Removed that, so it fell back to the standard Debian package, and all was well again.
Oh, by the way, you do not want to run debug builds for any longer than you have to. The loss in speed is bloody terrible!
Thank you developers.
I think we need a very stable release, like the 2.49.
aaa 2.49 that was a pleasure to work with, back then.2.69 is lookin pretty damb good these days,GSOC ridged body work is lookin good. i read on the commit logs they were updating the splash and removing the release candidate text. so is this finally 2.69, or more testing for 2.68,a.b,c everytime i spot what i think is a bug someone beats me to it,lol. no worriies just askin if this is it for 68. great work, congrates to all involved.
Thank you kindly, devs.
Yes, thanks devs!
Please, take all the time you need!
That'd only mean a better release.
This may or may not be the best place for it, but as I am not a developer or in any way on the Blender Foundation team, I don't want to just barge into the activity on their mailing lists or other official channels with this.
There was one portion of the three Blender UI videos that has been lost in all the traffic, which is the idea of speeding up the 3D window by conditionally and temporarily presenting an outline, wireframe or some other lower level-of-detail representation of an object when moving it cause the system to chug down and freeze up from trying to fully recalculate all the faces and shadings unnecessarily. That is good memory management and I'd like to suggest that it also be applied to the outliner window.
It seems that the threshold for slowdowns in the outliner window is somewhere between 3000 and 6000 objects. Something in the code causes all the other workspace windows to slow down if there is an open outliner window, and I think this may be a result of trying to cache too much of it in memory at once. It is even more pronounced when there are drivers attached to the objects, particularly in regards to drivers that impact the outline itself such as object renderability. It is as if the window "over-listens" to its environment and bogs down with operations that can be deferred.
What if when the focus is not in the outliner window, all the memory used to cache objects not currently visible in that window was de-allocated or de-referenced? It may not be trivial to code but I think it would be a worthwhile area to focus performance improvements on during the 2.7 stabilization roadmap. For the time being, a workaround is to just remove the outliner from each workspace it appears in until I need to use it, but one wrong move and I'm sitting at a blank screen for ages even if I have managed the 3D window itself carefully.
I have used software programs that have a feature to change something to outline or bounding box when the view port is being updated. And it sounds like a good idea but in practice it is not.
The problem is that the software has no way of telling what is important and what is not in regard the action the user is taking. example: I am moving object A on top of object B and I want object C to be dynamically proxified while i preform the action. How is Blender meant to know which object is object B and C?
To solve this problem you either have a system were you can prevent certain objects from being dynamically proxified, or you have a priorities weighting system. The problem with this is that you may want different things to be proxified depending on the action you are taking.
example: You are moving a statue from one room to another, the statue is highly detailed and you want it to be proxified while you are moving it.
example: You are rotating the statue to get a good view from the camera, you want the rest of the house to be proxified while you get the statue orientated just right.
Both of the above examples are the same action but require different things to be dynamically proxified, their is no way that Blender can intelligently "guess" which is the right thing to proxifiy.
Yeah, I wouldn't want something that dynamic. I'd probably make it optional, apply it to only the object being moved, or perhaps to objects assigned to a group. Or I can just Z-toggle the whole viewport to wireframe, which I do already. It's still superior to Google Sketchup... I have used scenes in Sketchup that really bog down to the point that I can't even use it at all, and Blender keeps on ticking.
There is still something going on with memory management that isn't quite right. The example with the outliner window probably demonstrates it best... it's as if it tries to buffer too much at once. Again I can work with it, but it's odd that if the only windows I have open are the outliner and any other single window, that other window can slow to a crawl. It's like the outliner is being "supercached" whenever it is open.
Thanks, devs.
2.69 will be the super stable version I'll be using for maintaining my previous projects. Looking forward to the next chapter in blender development.
Cool! I'll just wait for RC4. I have too many Blender apps in my hard disk.
Anyway,.. I download it to see the changes :D