[Bf-committers] Qdune code

[Joe Eagar]

One of the core Aqsis devs mentioned that Aqsis suffers from speed 
problems.  This was months ago, and current SVN could've improved a lot 
for all I know, but at that time there was even a java REYES renderer 
faster then Aqsis.

I kindof don't think Aqsis would be a good investment for direct 
integration into blender.  Pixie is miles ahead of Aqsis, which kindof 
makes the deal for me.  I'm not sure how you could ever argue Aqsis over 
Pixie, to be honest.  Pixie supports ray tracing (using the pixar cache 
method), better shadow maps, etc (I know, all these are being "worked 
on" for Aqsis).  Ray tracing especially is important for some things.

Joe

Jonathan Merritt wrote:
> Good grief Campbell, that's a very glib statement!
>
> Firstly, you don't say which version of Aqsis you tested, on what  
> platform, how it was optimised, etc.  Considering qdune has never seen  
> a release, to have Aqsis fairly represented would presumably have  
> involved getting a current SVN build going...?  Aqsis SVN is faster  
> than the previous 1.2.0 release from Feb 2007.
>
> Secondly, of all the Aqsis geometric primitives, I would say that  
> subdiv surfaces are among the *least* well-supported!  They're there,  
> and they work, but they aren't anywhere near as fast as NURBS for  
> example.  As with everything else, they are in development, and I'm  
> sure that if Blender were to become a major provider of subdiv content  
> then improving them would shoot way up the list of priorities.
>
> Thirdly, how were your simple subsurf tests performed?  I'm guessing  
> you just chucked the same RIB file at both renderers right?  Did  
> anyone count how many gprim splits were done or how many micropolygons  
> were produced?  I ask mainly because the basic "quality" settings of  
> renderers can be different.  Pixie vs Aqsis is a great example...  
> Pixie seems to end up with more coarse surface approximations, and  
> hence renders "faster".  It doesn't mean that Pixie *is* faster (I  
> would argue the reverse)... just that it's not as high quality by  
> default, doesn't have to do as much dicing and splitting, and then has  
> nowhere near as many micropolygons to shade and sample.  (The idea is  
> that whoever produces the scene can change these settings in the great  
> speed-quality tradeoff.)
>
> Finally, one of the best things about Aqsis is its test suite.  The  
> tests are *not* specific to Aqsis and are more extensive than any  
> other RenderMan test suite I'm aware of.  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.
>
> Jonathan Merritt.
>
>
> On 08/11/2007, at 8:44 AM, Campbell Barton wrote:
>
>   
>> Aqsis was slower then qdune for simple subsurf tests,
>> This is a fair comparison, qdune and aqsis both support this well.
>> Pixie wont run on 64bit systems yet.
>>
>> Even if they were used, integration would still take a while.
>>
>> On Wed, 2007-11-07 at 16:35 -0500, David Bryant wrote:
>>     
>>> Maybe I'm taking a shot in the dark but,have you examined Aqsis'
>>> source code? It's rederman compliant.
>>> _______________________________________________
>>> 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
>>     
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>