Same method as for the image in my "Delving into the bozo world" post.
(But only monochrome colours this time.)

I'll post the source soon.


Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Attachments:
Download 'crackle01.jpg' (161 KB)

Preview of image 'crackle01.jpg'

Tor Olav Kristensen wrote:
> 
> Same method as for the image in my "Delving into the bozo world" post.
> (But only monochrome colours this time.)
> 
> I'll post the source soon.
> 
	Nice, but I'd move the camera slightly up or down to avoid the
horizontal  dark line...

		Jérôme
-- 
********************************* Jérôme M. BERGER
* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy.    * http://www.enst.fr/~jberger
*********************************

Post a reply to this message

Tor Olav Kristensen wrote:

> ...
> I'll post the source soon.

I have now posted it to povray.text.scene-files:

news://news.povray.org/39EDBC5D.65D00C77%40hotmail.com


After studying the image, I have now found that there seems to
bee some problems with this rendering: Some of the spheres are
not completely round and some "false" odd shaped shadows
appear.

See the first attached image.
(Yellow arrows for cut spheres and red arrows for false shadows.)

Has anyone else seen these kind of errors with iso-surfaces before ?

If I remove my no_shadow keyword from the code, then many
more "odd shaped" shadows appear. See the last attached image.


Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Attachments:
Download 'isoerrors.jpg' (29 KB) Download 'isoshadows.jpg' (31 KB)

Preview of image 'isoerrors.jpg'

Preview of image 'isoshadows.jpg'

"Jérôme M. Berger" wrote:

> ...
>        Nice, but I'd move the camera slightly up or down to avoid the
> horizontal  dark line...

When I first rendered this image I got 3 such lines.
Back then I decided that I would remove 2 of them (vertical).

I kind of liked the third one (the horizontal), so I kept it.

But now I agree with you -It too has to go.

Thank you for commenting.


Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Tor Olav Kristensen schrieb in Nachricht <39EDC0F6.9E6AFC2B@hotmail.com>...

>Has anyone else seen these kind of errors with iso-surfaces before ?
>


Yes, degenerated forms like your cut spheres. I decreased the accuracy-value
and everything was good ... well, not everything: Rendertime increased quite
a bit.

BTW: nice image!

Hope it helps,

Marc-Hendrik

Post a reply to this message

Or wait ... wasn't it max_gradient? Yes, ... eval gave me some really big
values .... some percentages of that where enough to eliminate the visible
cuts (25 instead of 1045 or something like that).

Sorry

Marc-Hendrik

Marc-Hendrik Bremer schrieb in Nachricht <39edcafa@news.povray.org>...
>
>Tor Olav Kristensen schrieb in Nachricht <39EDC0F6.9E6AFC2B@hotmail.com>...
>
>>Has anyone else seen these kind of errors with iso-surfaces before ?
>>
>
>
>Yes, degenerated forms like your cut spheres. I decreased the
accuracy-value
>and everything was good ... well, not everything: Rendertime increased
quite
>a bit.
>
>BTW: nice image!
>
>Hope it helps,
>
>Marc-Hendrik
>

Post a reply to this message

Tor Olav Kristensen wrote:
> 
[...]
> 
> After studying the image, I have now found that there seems to
> bee some problems with this rendering: Some of the spheres are
> not completely round and some "false" odd shaped shadows
> appear.
> 
> See the first attached image.
> (Yellow arrows for cut spheres and red arrows for false shadows.)
> 
> Has anyone else seen these kind of errors with iso-surfaces before ?
> 
> If I remove my no_shadow keyword from the code, then many
> more "odd shaped" shadows appear. See the last attached image.
> 

I had a quick look at the code, your isosurface function does have abrupt
changes of values and those often cause problems (i had problems when using
object_pattern in isosurface functions for example) increasing max_gradient or
accuracy might help, but in general functions with abrupt changes are not ideal
for isosurface functions.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <39EDC0F6.9E6AFC2B@hotmail.com>, Tor Olav Kristensen 
<tor### [at] hotmailcom> wrote:

> After studying the image, I have now found that there seems to
> bee some problems with this rendering: Some of the spheres are
> not completely round and some "false" odd shaped shadows
> appear.

In addition to the things mentioned by others(max_gradient, 
discontinuous functions...), you may be finding too few intersections. 
Try raising max_trace...maybe use "max_trace all_intersections". (going 
from memory here...I have never actually used this feature)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Now this looks like some sort of mythical ice cave. 

