Hi guys,<br><br>This is great news, i was thinking something along the same lines, wait till 2.5 RNA api is finalized, then start planning 'something' to start with.<br>I'm convinced this will get a great response from the artist community aswell.<br>
<br>I'll start writing some documentation about various possibilities i need to research with more detail asap,<br>when we've got our %99.99 ready v0.6 luxrender release out of the door during the next week.<br><br>
Thnx!,<br>Radiance<br><br><br><br><div class="gmail_quote">On Mon, Mar 9, 2009 at 6:45 AM, Ton Roosendaal <span dir="ltr"><<a href="mailto:ton@blender.org">ton@blender.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
For many years we try to settle the render API topic, especially to<br>
allow advanced export and/or integration with third party renderers.<br>
For various reasons it remains getting postponed; mostly because the<br>
specs for such a system are complex and fuzzy.<br>
<br>
Before Wintercamp I was contacted by Terrence from Lux to at least give<br>
some roadmap or insight in how we like to proceed with rendering in<br>
Blender. Many developers out there are eagerly waiting for such<br>
clarity, and they are getting a bit tired or demotivated with our slow<br>
progress in this area. :)<br>
I've promised we would spend some time together during the Wintercamp<br>
workshop on this.<br>
<br>
We've discussed a couple of strategies; including a more 'high end'<br>
integration, not based on exporting geometry/materials but for example<br>
exposing an api to use raytrace calls and visibility info.<br>
However, what we quickly fell back to was the simple fact that we first<br>
should work on a good (re)design of how Blender will tackle rendering<br>
in general. This should start with a better way to define own shaders<br>
(real shader tree editor, shader language), but also a more advanced<br>
interal shading/lighting pipeline, and better methods to handle caching<br>
(geometry bucketing, image tiling, shadowbuffer tiling).<br>
This will, combined with the 2.5 flexibility to extend on Blenders data<br>
via RNA, deliver a much better starting point for a future proof design<br>
for integration (plugins) or export.<br>
<br>
So... not an easy answer! :) But I think it's fair for Blender to first<br>
fix their own issues before moving to get better support for external<br>
renderers. That topic is really high on the prioriry list, and can get<br>
first priority when 2.5 is in a workable state, when we start up our<br>
next movie project for example.<br>
<br>
It's extremely tricky to pin me down on dates for this, but very likely<br>
work on rendering code comes back before july, with a working new<br>
architecture for this some months later (october?).<br>
Designs for an improved render system could start away though, and I'd<br>
be very interested to see what Terrence or others have in mind,<br>
especially how integration should ideally work from their perspective.<br>
<br>
-Ton-<br>
<br>
------------------------------------------------------------------------<br>
Ton Roosendaal Blender Foundation <a href="mailto:ton@blender.org">ton@blender.org</a> <a href="http://www.blender.org" target="_blank">www.blender.org</a><br>
Blender Institute BV Entrepotdok 57A 1018AD Amsterdam The Netherlands<br>
<br>
_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</blockquote></div><br>