|
 |
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
|
|
|
|
On Tue, 20 Apr 1999 21:44:01 -0700, Ken <tyl### [at] pacbell net> wrote:
>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.
<snip>
Ken,
photons are shot at an object's bounding box. Quadrics are not
automatically bounded hence the infinite photon count. Bound the
teardrop manually, make sure user bounds are not removed (-ur), render
the thingy and let's see the result.
My best regards.
---------
Peter Popov
ICQ: 15002700
Post a reply to this message
|
|
|
|
Hi Ken,
The problem is that polynomial objects, like planes, are infinite solid
primitives and so are not bounded on the fly by PoV.
Unfortunately the photon patch gets upset by this and, I believe, tries
to photon sample between plus and minus infinity (or some approximation
thereof :-).
The solution is to bound by hand. I put the line
bounded_by { sphere { 0, 10 } }
in the object definition and it parsed in a couple of seconds.
Ken wrote:
>
> 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.
[snip, snip]
> With my regards,
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
[pov code snipped]
Post a reply to this message
|
|
|
|
Michael Andrews wrote:
>
> Hi Ken,
> The problem is that polynomial objects, like planes, are infinite solid
> primitives and so are not bounded on the fly by PoV.
> Unfortunately the photon patch gets upset by this and, I believe, tries
> to photon sample between plus and minus infinity (or some approximation
> thereof :-).
Peter - Michael,
I appreciate you coming to the rescue. It seems I am to be forever plagued
by this bounding box issue. I had no idea that one of the earliest pov object
types did not have an internal bounding scheme. I can see where it would be
a mother of a project to make it work. I will try to pound this into my head
with a large blunt object concerning this issue of bounding. For me it has
become the single greatest contributor to overly long gathering times and
twice now it has tricked me this way. It wont happen again I can assure you.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
