Given that it takes 1+ sec / frame, that strongly suggests that either
something very, very weird is going on here, or that Brian indeed uses
multiple secondary rays. In that case I'd not be surprised if
performance tanks; we've never played around with that, and many
optimizations might actually be disabled for secondary rays, anyway
(@brian: at least in the original dynrt codebase, only certain types of
rays actually used all the optimization techniques -- I'm not sure what
has been added since that code has been pulled over into manta).

Merry Christmas ;-)

Ingo

Thiago Ize wrote:
> Brian,
> Are you using manta for shooting just primary rays or are you doing a
> full blown path tracer? If it's a path tracer with lots of bounces,
> then I wouldn't be at all surprised that your single ray acceleration
> structure would perform better since it wouldn't have all the overhead
> inherent in the DynBVH and KDTree acceleration structures which are
> currently only designed for packets. If you are just raycasting, then
> something is very wrong, since you're at least an order of magnitude
> too slow.
>
> Thiago
>
> PS: Why are you not using the standard 1M tri buddha?
>
> Brian Budge wrote:
>> Hi Ingo -
>>
>> I just ran a couple of experiments through again.  It looks as though
>> the DynBVH is definitely faster than both kd-tree implementations.
>> Running the 1.5 million triangle buddha scene, I get the following
>> timings (at 1280x720):
>>
>> DynBVH: 1.1 seconds/frame
>> Manta KD: 1.7 seconds/frame
>> My KD: 1.4 seconds/frame
>>
>> I'm a total Manta newbie, so it may be possible that I don't have
>> packet tracing turned on somehow?  I think it's on by default?
>>
>> I guess there is an untold story here too.  If I run smaller scenes
>> (say 7,500 triangles), the timings are quite a bit different:
>>
>> DynBVH: 0.33 seconds/frame
>> Manta KD: 0.3 seconds/frame
>> My KD: 1.2 seconds/frame
>>
>> I can't say I understand this too well, but I would venture a guess
>> that the packets stay coherent much longer with the smaller scene.
>> Either that or I am doing something stupid with small scenes that
>> doesn't show up with larger scenes.
>>
>> Any insights?
>>
>> BTW, I am using a simple traversal scheme very similar to the one in
>> your thesis.
>>
>> Thanks,
>>   Brian
>>
>> On Dec 23, 2007 1:12 AM, Ingo Wald < ingowald@gmail.com
>> <mailto:ingowald@gmail.com>> wrote:
>>
>>
>>     >
>>     >     > for the viewer?  My own kd-tree ray tracer without sse is
>>     about the
>>     >     > same
>>     >     > speed as tte DynBVH that you guys have, but I would guess
>>     that your
>>     >     > kd-tree
>>     >     > is a good deal faster.
>>     >
>>     Hi Brian,
>>
>>     I actually doubt it is ;-).
>>     I've written the SSE'd kd-tree traverser and kd-SAH builder
>> (assuming
>>     the  one in manta is the one I wrote for Thiago's project...),
>> but it
>>     certainly isn't faster than DynBVH (how could it !?).
>>     I'm also a bit surprised that your _single-ray_ kd-tree is as
>> fast as
>>     DynBVH, which would be _very_ strange indeed (in theory, "perf(SSE
>>     packet/frustum kd-tree) > perf(single-ray kd-tree)" and
>>     "perf(dynbvh) >
>>     perf(SSE kd-tree)", so your message confuses me a bit.
>>
>>     Can you elaborate a bit on
>>     a) what traverser you actually use, and
>>     b) what performance you're getting with dynbvh ? anything close
>> to the
>>     numbers we reported in the paper ?
>>
>>     Ingo
>>
>>
>
>