Hi,
realy couldn't find one thing in manual... there AFAIR was some pattern 
(used i.e. in media) that value in <x,y,z> was equal to distance beetwen 
<x,y,z> and some object

so it works like object{} pattern, but it can be used with color_map etc

ther was some example represanting media looking like letter 'H'

is this pattern available in Pov 3.5 ?

-- 

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> Hi,
> realy couldn't find one thing in manual... there AFAIR was some pattern 
> (used i.e. in media) that value in <x,y,z> was equal to distance beetwen 
> <x,y,z> and some object

  If there would be a fast way of determining the distance of a point from
the surface of an object, that would be more or less a holy grail of
raytracing. (Among other things it would allow you to create an isosurface
identical to any given object and then just transform it non-linearly.)

  The sad fact is that there's no generic way of calculating this distance
fast and accurately for any given object.
  The patch you are referring to _approximated_ the distance by shooting
many rays towards the object and taking the one which hit the object at
closest distance. Of course this has two drawbacks: It's not very accurate
(usually introduces bad graininess) and it's very slow.

  There was a discussion some time ago (I think initiated by me) that the
distance calculation could be optimized in a per-primitive basis (for many
primitives getting the accurate distance fast is quite easy), as well as
developing a proper algorithm for calculating it analytically for a CSG
object. (Of course there are objects where you *can't* get the accurate
distance from the surface, eg. the 4D julia object. For some objects it
might not be unambiguous which distance is the correct one.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3d2b8f5f@news.povray.org:

>> realy couldn't find one thing in manual... there AFAIR was some
>> pattern (used i.e. in media) that value in <x,y,z> was equal to
>> distance beetwen <x,y,z> and some object
>   If there would be a fast way of determining the distance of a point
>   from 
> the surface of an object, that would be more or less a holy grail of
> raytracing. (Among other things it would allow you to create an
> isosurface identical to any given object and then just transform it
> non-linearly.) 
 
>   The sad fact is that there's no generic way of calculating this
>   distance 
> fast and accurately for any given object.
>   The patch you are referring to _approximated_ the distance by
>   shooting 

is this future available in Pov 3.5 and what is it's name ?

> many rays towards the object and taking the one which hit the object
> at closest distance. Of course this has two drawbacks: It's not very
> accurate (usually introduces bad graininess) and it's very slow.

Well - it should be easy to optimize it :) 
if you do NOT need information about normal of object, but only of 
distance, why not add future like

pixelized {
  object ...
  100,100,100
}

that will create 100x100x100 bits arrar - informing is some point inside 
object or not. In addition - it will be very fast to use, and object size 
(maybe speed) can be optimized using binary trees (or something simmilar).

For 'pixelized' object (as well as for some primitives) functions 
returining distance from <x,y,z> to object will be very fast.

I can implement it, in fact I would be heapy to, but I need little help - I 
realy do NOT like modyfing somones other code, especialy when its so big 
and complex as Pov's source. So I will write individual program realizating  
this algorith and if You will like it - maybe somebody will actualy use it 
in Pov.

How code should look to be easy to link with Pov ? 
My suggestion - program wil
Use functions of PovRay :
bool Inside(int x,int y,in z); // is point inside of some object

Give functions 
void BuildTab(); // build i.e. 100x100x100 array
void FreeTab(); // free
double Distance(float x,float y,float z); // distance from point to
  // object

I can alsow ofcourse implement above for sphere,box,cone,torus and maybe 
few other primitives


-- 

Post a reply to this message

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in
news:Xns### [at] 204213191226: 

Full example "

#declare pix = pixelized {
  object { some_complex_object }
  100,100,100
}

#declare d1=density {
  distance { pix } 
  distance { box { /* ... */ } } 
  distance { sphere } 
  distance { blob { ... } }  // error, or use future with shooting many 
  // rays
}


so in fact - pixelized its just a creation of df3 data while parsing,
functions like
save_data
load_data 
would be alsow useful

-- 

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> is this future available in Pov 3.5 and what is it's name ?

  I thought that I made clear that the patch was highly experimental.
  They didn't include highly experimental and incomplete patches to 3.5.

> Well - it should be easy to optimize it :) 
> if you do NOT need information about normal of object, but only of 
> distance, why not add future like

> pixelized {
>   object ...
>   100,100,100
> }

> that will create 100x100x100 bits arrar - informing is some point inside 
> object or not.

  Uh... I didn't understand this at all. What does it help to know if
