So no asking for new features in render engine now, it looks like plenty are in that list … !
Hi,
I’m going to move now to the 2nd phase of the render coding project;
which is a full refactor of the source/blender/render/ module in
Blender.
Targets are;
kill all bad level calls and abuse of render code in non-render
modules
means: build a good api to control the entire render process
separate the render process in a more controllable pipeline, I will
use ideas from the Reyes architecture for it
default render with “buckets” (tiles), and allow threads to do each a
full bucket (and more than 2 threads too)
prepare for smart bucketing of object/polygon data as well (later)
enable layer render (separate in front/back using blender layers or
scenes)
generalize current passes for halos and transparent, so it can be
used for more (hair)
use exr to store all tiles and passes in a single file (but also
prepare for multiple computers to render tiles together)
enable motion blur by storing motion vectors in vertices, so blur
passes can be done in postproduction (or exported)
make a noodle editor for reading back the exr ‘layer-passes’ and
enable compositing
enable preview renders of any object/scene in any situation (like
within a border in 3d win)
enable preview renders that only re-render a specific material
Hrms… the list is scary!
Anyhoo; it means a lot of code shuffling… especially in the render
module, but also in the other blender parts like renderwin.c,
material.c, previewrender.c, actually any c file that now has
“render.h” included.
To make a future merge of orange branch back possible, I’d appreciate
it if we can keep the code related to rendering fully frozen now. I
know there’s bugs still in it, but the benefits of a clean new API for
render is evident too!
As a result, unified render might get killed (is really a system I
can’t maintain well).
Also yafray export might need to be fully re-integrated. But, that was
scheduled to do anyway, based on much wanted renderman (Aqsis) export
too! For this I can really use help in a later stage. I’ve also asked
Alfredo to help with compositing effects.
One downside is that I can’t do much now on bf-blender support or
fixing… this is my own deadline for Orange. The guys should have
started rendering weeks ago!
I’ll drop in IRC during meeting time, and will only occasionally check
mail for the next 4-5 days!
i realy hope that yafray will continue its development.
it is to bad it is stalled at the moment. i am curious about how other
people might continue that development.
Some kind of DoF implementation might be nice as well. And I know its petty in comparison with the fundamental coding that he’s doing, but I’d really love to see the rendering “GUI” get fleshed out as well. What I wrote here as well as other interface improvements that will compliment these new features. Making it intuitive to an artist (however subjective this task may be) should be a high priority!
Fantastic, /me can’t wait! Motion blur, passes, all good stuff… and we just had Christmas (2.40)
Though I’m also worried about the future of Yafray, considering I heavily rely on it (well, maybe with renderer improvements, or Aqsis, I won’t need to.)
i am curious if it would be possible to seperate the renderengine from the the main application so it could also be used to batch render and while you render you can continue working in blender.
Yes, that’s something I’ve wanted to happen. This is another major reworking of Blender and I think this is going to take a while (of course in Ton time, that’s about a couple of weeks - he is one amazing coder) but I think it’s necessary. I think there is more than enough in the current release to be getting accustomed to.
This is great news but I just hope it’s a more generalized RIB output. Different renderers have quirks that would make aqsis-only rib output fairly unusable especially if the API is hard to modify. I don’t mean to be cruel to them because they’ve probably done a lot of work but most of the builds are classed as unstable and they still haven’t released a Mac version beyond 0.9.1 - I don’t care if the submitted date is 2005/10/19, it’s been stuck at 0.9.1 for nearly 2 years. The build date is around 2004/04/08 - that is the 8th of April btw, not the 4th of August.
Maybe Pixie would be a safer option given that it’s production tested and stable builds are made regularly for all platforms at the same time. Also, I think the intention of Pixie was to be as close to prman as possible so the rib output may well be usable by production houses who already own prman.
My personal preference is 3delight as it is very efficient, stable and again has stable, regular releases for all platforms and is production tested but it is only free for non-commercial use so may not be a good idea to base Blender’s output on it.
Now, if the aqsis developers and the Blender developers make an agreement to bundle aqsis with Blender so that the issue of different versions for different platforms is not an issue then that would be great.
One thing that may come in handy is the open source liquid project:
It has been used in major feature films and I’m pretty sure all it would need is to change the Maya primitives to Blender ones. It has support for all the major Renderman renderers and a built-in shader editor. It actually links with aqsis when compiling for rib out.
That is what I like about Blender. Not only the development speed, but also the development motto. THe way I understood NaN developed Blender was to look at how the other software packages are implemented and then code what they thought they could use.
And using a Reyes like render architecture seems to me a very safe bet!
But Blender is not only a chimera, but also the coders will further expand the possibilities thus making Blender more unique.
Well… I think I need a year or so to master all the new stuff in the meanwhile.
pass layers…that is great and something that has been lacking. Then again, when I’m not doing system admin work, I’m in the Shake lab working with compositing…
