Hi!

In the povray-code posted below, I'm trying to show two objects composed 
of transparent light emitting material, that intersect eachother, simply 
as an illustration of what the intersection should look like (first 
object red, second green, in the intersection both colors are emitted 
simultaneously).

This seems to work great, except when the surfaces of both objects come 
close to eachother.  Rendering the code should show some sort of cross 
composed of areas/pixels that are either fully red or green.  It is as 
if the rays only see the entrance into one of both objects, and the 
other object is disregarded.  Rendering with anti-aliasing partly hides 
the problems where they weren't too large in the first place, but the 
cross is still very visible.

Is there an easy solution for this?  (I suppose it's an accuracy 
problem, not a real bug)

Many thanks,
Stefaan


// Povray code for two intersecting, light emitting transparent lathes

camera {
	translate 1 * -z
	rotate <-90, 0, 0>
}

#declare cone0 =
	lathe {
		linear_spline
		2,
		<0, 0>, <.4, 4>
	}

#declare cone1 =
	object {
		cone0

		transform {
			translate -y * 2
			rotate <90, 0, 0>
		}
	}

#declare cone2 =
	object {
		cone0

		transform {
			translate -y * 2
			rotate <0, 0, 90>
			rotate <90, 0, 0>
		}
	}

object {
	cone1
	pigment { color rgbt <0, 0, 0, 1> }
	interior {
		media {
			emission rgb <.5, 0, 0>
			intervals 1
			samples 5
			method 3
			density { rgb 2 }
		}
	}
	hollow
}

object {
	cone2
	pigment { color rgbt <0, 0, 0, 1> }
	interior {
		media {
			emission rgb <0, .5, 0>
			intervals 1
			samples 5
			method 3
			density { rgb 2 }
		}
	}
	hollow
}

Post a reply to this message

> Is there an easy solution for this?  (I suppose it's an accuracy problem, 
> not a real bug)

There is no easy solution to this.
The artifacts are from floating point errors where
the very narrow seams are too small to sample.

Post a reply to this message

Stefaan De Roeck nous apporta ses lumieres en ce 2008/04/07 12:43:
> Hi!
> 
> In the povray-code posted below, I'm trying to show two objects composed 
> of transparent light emitting material, that intersect eachother, simply 
> as an illustration of what the intersection should look like (first 
> object red, second green, in the intersection both colors are emitted 
> simultaneously).
> 
> This seems to work great, except when the surfaces of both objects come 
> close to eachother.  Rendering the code should show some sort of cross 
> composed of areas/pixels that are either fully red or green.  It is as 
> if the rays only see the entrance into one of both objects, and the 
> other object is disregarded.  Rendering with anti-aliasing partly hides 
> the problems where they weren't too large in the first place, but the 
> cross is still very visible.
> 
> Is there an easy solution for this?  (I suppose it's an accuracy 
> problem, not a real bug)
> 
> Many thanks,
> Stefaan
>
Problems with floating point rounding errors.
An easy solution:
Scale your scene by 100 and divide the density by 100 and the cross is almost 
gone. Increase that to 1000 and you no longer see the artefacts.

A question: Why use a lathe when you have the cone primitive?

-- 
Alain
-------------------------------------------------
WARNING: The consumption of alcohol may make you think you are whispering when 
you are not.

Post a reply to this message

Alain wrote:
> Problems with floating point rounding errors.
> An easy solution:
> Scale your scene by 100 and divide the density by 100 and the cross is 
> almost gone. Increase that to 1000 and you no longer see the artefacts.

Strange, but it works.  But how can it?  Floating point numbers are 
represented by radix and exponent.  Usually errors are introduced when 
e.g. subtracting two similar numbers, thus challenging the radix' 
accuracy.  Those cannot be solved by such scaling, suggesting the
exponent in the floating point does not suffice to represent 
intermediate results.  Supposing double precision floats, this would 
mean some significant intermediate results are between 2^(-1024) and 
2^(-1024)/1000?
In any case I'm happy to have a workaround, but I'm still trying to 
understand the source of the problems.

> 
> A question: Why use a lathe when you have the cone primitive?
> 

Because I lack adequate knowledge on the primitives :)

Thanks!

Post a reply to this message

Stefaan De Roeck nous apporta ses lumieres en ce 2008/04/10 09:42:
> Alain wrote:
>> Problems with floating point rounding errors.
>> An easy solution:
>> Scale your scene by 100 and divide the density by 100 and the cross is 
>> almost gone. Increase that to 1000 and you no longer see the artefacts.
> 
> Strange, but it works.  But how can it?  Floating point numbers are 
> represented by radix and exponent.  Usually errors are introduced when 
> e.g. subtracting two similar numbers, thus challenging the radix' 
> accuracy.  Those cannot be solved by such scaling, suggesting the
> exponent in the floating point does not suffice to represent 
> intermediate results.  Supposing double precision floats, this would 
> mean some significant intermediate results are between 2^(-1024) and 
> 2^(-1024)/1000?
> In any case I'm happy to have a workaround, but I'm still trying to 
> understand the source of the problems.
> 
>>
>> A question: Why use a lathe when you have the cone primitive?
>>
> 
> Because I lack adequate knowledge on the primitives :)
> 
> Thanks!
In fact, the artefacts are still there, but they become smaller, sub-pixel. When 
you scale up, the integer part become larger. You don't get rounding errors on 
the integer part, only in the fractional part. When you scale up, the fractional 
part become less and less importent, reducing the errors.

-- 
Alain
-------------------------------------------------
After any salary raise, you will have less money at the end of the month than 
you did before.

Post a reply to this message

Stefaan De Roeck nous apporta ses lumieres en ce 2008/04/10 09:42:
> Alain wrote:
>> Problems with floating point rounding errors.
>> An easy solution:
>> Scale your scene by 100 and divide the density by 100 and the cross is 
>> almost gone. Increase that to 1000 and you no longer see the artefacts.
> 
> Strange, but it works.  But how can it?  Floating point numbers are 
> represented by radix and exponent.  Usually errors are introduced when 
> e.g. subtracting two similar numbers, thus challenging the radix' 
> accuracy.  Those cannot be solved by such scaling, suggesting the
> exponent in the floating point does not suffice to represent 
> intermediate results.  Supposing double precision floats, this would 
> mean some significant intermediate results are between 2^(-1024) and 
> 2^(-1024)/1000?
> In any case I'm happy to have a workaround, but I'm still trying to 
> understand the source of the problems.
> 
>>
>> A question: Why use a lathe when you have the cone primitive?
>>
> 
> Because I lack adequate knowledge on the primitives :)
Experiment with the primitives, and gain practical knowlege of them.
> 
> Thanks!
In fact, the artefacts are still there, but they become smaller, sub-pixel. When 
you scale up, the integer part become larger. You don't get rounding errors on 
the integer part, only in the fractional part. When you scale up, the fractional 
part become less and less importent, reducing the errors.

-- 
Alain
-------------------------------------------------
After any salary raise, you will have less money at the end of the month than 
you did before.

Post a reply to this message