Well - to be honest the render capabilities is since years an issue with Blender.
It is not just a bug problem.
Lets hope that the render branch can bring some relieve to that.
43 seconds on the same chip just the os x version.
must be the winXP build I used - since the time there
was 60 seconds longer.
I was under the impression that Windows versions of Blender were much slower generally in just about everything.
Hopefully we can see stuff like caustics and reflected bump maps worked on after Durian is completed. I do agree with AD in that it is depressing that every other app out there has some form of ‘working’ fast GI system. The big problem with going to 2.5 with me now is that there is no Yafaray plug in.
See what happens.
True, and I am afraid there is some reason:
Open source programs are developed either as alternative to existing software or to accomplish something that is not done by any existing software. in both cases the approach is functional, people just want to be able to do what the big boys do for free, and “a reasonable speed” is often the goal. Reasonable is not enough, the pressure that exists in commercial software doesn’t allow them to just provide functionality: they have to keep optimizing it.
A few years ago, there was just yafray. Now In most types of renderers there are at least two to chose from:
physically based: Luxrender / Yafaray,
Biased hybrid: POVRay / Blender internal,
Renderman compliant: Aqsis / Pixie,
I hope they get enough community to survive all in the long run, so that we have huge open source tool box.
That being said what is really unique in Blender 2.5 is that it mostly focuses on optimisation. For the first time we see commercial renderers versus “open source produced” images compared without people screaming “it’s not fair!”. Because it’s fast enough 
Maurice
well I think you are very right. The past 3 projects always provided new code essential for those
movies, but not for the Blender use base in a general aspect.
While the animation tools, compositor, and modeling tools are of course very welcome
and usable by everybody.
The rendering seems in deed to be enhanced to fit the movie project’s needs.
As far as I know once the Python API is done/stable the Yafaray people will finalice the
exporter for 2.5, which by the way is also a GSOC project right now.
So in that aspect it will not be so bad.
Besides the render engines you mentioned there is also Thea Renderer, which looks very promising
and costs wise very attraktive. If you take a look at their feature list it is very very impressive
and the new interface is a blast to work with.
Sadly the render pass export isn’t really there, which makes post-pro with Blenders compositor
not possible.
What about the work that was done to allow one to use Vray with Blender 2.5? It would almost be a no brainer to buy it (providing you can easily afford it) if it supported all material and texture options (including the procedurals), all the node types (including blending materials together with vertex color channels), the volume textures, and particles (including point density and hair), and pretty much the other things that can be done with Blender Internal.
Considering it looks more attractive if you take note of all the people who dumped MentalRay for Maya, Max, and XSI, for the Vray plugin. Maybe though Thea renderer is cheaper and has the capability to support the same stuff.
Still it doesn’t mean the current bugs and limitations in Blender Internal shouldn’t be dealt with, as it’s still currently the only renderer supporting everything Blender can do.
you all know that the rendere is going to be recoded after durian right?
the render bugs will be fixed for sure we just don’t have the time and only a few of us dare to tread in that place in code, ewwwwww squishy :S
so please show some patience please brecht said don’t post bugs about the render branch for these reasons as its very early days just fixing stuff for durian then fix it fully
Ace,
that is why I have vray for Blender and once the 2.5 exporter is done I will donate funds
to Andrew for having finished it.
It is the best option you can choose from, speed and functionality.
All other options are more or less limited or incomplete.
Mfxodogg
but question is how long this will actually take.
bat3a,
interesting to read - confusing because I can find as many other articles
stating win 7 runs slower because XP is leaner.
strange strange well thats probably the issue with benchmarks you did not
do on your own.
@cekuhnen
come on this is brecht the master renderman with matt ebb as his loyal aprentice, with yves as the wise old man, everything has been planned out and designed now its just to impliment it, which will lake a week to a month not much more i would say
So does that mean that Matt Ebb will be one of the main developers working on the shading recode along with Brecht, will Ton play any role in this project?
Too bad the recode couldn’t have been done during the Durian project like initially planned (if I remember right), it really would by now have shown fruits that would mean a lot of talk about render25 bugs being avoided.
Having plans and being able to do it is something different.
We will see what will be possible for them to do with the resources they have.
U think it would be so fast to get that part done? I imagine 3d render code
being the most difficult one.
Aaaah… music to my ears…
WHAT?!?!? Really??
Too much music for my ears… that’s almost vuvuzelas to my ears!
There’s one BIG upper hand blender internal renderer has towards Mental Ray, V-Ray etc. Maybe the biggest card. It’s Open Source.
I don’t you can get to hung up over the competition, you have to run your own race.
And here I think the future of blender internal renderer can get a lot of help and know how from 3rd party OSS-Developers involved in LuxRenderer, Sunflow (although Java based), Yafaray.
Maybe that’s the time, when re-planning and recoding the internal renderer to invite people over to BF or something. Not only to share source code, but to get ideas how to solve problems. How to get a better integration for external render engines.
For me I would love to get features, like. Rulers in render window so you see the resolution. Able to tweak lighting after render is done ala lux renderer.
Tweak exposure time after rendering is done, apply vignetting afterwards. etc, …
And if 3rd party render engines goes into blender, I would love to see hooks for them in the node compositor so you can do compositing work on a image rendered w/ yafaray etc.
I really hope that’s doable, but for that I think they need to get together and do some planning and good API documentation for the guys working on external render engines.
aermartin
very good point - I asked myself why for example the yafaray people try not to work together with
the Blender people to craft an internal render engine making use of Blenders infrastructure but
supporting yafaray’s quality and tool set.
I know simple copy and past of code does not work. But I hope that at one point there might be
a collaboration between the different camps.
I believe Broken once coded a patch that added chromatic dispersion capability for mirrors and transparency for Blender Internal, as I read it was based off of Yafray’s (or Yafaray’s) code.
It was never put into trunk, but it shows that perhaps some of Yafaray’s code could be adapted to go into Blender Internal with enough work. One of the main reasons the Durian team didn’t break with BI and use Yafaray was because it would’ve needed a bit of work to get it to natively support Blender features that were to be used in the movie, perhaps it being less work to add some sort of GI to Blender Internal.
True I remember that - well lets hope they can do that and bring more things to Blender.
But what questions me is when porting or adapting code would be so easy why do others
spend so much time on writing their own projects?
It seems that it is not so easy to port things. But I am not sure.
bat3a,
ok we tested win7 on my mashine and the time is the same, actually a second slower. so it is just that build.
no big speed gain with win7 and better support for i7.
and strangely again the builds dont work in most cases
I installed win7, python 3.2
Here is the blender 64 build I just tried
I have one other build which runs fine, the one I did the tests with but that one did not even require
python to be installed.
1.you don’t need python to the builds, i never installed it.
2.and that build works fine in my pc, have you installed c++ 2008 latest run time, it’s about 5mb
3.i’ll do some tests on my machine and report it later.