Manta Interactive Ray Tracer Development Mailing List

Text archives Help


Re: [Manta] r2077 - trunk/Interface


Chronological Thread 
  • From: Solomon Boulos <boulos@cs.utah.edu>
  • To: Thiago Ize <thiago@cs.utah.edu>
  • Cc: "Steven G. Parker" <sparker@cs.utah.edu>, ollie@lanl.gov, manta@sci.utah.edu
  • Subject: Re: [Manta] r2077 - trunk/Interface
  • Date: Fri, 15 Feb 2008 15:01:22 -0800
I don't believe that a non constant epsilon is going to cause a noticeable perf hit almost anywhere. Unless we've got a statically loaded sse version of T_EPSILON lying around, the compiler won't be making any optimizations that would cause any difference if that value were in the ray packet and per ray (even for scalar code, C++ is going to block it from doing anything particular clever with the value).

I plan on testing this idea soon anyway, so I'd say get your benchmarks ready ;) (though the ones we're using now are pretty good I'd say).

On Feb 15, 2008, at 2:58 PM, Thiago Ize wrote:

It's roughly 10x10x10 units according to the BBox. That seems reasonable, although resizing the scene would by 1/10 might help.

Also, I'm a little worried that a non-constant epsilon would cause a noticeable performance hit. Instead of modifying epsilon, I'd advocate resizing the scene (not through an instance, but on the actual data).

Thiago

Steven G. Parker wrote:
We might want to make epsilon be part of the scene instead of compiled into the binary. What is the "scale" of that object? If it is not on the order of 1.0, Manta miht not like it. Changing epsilon would help that.

Steve


On Feb 15, 2008, at 3:48 PM, Thiago Ize wrote:

Li-Ta Lo wrote:

On Fri, 2008-02-15 at 14:44 -0700, Thiago Ize wrote:

yeah, I see the surface acne along the shadow boundary. I'm guessing
what is happening here is a self shadowing artifact. If that's the
case, then I would have expected my raising of T_EPSILON from 1e-5 to
1-4 would have actually improved this problem for you.

When you hit 'c', what is the camera position? Also, what are the
dimensions of your scene? (Some of the acceleration structures will
print the bounding box for you during the build).


A similar one showing the problem has bbox and camera:

Make_scene args: 2

DynBVH::preprocess START (11035 objects)

DynBVH build time: Total (0.01881)
object_ids initialization (0.001255)
build (0.016756)
updateBounds (0.000799)
BBox = (-72.7012 -56.3921 254.661, -62.4312 -44.3239 264.465)

pinhole( -eye -62.0498 -49.0895 256.554 -lookat -67.5659 -50.3581
259.562 -up -0.176268 0.98021 0.0900966 -hfov 60 -vfov 60
-normalizeRays )



Alas, that looks reasonable to me. Does modifying the value of T_EPSILON to 1e-2, 1e-3, 1e-4, etc... in Interface/Parameters.h give something that works?
By the way, if you want nice looking images, try super sampling by
adding one of the following command line arguments:
 -imagetraverser deadline"()" or

This one fixed the problem as is actuall twice faster (fps). It is
normal to show the mosaic when I rotate the scene, right?

It's not actually twice as fast. What deadline does is progressively render the frame. So it will first render a coarse version. Then it will cast some more rays and render a more refined version. And so on until you've actually cast 1024 rays per pixel. That means the image should look really pretty if you wait a while and don't move the camera. The blockyness you see when you move the camera is manta having to start from scratch again and render a coarse version. The fps will actually always be the same with deadline. But if you have a really slow to render scene you'll see the blockyness for more time since manta is taking lower to refine (so we trade quality for responsiveness).
What is an image traverser?


It determines how the primary rays should be cast. Deadline does it progressively, others will cast rays in a horizontal line, some in a square tile, and so on.

Thiago





Archive powered by MHonArc 2.6.16.

Top of page