Blender.org

The videos work fine on my Gentoo Linux on AMD64. I wasn't so sure about the 8fps framerate but it turned out better than I thought. More would always be preferable, but given the amount of videos this looks like a reasonable compromise. Are there any plans to distribute the videos via commom p2p-ne...

As I said on Blendernation: I could lend you my Canon Mini-DV Camera for the time of the conference. The only problem is that I don't want to operate it all the time and I also don't have a tripod for it. Additionally I'd bring my IRIver, which is an MP3-Player with a line-in and recording capabilit...

The room for improvement seems limitless, but I just wanted to take a moment to say:

THANKS n_t FOR THIS FANTASTIC FEATURE!

I can't wait for the next and hopefully more polished version.

This problem also occurs with the internal renderer on Linux (and I would guess on any other platform as well) It appears that it's a minor flaw in the fluid-simulation. It will always use the first frame of the fluid-simulation in the first rendering-frame, even if you start rendering from a frame ...

I guess batch-rendering is something we will see one day. It makes sense from a productivity-standpoint, but I wouldn't expect it too soon.

But as far as I remember you could do it with instinctive-blender (readme).

My favourite way:

Do it during compositing, this gives you the most control over the whole animation.

Always remember: do as much as you can in compositing, never try to render a complex animation in one piece. This gives you a whole lot more control over the final result.

I didn't ever think about Blender as a security issue.

Although I seems currently highly unlikely to be attacked through .blend-files this might become more likely in the future.

It makes me wonder whether there are even thoughts about security when it comes to the verse-integration.

This rocks hard on my gentoo-Linux (AMD64). It's so fast!

I couldn't find any bugs yet, sorry

Waddayaknow, blender can now render without the gui as well. Seems like I have some catching up to do. Last year this wasn't possible, as far as I recall. And I also read the compiling-instructions for blender back then. They were so complicated I didn't even think of trying. (And I didn't find inst...

As turns out that 1 of the test runs was custom compiled. I must mention that "compiling" something on gentoo merely means typing "emerge [package]" in the console, that's about it. For my AMD64 I had to add a little line to one system.-wide configuration file once, but this process was overwhelmin...

Here's the info I can provide: 1. Which blender versions did you compare? 2.37a on both systems 2. Which gcc version did you use with gentoo? The one that comes with it? 3. Which compiler options were set for gcc? The ones recommended in the gentoo installation docs I think. 4. How much free RAM was...

As a short follow-up on my recent Yafray win32 vs. gentoo64 comparison I now had the chance to compare rendering-times with the Blender's internal renderer: my short specs: AMD Athlon 64 3400+ 1 GB Ram The scene contains some very large textures and is lit by a lightdome casting buffered shadows. No...

I'd recommend two thing to get the most out of blender on current hardware: a) the GPU: go for an nVIDIA GPU, as ATI support is rather bad under Linux. which leads us to... b) the CPU: go for an AMD64 processor and run some Linux 64bit system on it for the best possible render-times. I have had a li...

...and now to the direct comparison: system: AMD Athlon 64 3400+ 1GB Ram A new scene showed the following results (rendering times for a single frame): Windows XP 32 SP-2: 4:05.49 gentoo 64 kernel 2.6.11: 2.42.49 I leave it to you whether you consider these numbers "absolutely worthless". As far as ...

I think it is indeed very interesting. I just happened to recently read an article comparing Win32 and Win64 performance . It showed performance-gains between 1% and 10% for floating-point operations. The peak performance increase was visible during media-encoding (15.5%) with XMpeg. Though still in...