-- 
Cheers
Steve              email mailto:ste### [at] zeroppsuklinuxnet

%HAV-A-NICEDAY Error not enough coffee  0 pps. 

web http://www.zeropps.uklinux.net/

or  http://start.at/zero-pps

 11:50pm  up 8 days,  1:10,  2 users,  load average: 1.06, 1.08, 1.03

Post a reply to this message

Marc-Hendrik Bremer wrote:

> Or wait ... wasn't it max_gradient? Yes, ... eval gave me some really big
> values .... some percentages of that where enough to eliminate the visible
> cuts (25 instead of 1045 or something like that).

I have just started a test rendering with max_gradient set to 150.
And it looks promising so far...

=)


Thanks !

Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Christoph Hormann wrote:

> Tor Olav Kristensen wrote:
> ...
> > Has anyone else seen these kind of errors with iso-surfaces before ?
> ...
>
>
> I had a quick look at the code, your isosurface function does have abrupt
> changes of values and those often cause problems (i had problems when using
> object_pattern in isosurface functions for example) increasing max_gradient or
> accuracy might help, but in general functions with abrupt changes are not ideal
> for isosurface functions.

I was not aware of problems with such functions.

I'll bear it in mind till my next isosurface project.


I don't know what an object_pattern is, but I'll try to read some more in the
MegaPOV documentation.

Thanks again.


Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Steve wrote:

> Now this looks like some sort of mythical ice cave.

It reminds me of caves too.

Theses images gives me some vague associations to a
Donald Duck story that I read when I was a child:

There were thousands of small round stones in some
enormously large underground cave systems.

These small round stones appeared to be living
creatures that caused earth quakes when collectively
rolling and colliding against the columns that supports
the surface of the earth.


Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

In article <39EE356F.10561BCA@hotmail.com>, Tor Olav Kristensen 
<tor### [at] hotmailcom> wrote:

> I don't know what an object_pattern is, but I'll try to read some 
> more in the MegaPOV documentation.

He was talking about the "object" pattern. It is a list pattern, like 
hexagon or checkers, but it chooses between the colors/pigments/etc. 
depending on whether a point is inside or outside of a specified object. 
You can use it as a text pattern...just use a text object in the pattern.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Wow... I saw a cartoon version of that story... Do you remember the
name...?

BTW... I like this one the best... The monochrome color really adds to
the depth of the image...

Tor Olav Kristensen wrote:

> Steve wrote:
>
> > Now this looks like some sort of mythical ice cave.
>
> It reminds me of caves too.
>
> Theses images gives me some vague associations to a
> Donald Duck story that I read when I was a child:
>
> There were thousands of small round stones in some
> enormously large underground cave systems.
>
> These small round stones appeared to be living
> creatures that caused earth quakes when collectively
> rolling and colliding against the columns that supports
> the surface of the earth.
>
> Tor Olav
> --
> mailto:tor### [at] hotmailcom
> http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

i DL the source but i do not understand the if statement you referred to
...

I let the iso-surface do the work itself.
(-By using a pigment function inside an if statement. If the pigment
value in the middle of a "subcube" in 3D-space is above a certain
limit/threshold, a function is called to make a sphere in this
"subcube".
Else a constant outside the limit is returned.)

What does this statement exactly do... Or better yet how does it do what
it does...
How are the arguments read...?

if(
      MidOfCrackleSquare(x, y, z) - Threshold,
      ManySpheres(x, y, z),
      1
    )

Im guessing if mid of crackle square... then do many spheres... what is
the 1... threshold...?
please help,

Post a reply to this message

SomeGuy wrote:

> Wow... I saw a cartoon version of that story... Do you remember the
> name...?

No, I'm sorry. It's too many years ago (20++).


> BTW... I like this one the best... The monochrome color really adds to
> the depth of the image...

Thanks.


Regards,

Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html


> Tor Olav Kristensen wrote:
> > ...
> > Theses images gives me some vague associations to a
> > Donald Duck story that I read when I was a child:
> >
> > There were thousands of small round stones in some
> > enormously large underground cave systems.
> >
> > These small round stones appeared to be living
> > creatures that caused earth quakes when collectively
> > rolling and colliding against the columns that supports
> > the surface of the earth.

Post a reply to this message

SomeGuy wrote:

> i DL the source but i do not understand the if statement you referred to
> ...
>
> I let the iso-surface do the work itself.
> (-By using a pigment function inside an if statement. If the pigment
> value in the middle of a "subcube" in 3D-space is above a certain
> limit/threshold, a function is called to make a sphere in this
> "subcube".
> Else a constant outside the limit is returned.)
>
> What does this statement exactly do... Or better yet how does it do what
> it does...
> How are the arguments read...?
>
> if(
>       MidOfCrackleSquare(x, y, z) - Threshold,
>       ManySpheres(x, y, z),
>       1
>     )
>
> Im guessing if mid of crackle square... then do many spheres... what is
> the 1... threshold...?
> please help,

I find this difficult to explain, but I'll give it a try.

Here I go:
(Anyone please correct me if I'm telling any lies here.)

For "every" point inside the contained_by shape, find out which
cube in 3D-space this point is contained within.
(E.g. The point <3.4, 7.8, 0.1> is contained within the cube
with opposite corners <3, 7, 0> and <4, 8, 1>.)

Find the middle of this cube and fetch the field strength for the
crackle pattern at that midpoint. (E.g.: The midpoint of the cube
above is <3 + 0.5, 7 + 0.5, 0 + 0.5> = <3.5, 7.5, 0.5>)

(The MidOfCrackleSquare function calculates the coordinates
for these midpoints. {A better name for this function would have
been MidOfCrackleCube.} The MidOfCrackleSquare calls the
CrackleFunction and passes the midpoint to it. The
CrackleFunction returns the "field strength" value at this point.)

Then the field strength is checked if it is above a certain
"Threshold" limit. If it is, then the point belongs to a set of points
that "later" will be evaluated as candidates for being inside a
sphere within the cube.

All such points that are found to be inside such a cube with
an "OK" threshold in it's middle are evaluated with the
ManySpheres function.

If they are found to be inside a cube with a "wrong" threshold
in its middle, they are "assigned" with a value that guarantees
that they are not candidates for being considered as "insiders"
to the isosurface.

The ManySpheres function translates the point given it
to a corresponding position within a similar cube centred
around origo.

Then the ManySpheres function calls the built in "sphere"
function that calculates how far the translated point is from
the surface of a sphere centred around origo. (It returns
positive values if the translated point are outside the sphere.
0 if it's on the sphere's surface, and negative values if it's inside
the sphere.)

The result of this is that the original point is assigned the same
value as it's translated version.

One can imagine that after "all" points inside the contained_by
shape have been evaluated, they have been assigned a value
that now are checked to see if they are inside, outside or on
the isosurface.

All the points that was not assigned a "guaranteed not insiders"
value, are now candidates for being _on_ the isosurface or
inside it.

The float after the isosurface's threshold keyword gives the
potential that the value of every such points is checked against.

If a point has an "assigned" value that is equal to this potential,
then it is _on_ the isosurface. If its value is greater than this
potential, then the point is outside the isosurface, and if its value
is less than this potential, then the point is inside the isosurface.

So if the isosurface shape is not involved in any CSG-operations
then only the points that are _on_ the isosurface are "visible".


Notes:

To find the radii of the spheres in the image, just add the
the value after the threshold keyword (0.2) to the radius
given to the built in function "sphere" (0.2). Thus the radius
of all the spheres are 0.4.

To find a suitable value to be assigned to "guaranteed not
insiders" points, one can select a value just above the value
after the threshold keyword (0.2). I had not reflected much
about this, so I chose the value 1. (0.21 would have been
sufficient.)


Feel free to ask more if there's anything that needs more
explaining.

Below are some code made for playing around with my
ManySpheres function.

P.S.:
Try to uncomment the commented lines different combi-
nations (At different resolutions and AA settings)

Tor Olav
--
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version unofficial MegaPov 0.5;
#include "colors.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare SphereFunction = function { "sphere" <0.1> }

#declare ManySpheres =
function {
  SphereFunction(
    x - floor(x) - 0.5,
    y - floor(y) - 0.5,
    z - floor(z) - 0.5
  )
}

isosurface {
  function { ManySpheres(x, y, z) }
//  threshold 0.1
  contained_by { sphere { <0, 0, 0>, 200 } }
//  method 1
  pigment { color Yellow }
  no_shadow
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

background { color Blue/2 }

//light_source { 1000*<-3, -4, 2> color White*2 }
light_source { 1000*<0, 1, 0> color White*2 }

camera {
  location <0, 0, -10.5>//*60
  look_at <0, 0, 0>
//  angle 35
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

Post a reply to this message