POV-Ray : Newsgroups : povray.unofficial.patches : Photon Patch Observation : Photon Patch Observation Server Time
2 Sep 2024 22:17:20 EDT (-0400)
  Photon Patch Observation  
From: Ken
Date: 21 Apr 1999 01:42:53
Message: <371D5791.F2ED940F@pacbell.net>
Hi patch people and Nathan too,

   I recently recieved the source for a representation of a tear drop
 in the form of a Pov quartic object. After seeing how smooth the
 object rendered and thinking about it's uniquely recognizable shape
 I though it would be a good candidate for trial in the Photon patch.

   I ran into an insurmountable problem I though might need to be
 investigated. I never did get the object to render with the photons
 turned on. I tried everything and after waiting through 5 min. plus
 parsing times with no end in sight I gave up.

   In an effort to at least isolate why it would not finish shooting
 photons at the object I tried other primitive types to reproduce the
 tear drop shape. I got a reasonable approximation using a scg of
 various primitives and it rendered in predictable times with
 predictable photon counts.

   I tried the same approach using sors and lathe objects and likewise
 they too operated predictably. I had kind of hoped that the problem
 might have something to do with the higher order math functions used
 in the quartic primitive but my tests do not bear this out. The
 quartic is a 4th order polynomial function while the cubic and
 bezier spline lathe types I tried are listed as 6th order poly's.

   My theory would have placed the lathe object in a higher risk
 group but they but rendered with no problems. The addition or
 omission of the sturmian root solver had no noticable effect on
 the photon patche's handling of the object. It did help the
 appearence of the object and I wonder too if there is some sort
 of tie in here. Is using the sturmian root solver to resolve an
 appearence problem the right thing to do ? Perhaps it is a crutch
 that is masking a much deeper rooted problem within the programs
 handling of these functions.

   Anyway it is being dutifully reported as a possible grey area in
 the Patch's behaviour and I will leave it at that. The source for
 my troubled little scene is below but there were so many different
 parameters used they are no longer representative of what I had set
 for the gathering process. The scene elements in most cases changed
 little or not at all once I found that the lathe object looked fine
 while the quartic did not. I also double checked this observation
 against another closed quartic from shapesq.inc. I choose the piriform
 object as it has similar topographies as the tear drop shape.
 It exhibited the same problem and I presume the same would be true
 with any closed quartic type object.

 With my regards,

-- 
Ken Tyler

mailto://tylereng@pacbell.net


 #declare Drop = 
 quartic{<0,0,0,0,0,0,0, 0,0,-4,0,0, 0,0,0, 0,0,0,
          0,0,0,0,0,0,0,-4,0, 0,0,0,-1,2,0,-2,1 >sturm}

  global_settings { max_trace_level 15 
          photons { gather 20,100 radius .1, 2, .1 jitter .4 autostop 0 } }

  light_source { < 25 , 90, 0> rgb 1 
       photons { refraction on reflection off } }

  camera { location < 0,12, -38 > look_at < 0,-2 ,0 > }

  object  { Drop
    pigment { rgbf 1 }
     finish  { ambient .05 diffuse .01 reflection .05 }
     interior { ior 1.19 }
     rotate 90*-x
    scale 6 
    hollow
   photons { density .12 reflection off refraction on }
  }


  plane { y, -12 
   pigment { rgb<1,1,1> } 
    finish { ambient .025 diffuse .33 }
  }


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.