[Bf-committers] Qdune code

[Alfredo de Greef]

Well, similarly I can't speak for the Blender devs
myself either, in a way I'm still on the outside
myself...

Warning! I tend to be very long winded and have
difficulty expressing myself well, so a (very) long
story ahead, but maybe it helps to understand some
things...

Reyes rendering was just something I always have been
interested in. Besides that, almost any graphics coder
 will try programming a raytracer at some point in
their coding life. I had already made a few myself,
also worked on another OS raytracer, the YafRay
project.
So I wanted to try something different next.

Of course you could then ask, why didn't you join
aqsis or Pixie? Well, I wanted to really learn
everything from the ground up, so an obvious choice
was to write my own reyes based renderer.
I was not interested in competing with other projects
at all, I only did this just out of interest, I wanted
to really learn about the inner workings of the reyes
algorithms and such. And with the release of the
"Production Rendering" book the opportunity presented
it self.

This was all around the time of the 'Orange' project.
I also really wanted to contribute something to the
Orange project, and I thought it would be a nice idea
to combine the two.
They really seemed to like the idea, and so I set out
to make something that eventually might be useful in
Blender. They were quite dissapointed in my naive '6
month' estimate for initial implementation, but of
course even that was greatly underestimated.

Of course back then it already occured to me as well
that if it would make it to Blender, the aqsis team at
least probably were not going to be happy about it,
especially concerning the common history of both
aqsis/blender.
On the other hand, I didn't really see that I was ever
going to make it to the same level of aqsis at all,
this was just a 'hobby' project after all.

So much time passed, and of course I didn't make it
for the Orange project and I'm sure it was forgotten
about at times (some probably never expected it to
come to fruition even).
So I got in deeper and deeper, and I could not see any
way to do this without really doing it according to
the books first.
Blender compatibility was less important for a while,
so I ended up with a basic reyes renderer exactly to
specifications (well the basics of it anyway).

Then a while ago plans for a new movie project were
revealed, and one of the main things needed to develop
was better hair rendering. Well, just as you yourself
know very well, RiCurves are very good at that.
(Actually, when Blender strands were implemented, I
can remember you remark here on the list something
like 'when will Blender have dicing/micropolygons?')
Of course, while even after two years QD was still far
from ready yet, I thought maybe this time I could
contribute the micropoly renderer. Besides the movie
project, other projects like GSoC could make it more
difficult later on, so if I didn't do it this time, it
would probably be too late for QD.

And so I did, even though I wanted to contribute, at
the same time I didn't really want all that attention
around it. Certainly not this kind of attention.
so it took a bit of a fight;)
Also because I could already see that it probably was
still way too early, and releasing it might actually
lead to its premature death in a way...

So that is how it all happened.
Besides all of the above, I actually have more
personal reasons for all of this too that I don't want
to get into here.

I didn't expect integration to be done as is the case
now, basically by using the Ri API, with some
extensions.
However, that also means that at the same time work
has been done to make integration with other renderers
easier.
But Brecht, or other blender devs will know more about
that.

Anyway, as you now know, QD will not be used for Peach
at least.
Personally, I can imagine (but that may just be me)
that there is a possibility that it actually might not
happen in the future either...
For Peach they will have to find some rendering
solution for better hair. And that solution might lead
them to implement some form of micropolygons
themselves. Of course with that, it would seem natural
to then extend the rest of the Blender rendering
system  with it as well, instead of replacing it with
completely 'alien' code. Which means QD might only
serve in the end as a base for idea's or such.
QD itself as it is now certainly does not naturally
fit in with the rest of Blenders code base. Not in the
least since it is C++ code, not C.

Again, I did not create this to sabotage Aqsis/Pixie
or any other MP renderer out there.
I did put a *lot* of work into this myself, it is not
the result of an hour or two of work per week, but
rather almost 24/7 straight coding for the past two
years. Yes, I really have nothing better to do at
all...

