>
> In a DF3 file, each value apply to a cube, so, you obviously get a blocky aspect.
> POV-Ray don't use any tessellation. It samples along a ray and evaluate the
> isosurface value at a point, if it evaluate to less than the therhold, you are
> outside the object, it it evaluate at the threshold, you are ON the surface, if
> larger, then you are inside.
> DF3's are mostly used for media dencity where the blockyness is less visible.
>
> --
> Alain
> -------------------------------------------------
> The strongest reason for the people to retain the right to keep and bear
> arms is, as a last resort, to protect themselves against tyranny in
> government.
> Thomas Jefferson


Yes, there is indeed blocky appearance, but i think if there is no any
tessellation, what kind of primitives povray is using to represent the
intersection between a ray and the on-surface cube. And for each
intersection point, its normal should be calculated from the volume data.

Is that possible that povray is just using a rectangle to reprensent the
intersection of the on-surface cube? which is something like billboards,
since it is very efficient. If so, there would be no way to make the
resulting surface  smoother, except using finer volume data.

Post a reply to this message

lien0n wrote:
> to Thorsten:
> Can you give me some comments towards the patches in my image? In fact, I
> want to get a smooth surface from the volume data set. Maybe I used the
> isosurface object incorrectly. the code for the isosurface object is:
> 
> #declare dens=function{pattern {density_file df3 densityfile interpolate 1}}

I would use interpolate 2 and watch the max-gradient messages at the end of
the render, if any.

	Thorsten

Post a reply to this message

> Yes, there is indeed blocky appearance, but i think if there is no any
> tessellation, what kind of primitives povray is using to represent the
> intersection between a ray and the on-surface cube. And for each
> intersection point, its normal should be calculated from the volume data.
>
> Is that possible that povray is just using a rectangle to reprensent the
> intersection of the on-surface cube? which is something like billboards,
> since it is very efficient. If so, there would be no way to make the
> resulting surface  smoother, except using finer volume data.

Pov doesn't tessellate anything ever. All of pov's primitives are
volumetric, or surfaces. Since a DF3 is an array, the
data is represented as cube shaped data, if more than one
ray hits in each data spot it looks blocky because it is blocky.

You might try averaging a bit - interpolate 2 or ...
function{ // untested
   ( dens(x,y,z)
     +dens(x+0.05,y,z) + dens(x-0.05,y,z)
     +dens(x,y+0.05,z) + dens(x,y-0.05,z)
     +dens(x,y,z+0.05) + dens(x,y,z-0.05)
   )/7
}

Post a reply to this message

lien0n nous apporta ses lumieres en ce 17-01-2007 03:52:
>> In a DF3 file, each value apply to a cube, so, you obviously get a blocky aspect.
>> POV-Ray don't use any tessellation. It samples along a ray and evaluate the
>> isosurface value at a point, if it evaluate to less than the therhold, you are
>> outside the object, it it evaluate at the threshold, you are ON the surface, if
>> larger, then you are inside.
>> DF3's are mostly used for media dencity where the blockyness is less visible.

>> --
>> Alain
>> -------------------------------------------------
>> The strongest reason for the people to retain the right to keep and bear
>> arms is, as a last resort, to protect themselves against tyranny in
>> government.
>> Thomas Jefferson


> Yes, there is indeed blocky appearance, but i think if there is no any
> tessellation, what kind of primitives povray is using to represent the
> intersection between a ray and the on-surface cube. And for each
> intersection point, its normal should be calculated from the volume data.

> Is that possible that povray is just using a rectangle to reprensent the
> intersection of the on-surface cube? which is something like billboards,
> since it is very efficient. If so, there would be no way to make the
> resulting surface  smoother, except using finer volume data.


POV-Ray send a ray for each pixel. It then check along that ray if it encounter 
anything, and where. When a surface is found, it's colour is evaluated along 
with it's orientation, the normal, and the placement of any light. This will 
give you the effective colour of that pixel. It can be complicated if the 
surface is reflective or transparent.
It don't use a rectangle to represent the intersection, it's just that the 
effctive surface IS blocky. Yess, the only way to get a finer result, in this 
case, is to use a finer, higher resolution, data set.

-- 
Alain
-------------------------------------------------
If all the world is a stage, where is the audience sitting?

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Attwood wrote:
>> Yes, there is indeed blocky appearance, but i think if there is no any
>> tessellation, what kind of primitives povray is using to represent the
>> intersection between a ray and the on-surface cube. And for each
>> intersection point, its normal should be calculated from the volume data.
>>
>> Is that possible that povray is just using a rectangle to reprensent the
>> intersection of the on-surface cube? which is something like billboards,
>> since it is very efficient. If so, there would be no way to make the
>> resulting surface  smoother, except using finer volume data.
> 
> Pov doesn't tessellate anything ever. All of pov's primitives are
> volumetric, or surfaces.
	Actually, it does tessellate bezier/bicubic patches. You can choose
the tessellation amount with the u_steps, v_steps and flatness
keywords. But that's the only object type that gets tessellated.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFrnxxd0kWM4JG3k8RAnoSAJ0VcOyGeVcxK+Wtha8gqywhsTD5ygCeOH0i
vAojjX39B2Dwxeqqmu3A/Vg=
=wLMo
-----END PGP SIGNATURE-----

Post a reply to this message

"Tim Attwood" <tim### [at] comcastnet> wrote:
>
> You might try averaging a bit - interpolate 2 or ...
> function{ // untested
>    ( dens(x,y,z)
>      +dens(x+0.05,y,z) + dens(x-0.05,y,z)
>      +dens(x,y+0.05,z) + dens(x,y-0.05,z)
>      +dens(x,y,z+0.05) + dens(x,y,z-0.05)
>    )/7
> }

I created two other images at
http://news.povray.org/povray.binaries.images/thread/%3Cweb.45ac7028a8a7f8c81524ae1d0@news.povray.org%3E//povray.binari
es.images/thread/%3Cweb.45ac7028a8a7f8c81524ae1d0@news.povray.org%3E/
You guy's ideas worked, cool.

But for the case of "interpolate 2", the resulting image is quite strange
with compare to the two images of "interpolate 1" whose shape is what I
want, since I use the same threshold value.

Post a reply to this message