 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8-7-2015 22:00, Samuel Benge wrote:
> I was hoping that with 64 bit would come a more precise epsilon value, but it
> didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> POV-Ray rendering the same on different architectures, I wonder?
>
Somehow, and I am no expert, I get the impression that epsilon issues
have gotten worse with 3.7.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> On 08/07/2015 21:00, Samuel Benge wrote:
> > Orchid Win7 v1 <voi### [at] devnull> wrote:
> >> On 08/07/2015 06:14 PM, Samuel Benge wrote:
> >>> scott<sco### [at] scottcom> wrote:
> >>>>> The attached shows artifacts present at various accuracies for the function
> >>>>> sqrt(x*x+y*y+z*z)-1.>
> >>>>
> >>>> Assuming you've got no pattern displacement in any of those images, it
> >>>> looks to me like it's something to do with the shadow ray being started
> >>>> too close to the surface (and hence the tracer immediately thinks the
> >>>> shadow ray has been blocked by the isosurface itself).
> >>>
> >>> I should have guessed that, since I ran into shadow ray problems last summer
> >>> with the raymarching stuff. The shadow ray's origin had to be spaced from the
> >>> initial hit point (by backing it up toward the camera or outward from the
> >>> surface), or else artifacts would appear.
> >>
> >> Question: Does the problem go away if you make the spheres bigger? Like,
> >> say, 10 units across instead of just 1?
> >
> > I just ran some tests. Scaled the isosurface and zoomed the camera; adjusted the
> > function radius and scaled the object; multiplied/divided the function to change
> > the gradient's falloff rate... all at values between .01 and 100. No change. You
> > end up just needing to adjust the accuracy and max_gradient, but the end result
> > is always the same.
> >
> >> As I recall, POV-Ray tends to dislike rendering either very tiny or very
> >> large objects. Floating-point precision issues and all.
> >
> > I was hoping that with 64 bit would come a more precise epsilon value, but it
> > didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> > POV-Ray rendering the same on different architectures, I wonder?
>
> This is completely off-topic!
Doh! It's happens too easily around here ;)
> If you start the shadow ray a little further out, you'll just get the
> same artifacts but in a slightly different place. With a point light
> casting a hard shadow-line on a curved surface like that it's always
> going to amplify any numerical precision issues, as all the pixels
> around the shadow-line will have very similar shadow ray direction
> (which are very close to tangent to the surface).
>
> A realistic solution is to use a very small area light, to average out
> the area around the shadow-line.
Well I was thinking that if it worked with straight raymarchers, it would help
with pov's isosurface as well. Editing/compiling pov's source is something I
intend to do... someday. But if somebody wants to beat me to the punch and come
up with an isosurface shadow ray fix (and maybe convince clipka to add it to
UberPOV), it won't hurt my feelings one bit :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> >> I'm also not sure if such a scheme would actually make much improvement
> >> on a GPU.
> >
> > Maybe voronoi diagrams aren't needed. Perhaps a simple 'buckets' system would
> > suffice, where space is divided into cubic cells, with each cell containing just
> > a few objects. Of course, any object overlapping cell boundaries will have to be
> > held in more than one bucket...
>
> I think the tricky part would be deciding which cells an object goes
> into, without either limiting yourself to very simple objects or having
> to manually figure it out.
>
> But assuming you can get around that problem, then yes either into cubic
> cells, or I was initially thinking of non-uniform "groups" that could
> just have bounding spheres. With either method you could go down an
> arbitrary depth depending of cells-within-cells on scene complexity.
Sounds feasible, but I wonder if not being able to use multidimensional arrays
in GLSL will be a roadblock.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> On 8-7-2015 22:00, Samuel Benge wrote:
> > I was hoping that with 64 bit would come a more precise epsilon value, but it
> > didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> > POV-Ray rendering the same on different architectures, I wonder?
> >
>
> Somehow, and I am no expert, I get the impression that epsilon issues
> have gotten worse with 3.7.
>
I haven't noticed. What sorts of problems have been seen?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.07.2015 um 22:00 schrieb Samuel Benge:
> I was hoping that with 64 bit would come a more precise epsilon value, but it
> didn't turn out that way :( Was it a misunderstanding on my part, or to keep
> POV-Ray rendering the same on different architectures, I wonder?
That's obviously a misunderstanding on your part: "64 bit" isn't about
floating point values at all. It's /only/ about pointers: The 32-bit
version of POV-Ray is limited to 3 GB of memory (theoretically 4 GB, but
the operating system typically reserves 1 GB); with the 64-bit version,
your system's physical memory is the limit (POV-Ray's performance on
virtual memory is typically poor at best).
Floating-point values have always been 64 bit in POV-Ray.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.07.2015 um 09:07 schrieb Thomas de Groot:
> On 8-7-2015 22:00, Samuel Benge wrote:
>> I was hoping that with 64 bit would come a more precise epsilon value,
>> but it
>> didn't turn out that way :( Was it a misunderstanding on my part, or
>> to keep
>> POV-Ray rendering the same on different architectures, I wonder?
>>
>
> Somehow, and I am no expert, I get the impression that epsilon issues
> have gotten worse with 3.7.
The problem is, someone changed some of those precision-related
constants during the early stages of 3.7 development for obscure
reasons, and now nobody seems to know what the right values are.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/07/2015 05:44 AM, clipka wrote:
> The problem is, someone changed some of those precision-related
> constants during the early stages of 3.7 development for obscure
> reasons, and now nobody seems to know what the right values are.
What, no source control?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.07.2015 um 09:48 schrieb Orchid Win7 v1:
> On 11/07/2015 05:44 AM, clipka wrote:
>> The problem is, someone changed some of those precision-related
>> constants during the early stages of 3.7 development for obscure
>> reasons, and now nobody seems to know what the right values are.
>
> What, no source control?
Not in the early (read: way before beta) stages of 3.7 development, no.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 13 Jul 2015 00:24:55 +0200, clipka <ano### [at] anonymousorg> wrote:
> Am 11.07.2015 um 09:48 schrieb Orchid Win7 v1:
>> On 11/07/2015 05:44 AM, clipka wrote:
>>> The problem is, someone changed some of those precision-related
>>> constants during the early stages of 3.7 development for obscure
>>> reasons, and now nobody seems to know what the right values are.
>>
>> What, no source control?
>
> Not in the early (read: way before beta) stages of 3.7 development, no.
>
Wouldn't it be in the 3.6 code?
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.07.2015 um 18:14 schrieb Nekar Xenos:
> On Mon, 13 Jul 2015 00:24:55 +0200, clipka <ano### [at] anonymousorg> wrote:
>
>> Am 11.07.2015 um 09:48 schrieb Orchid Win7 v1:
>>> On 11/07/2015 05:44 AM, clipka wrote:
>>>> The problem is, someone changed some of those precision-related
>>>> constants during the early stages of 3.7 development for obscure
>>>> reasons, and now nobody seems to know what the right values are.
>>>
>>> What, no source control?
>>
>> Not in the early (read: way before beta) stages of 3.7 development, no.
>>
>
> Wouldn't it be in the 3.6 code?
The problem isn't so much what the original values were (although that
in itself might turn out to be a rather tedious task by now, as files
have been moved around, functions renamed, and so forth), but which of
the changes that have been made since then are legit and which are just
relics of blind tweaking.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