I don't want to sound presumptuous, and I'm sure this
is going to sound completely ridiculous to you, but
there might actually be some tiny bits of code in
there that might even be useful to aqsis, then again,
maybe not... ;)
I did not entirely code it according to the PR book,
some things I did my own way based on past experience
and experiments.
In my own tests it really did seem as if it was quite
a bit faster than aqsis at times. Of course these were
*rendertests*, not *production rendering*.

I think though that the PR book might lead to more OS
reyes renderers in the future. It is not the same
level of PBRT, but anyone dedicated enough should be
able to create a Reyes renderer from scratch using the
book as reference.

Anyway, I think I said about as much as I can say
myself about this whole affair, the history part
anyway, I'll leave the rest to the Blender devs.

I'm sorry if this doesn't answer your question at all,
but I don't really know what else to say.
If you have any questions for me, then you can always
mail me if you want.

Alfredo

(+2hrs, a record, even for me...)

--- Jonathan Merritt <j.merritt at pgrad.unimelb.edu.au>
wrote:

> Well, I can't speak for anyone else involved with
> Aqsis, but I was  
> personally a bit perplexed to hear about QD.
> 
> The main thing I've been wondering is: why develop
> QD as a separate  
> project?  Why not, for example, take the Aqsis
> subdiv2 code and  
> improve it?  Or add a new shading and sampling
> pipeline?  Or add a  
> "Blender interface" to replace the Ri-calls.  Or ...
> 
> If it is accepted into Blender, QD will fight for
> developers alongside  
> the other open source REYES implementations. 
> Because of the large  
> Blender user base, it will instantly achieve a large
> advantage over  
> Aqsis (and Pixie) that I don't understand.
> 
> It would be instructive to know why QD was chosen. 
> Quick assertions  
> about speed (when the project has never been
> released!) seem to be a  
> bit of an insult to the innumerable man-hours that
> have been devoted  
> to Aqsis and Pixie, and the good-faith efforts to
> get proof-of-concept  
> stuff working.
> 
> The history in this area is really long; numerous
> attempts at Python  
> exporters, work by Green, Paul Gregory and myself on
> integrated  
> exporters, and now the Render API project.  Of all
> those efforts, the  
> Render API looked the most promising.  But then
> suddenly QD sprang up  
> and was incorporated into the Blender code base
> without any external  
> evaluation!  How can QD not be in direct competition
> with the Render  
> API, if it is being used with the intent of
> achieving the same stuff  
> that people would like to see from external
> renderers that will  
> eventually be hooked up to the Render API?
> 
> It's all a bit difficult to understand from the
> outside...
> 
> Jonathan Merritt.
> 
> On 08/11/2007, at 11:54 AM, Alfredo de Greef wrote:
> 
> > --- Jonathan Merritt
> <j.merritt at pgrad.unimelb.edu.au>
> > wrote:
> >> Can
> >> somebody please post the
> >> results of running qdune on these tests?  Then
> we'll
> >> know whether it's
> >> something to get excited about, or whether it's
> >> still a naiive
> >> implementation with a great deal of work still to
> be
> >> done.
> >
> > First, you can safely assume the latter, because
> that
> > is *exactly* what it is.
> >
> > Anyway, the majority of ribfile tests I used
> during
> > development were from JRman, but some of them
> again
> > might come from the aqsis suite, not sure.
> > But as far as I know, making Blender a renderman
> > compliant renderer is not the point anyway, which
> QD
> > certainly is not at all.
> >
> > I hope QD is not seen as the enemy here, though I
> can
> > sort of imagine some feelings of resentment.
> > QDune was/is only possible because of the
> Production
> > Rendering book, and so I also have Paul Gregory to
> > thank for that.
> >
> > Alfredo
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> >
>
http://lists.blender.org/mailman/listinfo/bf-committers
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
>
http://lists.blender.org/mailman/listinfo/bf-committers
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com