a point is inside an object or not, when you are calculating the distance
of a point from the surface of the object?

  And besides, insideness test is not a problem (it's required for CSG and
perhaps some other things, and in pov3.5 they even added it to the SDL so
that you can use it in your scenes; it's the inside() function).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3d2ba80d@news.povray.org:


>> that will create 100x100x100 bits arrar - informing is some point
>> inside object or not.
>   Uh... I didn't understand this at all. What does it help to know if
> a point is inside an object or not, when you are calculating the
> distance of a point from the surface of the object?

in worst case - You can just shut rays at object, as it was in test wersion 
of distance pattern, but it will by much faster to test intersection of 
pixelized rather then i.e. isosurface or complex CSG

> And besides, insideness test is not a problem (it's required for CSG
> and 
> perhaps some other things, and in pov3.5 they even added it to the SDL
> so that you can use it in your scenes; it's the inside() function).

I only suggested : why not optimize (using pre-calculated array) this 
tests, that will result in faster shooting rays and i.e. speeding up 
distance calculations

-- 

Post a reply to this message

On 9 Jul 2002 21:17:50 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Hi,
> realy couldn't find one thing in manual... there AFAIR was some pattern 
> (used i.e. in media) that value in <x,y,z> was equal to distance beetwen 
> <x,y,z> and some object

For basic primitives this can be realized without internall support. Take a
look at my 'rounded' addition to iso_csg library
(http://www-public.tu-bs.de:8080/~y0013390/pov/ic/). It can be even faster
than internall pattern since it is optimized for shapes and not use rays like
original proximity pattern. It is also accurate unless you not use strange
transformations or complicated CSGs.

For more complicated shapes it can be realized with my
blurred/distance/proximity solution (unfortunatelly final macro is not
finished becouse of bugs I found during betatesting but initial version should
work).

http://news.povray.org/povray.binaries.images/22100/
http://news.povray.org/povray.binaries.images/22745/
http://news.povray.org/povray.text.scene-files/22075/


ABX

Post a reply to this message

On 9 Jul 2002 23:01:00 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> pixelized {
>   object ...
>   100,100,100
> }
>
> that will create 100x100x100 bits arrar - informing is some point inside 
> object or not. In addition - it will be very fast to use, and object size 
> (maybe speed) can be optimized using binary trees (or something simmilar).

No need for patching. It is already done in my implementation of distance
pattern via functions.

> I realy do NOT like modyfing somones other code, especialy when its so big 
> and complex as Pov's source.

If you really want to help POV or You want work in any team professionally you
should learn to work with other sources. Moreover POV sources are complex in
total size but basic in general raytracing algorithms and are builded very
clear. Yes, there is no so much comments but identifiers are usually
selfexplaining.

ABX

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> in worst case - You can just shut rays at object, as it was in test wersion 
> of distance pattern, but it will by much faster to test intersection of 
> pixelized rather then i.e. isosurface or complex CSG

  Really? Can you give me actual measurements of this?
  Besides, you will just get a "pixelized" distance pattern (ie. the pattern
will be formed of cubes). How is that useful?

> I only suggested : why not optimize (using pre-calculated array) this 
> tests

  Because insideness test is already very fast. As I said, that's not the
problem. However, a fast insideness test does not help resolving the
distance from the surface of the object.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3d2b8f5f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   There was a discussion some time ago (I think initiated by me) that the
> distance calculation could be optimized in a per-primitive basis (for many
> primitives getting the accurate distance fast is quite easy), as well as
> developing a proper algorithm for calculating it analytically for a CSG
> object. (Of course there are objects where you *can't* get the accurate
> distance from the surface, eg. the 4D julia object. For some objects it
> might not be unambiguous which distance is the correct one.)

That is an optimization that I've been planning on for nearly as long as 
the proximity pattern has existed...I'm going to do a fairly complete 
rewrite of the patch, making something that is simpler to use and 
generally faster. I'm going to do something similar for the glow patch 
as well...the two patches are going to be pretty closely tied together.

To answer the question: no, the proximity pattern was not added to POV 
3.5...it never got beyond the experimental stage, and wasn't even close 
to being ready for the official version. The object pattern did make it, 
and it can be used to get a somewhat similar effect where the pattern 
value depends on the percentage of nearby space filled by the object. 
This is not proximity, and it is a bit slow, but it might do what you 
need.

And the "pixelize" idea (which would really be "voxelize") has its own 
problems: the voxel field takes up a huge amount of memory, and even 
with interpolation you get grid artifacts if the resolution is too low. 
It doesn't require a patch though...if I recall correctly, there are 
other patches in MegaPOV that would make it possible. The official 
POV-Ray 3.1 has a density file pattern, and a MegaPOV patch made it 
possible to generate the field from within the scene file. (this might 
have made it into 3.5, I don't remember)
A patch adding features for generating and processing voxel information 
would be useful though. There are a lot of things that could be done to 
extend the current capabilities.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message