 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
imho ISOsurface is the most flexible and powerfull future in Pov :)
Only disadvantage is it's speed in some cases.
I have idea for a opimization, that in some cases can prove _realy_ fast.
Let's think about iso in shape like :
.....
. .
..*..
. .
.....
the '.' border shaphe is quite smooth, and in tha areas max gradient is
about 0.1
but center '*' shape is very sharpl, and it's max gradient is 50.0
so entire ISO is calculated with gradient 50.0
but if we divide ISO to separate iso's with diffrent max_gradient it will
ernder much faster. Problem with using i.e. union/merge of smal ISO's is
that ther will be some artefacts in places where elements touches
togeather.
I will soon prepare some examples (images+code), ideas how toimplement it,
and suggested syntax. Do You find this idea interesting ?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rafal 'Raf256' Maj" <raf### [at] raf256 com> wrote in message
news:Xns### [at] 204213191226...
>
> imho ISOsurface is the most flexible and powerfull future in Pov :)
>
> Only disadvantage is it's speed in some cases.
> I have idea for a opimization, that in some cases can prove _realy_ fast.
>
Been there, done that ;)
Of course, it depends on knowing quite a lot about the eventual shape of the iso
and where the requirements for a high max gradient will be.
I've also combined it with other time-savers - consider a ridged mf landscape
with high peaks in the distance, but a central plane.
Not only does it make sense to muck around with different max gradients, but
different bounding as well, since the high bounding box required for the distant
peaks is very redundant on the near plane.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj wrote:
>
> imho ISOsurface is the most flexible and powerfull future in Pov :)
>
> Only disadvantage is it's speed in some cases.
> I have idea for a opimization, that in some cases can prove _realy_ fast.
>
> [...]
A few thoughts about that:
It's out of question that the isosurface intersection test is something
that could be improved. There are various possible approaches to achieve
speed improvements, for example based on precalculations and caching of
function values. What's most important for such an improvement IMO is
that it should not be too specialized for a particular type of function.
And you should probably be careful when promising an enormeous speed
improvement.
Concerning your suggestion, you should probably try out 'evaluate' and
play with the parameters, dividing a larger isosurface into smaller ones
is a useful trick, but the borders are often a problem, especially if you
also use different accuracy values.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 03 Aug. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote in
news:3D4E948F.6A8571BB@gmx.de
>> Only disadvantage is it's speed in some cases.
>> I have idea for a opimization, that in some cases can prove _realy_
>> fast.
> A few thoughts about that:
> It's out of question that the isosurface intersection test is
> something that could be improved.
so I'll be hepay to help in improving it :)
> There are various possible
> approaches to achieve speed improvements, for example based on
> precalculations and caching of function values.
> What's most important
> for such an improvement IMO is that it should not be too specialized
> for a particular type of function.
it's useful for all functions
> And you should probably be careful when promising an enormeous speed
> improvement.
I'm preparing some tests right now :)
> Concerning your suggestion, you should probably try out 'evaluate' and
> play with the parameters, dividing a larger isosurface into smaller
> ones is a useful trick, but the borders are often a problem,
> especially if you also use different accuracy values.
yes, that's wy I want that future to be coded into POV, and using union
{...} of iso's is just for testing purpose, because it doesn't take into
account artefacts on borders of bounding boxes
--
#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:
> 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.
> but if we divide ISO to separate iso's with diffrent max_gradient it will
> ernder much faster. Problem with using i.e. union/merge of smal ISO's is
> that ther will be some artefacts in places where elements touches
> togeather.
How do you propose to do this? Have the user create another function
describing the gradient of the isosurface function?
You would need a smoothly varying value for the reason you mentioned, it
will create artifacts otherwise. Automatically analyzing the function
and creating the gradient function is not practical. One possible
alternative would be to create a voxelfield of gradient values over the
isosurface and use that for the gradient value...this could use quite a
bit of memory though, and add overhead which would just slow down other
functions, so you would definitely want a way to turn it off.
--
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
> First, *it is not ISOsurface*! The word is "isosurface", the "iso"
> How do you propose to do this?
> One
> possible alternative would be to create a voxelfield of gradient
> values over the isosurface and use that for the gradient value...this
yes, and in addition :
> could use quite a bit of memory though, and add overhead which would
> just slow down other functions, so you would definitely want a way to
> turn it off.
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
--
#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:
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
