In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> slow down ? no, why ? maybe in some rare cases. Idea is to use voxelfield, 
> maybe optimized into set of boxes, in some examples it will work perfect, 
> please wait just a minut, I will post a full example

Yes, slow down. Computing a value from a voxel field is obviously slower 
than using an existing variable. It would have to be computed for each 
end of each interval, instead of just using the same variable and value 
for all intervals. It would not be extremely slow, but it would slow 
down functions which don't need the "gradient map", so you would 
definitely want an option to turn it off and use a constant max gradient 
value.

"optimized into set of boxes"...what do you think voxels are?

And the memory...assume 32 bit floats are used instead of 64 bit 
doubles, for compactness. A 128*128*128 field would have 2,097,152 
voxels of 4 bytes each...8 megabytes for the gradient map for that 
isosurface. You could reduce precision further, but converting it into a 
float or double value for the calculations will add more overhead.

-- 
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

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

> Yes, slow down. Computing a value from a voxel field is obviously
> slower than using an existing variable. 

not computing is needed, this voxel field will have no interpolation

just, for pixels in <0,0,0>-<1,1,1> tak max_gradient 2.0 
etc

> "optimized into set of boxes"...what do you think voxels are?

voxel is a set of SAME SIZE boxes, and therefore :
 
> And the memory...assume 32 bit floats are used instead of 64 bit 
> doubles, for compactness. A 128*128*128 field would have 2,097,152 

while I was thinking of something that.. hmm how to say it... like uhm 
antialias, or 3d version of binary-tree 

2d example for this :

11112222 start with 4 cubes and calcualte theirs max gradient.
11112222 if gradient is same in all 4 (or almost simmilar in some
33334444 threshold) -  make 1 cube with, end finish, if not :
33334444

1122  for each of 4 cubes, divide it into 4 smaller cubes, and repeat
3344  previous step

as in AA, we need to define max-recursion-level and threshold

example, we have a box and torus :

***
***
***  ** 
    *  *
     ** 

we will need :
- one big box in upper-left that covers ball,
- 2 boxes in lower-left and upper-right with max-gradient = 0
- several small boxes that will describe quite compicated shape of torus
- one medium box inside in torus with max_grad = 0 (hole in torus)

so we will need about 10 boxes, now think about :

************
************
************
************ 
*************
          *  *
           **

1 biig box + 3..10 smaller will describe this shape, as well as
regular gird of about 20x10 pixels

in 3d this approach will give even better results

implementation  - 'binary' tree, but each node wil have 4 sons, not 2



-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> > Yes, slow down. Computing a value from a voxel field is obviously
> > slower than using an existing variable. 
> 
> not computing is needed, this voxel field will have no interpolation
> 
> just, for pixels in <0,0,0>-<1,1,1> tak max_gradient 2.0 
> etc

Have you ever done any programming? It doesn't sound like it.
You still have to find the correct voxels and get their value. It is 
very obvious that this will have more overhead than simply using a 
single value.
BTW, I was wrong: you wouldn't just need the gradient value at each end 
of each interval, you would need the gradient values for all the voxels 
the interval goes through. That's quite a bit more overhead...best thing 
would probably be to build a list of all voxels the ray passes through 
and process using the list instead of directly accessing the voxel 
field, sub-intervals could then just use segments of this list. And it 
still isn't foolproof, there could be a high gradient area that falls 
between the voxel samples, though you could supersample the voxels to 
reduce that risk, at a cost of increasing the parse time. It would be 
considerably slower than accessing a constant max_gradient, though it 
might be fast enough to speed up some surfaces.


> while I was thinking of something that.. hmm how to say it... like uhm 
> antialias, or 3d version of binary-tree 

You are thinking of something closer to lossy compression, throwing out 
low-amplitude variations. I believe you are talking about an oct-tree, 
each node is a cube divided into 8 sub-cubes...that could help reduce 
the memory requirements if you are willing to throw away information, 
which shouldn't be a problem for this. In some cases where there is a 
lot of variation in the gradient, it would require more memory...most of 
the voxels and a lot of node pointers. It would also make it even slower 
to find a particular voxel: you would have to descend the tree instead 
of just accessing an element of an array.

-- 
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

Another approach instead of working with different max gradients is to use 
the second derivatives instead of the first one. So instead of the max 
gradient the max second derivative Cmax of the function has to be specified 
(is there a math expression for that? curvature?). Then, if you have the 
function evaluated at some point p0 with value v0 and approximated gradient 
g0 (which you can do by taking a second point as it is done in normal 
calculation) you place a polynom of order 2 which fits the point and the 
gradient at p0 and has the curvature Cmax. You know then that there is no 
root between p0 and the roots of the polynomial.

