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