This will work well with many functions. Problems can arise with functions 
that are not differentiable. 

I have implemented a version that works with the second derivative for 
isosurfaces in my own raytracer (written in java though). If anybody wants 
I can send him/her the source code. 

- Micha

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
5AF### [at] netplexaussieorg

>> just, for pixels in <0,0,0>-<1,1,1> tak max_gradient 2.0 
>> etc

> Have you ever done any programming? It doesn't sound like it.

http:\\www.raf256.com at bottom of page - this are programs from primary 
school times

> You still have to find the correct voxels and get their value. It is 
> very obvious that this will have more overhead than simply using a 
> single value.

we will see...


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> > You still have to find the correct voxels and get their value. It is 
> > very obvious that this will have more overhead than simply using a 
> > single value.
> 
> we will see...

It is pretty obvious. In fact, it is so blindingly obvious I don't see 
how you could possibly think otherwise. Here is the code for accessing 
the max gradient now:

ISOSRF->max_gradient

Now think about the code for grabbing the max gradient from a voxel 
field. Even if you do it the wrong way, and check a single voxel from a 
3D array, you would end up with something like:

ISOSRF->gradientField
[floor(ISOSRF->gfXRes*(Point[X] - ISOSRF->gfMin[X])/ISOSRF->gfSize[X])]
[floor(ISOSRF->gfYRes*(Point[Y] - ISOSRF->gfMin[Y])/ISOSRF->gfSize[Y])]
[floor(ISOSRF->gfZRes*(Point[Z] - ISOSRF->gfMin[Z])/ISOSRF->gfSize[Z])]

gradientField is a 3D array of floats, gfXRes, gfYRes, and gfZRes are 
the integer xyz resolutions of the voxel field, gfMin is the minimum 
extent of the field, gfSize is the size of the field. No safety checking 
to make sure it stays in the array bounds.

That gets you the gradient at a single voxel assuming the simplest kind 
of voxel structure you can have. What you actually need is the maximum 
gradient of all the voxels the current interval passes through. The best 
way to do this would probably be to get all of the voxels the entire ray 
passes through and put them in a sorted list, and go through sections of 
this list for each interval. That would be much, much more overhead than 
a simple struct member access. It might speed up some isosurfaces which 
have a few areas with very high gradients, but it would slow down others.

-- 
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

In article <3d4ec56e@news.povray.org>, Micha Riser <mri### [at] gmxnet> 
wrote:

> I have implemented a version that works with the second derivative for 
> isosurfaces in my own raytracer (written in java though). If anybody wants 
> I can send him/her the source code. 

This sounds interesting...are you going to make the source code for your 
tracer public?

-- 
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

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
DD2### [at] netplexaussieorg

> field. Even if you do it the wrong way, and check a single voxel from a 
> 3D array, you would end up with something like:
> 
> ISOSRF->gradientField
> [floor(ISOSRF->gfXRes*(Point[X] - ISOSRF->gfMin[X])/ISOSRF->gfSize[X])]
> [floor(ISOSRF->gfYRes*(Point[Y] - ISOSRF->gfMin[Y])/ISOSRF->gfSize[Y])]
> [floor(ISOSRF->gfZRes*(Point[Z] - ISOSRF->gfMin[Z])/ISOSRF->gfSize[Z])]

no, it;s not exacly what I ment, the voxels is in fact Yours suggestion, I 
ment something bit different. Now i'm rendering few tests, it's almost 
clear that in meany cases using my little idea improves speed about 50%, 
full examples + sources will be place soon (one test without optimization 
renders 5 h  iwanted even tests to look nice ;)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote:
> In article <Xns### [at] 204213191226>,
>  "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
>
> > imho ISOsurface is the most flexible and powerfull future in Pov :)
>
> First, *it is not ISOsurface*! The word is "isosurface", the "iso" used
> here is not an acronym for anything, isosurface just means equipotential
> surface, a surface where a function is equal to a certain potential or
> threshold value.

Oooh... I was eagerly waiting for the next release of POV-Ray so I could
play with ANSI surfaces and DIN surfaces :-)

(Sorry, I couldn't resist :-P)

-- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

Christopher James Huff wrote:

>
> This sounds interesting...are you going to make the source code for your
> tracer public?
>

I plan to release it under GPL once I think it is worth to do so... but I 
can't say if this is within a month or half a year.

-- 
http://objects.povworld.org - the POV-Ray Objects Collection

Post a reply to this message