Jellby <me### [at] privacynet> wrote:
> Among other things, Warp saw fit to write:
>
> >>>    No matter how long I look at it, I see bubbles, not craters.
> >>
> >> No matter how long I look at it, I see craters, not bubbles. ;)
> >
> >    Deducing from your smiley I assume it's not true.
>
> No, it's true, even though the light comes from below, I have no problem
> seeing craters and I just can't get my brain to "see" bubbles.

Just flip it... craters will turn into bubbles.. or bubbles will turn into
craters.  Same thing happens when I see bubbles--I mean craters on the
moon.

Post a reply to this message

"Mike Sobers" <sob### [at] mindspringcom> wrote:
> I compiled the crater field generator code by PM 2Ring with a few
> modifications:

Thanks, Mike. To be truthful, the original crater code is by John Walker of
Autodesk (& Fourmilab) and Rudy Rucker developed the random distribution
algorithm. I just fixed it up a little bit & made it output as a
heightfield.

> New functionality:
>
> 1) If desired, large craters can now have a central peak.

Excellent! FWIW, the main crater code conserves volume, although this is
disturbed a bit by the code that 'blends' the outer wall onto the existing
ground. The program assumes that the volume of the impacting meteor is
negliglible, so I suppose it's also ok to ignore the extra volume of the
central peak.

> 2) You can specify erosion - the program will average the pixels the
> specified
> number of times to simulate eroded craters.

That's very handy for places like Mars.

> 3) Output is to .bmp instead of PGM.  Unfortunately, in this current version
> it's a 24-bit file with only 8 bits of info, so an 8000 x 8000 crater field
> produces an output file somewhere around 187 MB.  But you can always
> convert to .png after you make the .bmp output file.  Maybe I'll eventually
> re-write this to produce 16-bit output (.pgm, .tga, or .png).

I stuck with PGM because many NetPBM programs can process data in a
pipeline, reading line by line, so you can avoid writing huge files to
disk. BMP isn't so good for POV since it can only be read & written by the
Windows version, IIRC.

Funny, I was just thinking about fixing it do 16 bit on the weekend...

> Also, maybe I'll create an option to import an existing hightfield.  That
> would allow you to use a pregenerated landscape and then subject it to a
> meteor storm.  Thoughts?

Sounds good to me, and it shouldn't be too hard to implement.

Post a reply to this message

"PM 2Ring" <nomail@nomail> wrote:
> "Mike Sobers" <sob### [at] mindspringcom> wrote:
> > I compiled the crater field generator code by PM 2Ring with a few
> > modifications:
>
> Thanks, Mike. To be truthful, the original crater code is by John Walker of
> Autodesk (& Fourmilab) and Rudy Rucker developed the random distribution
> algorithm. I just fixed it up a little bit & made it output as a
> heightfield.
>

> I stuck with PGM because many NetPBM programs can process data in a
> pipeline, reading line by line, so you can avoid writing huge files to
> disk. BMP isn't so good for POV since it can only be read & written by the
> Windows version, IIRC.
>
> Funny, I was just thinking about fixing it do 16 bit on the weekend...
>
> > Also, maybe I'll create an option to import an existing hightfield.  That
> > would allow you to use a pregenerated landscape and then subject it to a
> > meteor storm.  Thoughts?
>
> Sounds good to me, and it shouldn't be too hard to implement.

If you want, I can post a link to the source files, and hand the project
back over to you. I don't think I'll have time to work on them much in the
near future.  The only reason I went to BMP is because I am using Windows,
and I wanted immediate feedback on the look of the craterfield.  Also, the
random number generator didn't work when I compiled it under Microsoft
Visual Studio (something about the syntax on the bit shift commands) so it
only produced 1 crater at X,Y = 0,0.  Other than that, it would probably be
better to have a PGM output, especially since that could get you to 16 bit.
I was going to include .jpg and .png output options, but I didn't want to
have to wade through the class definitions to pick out the small bit of
code I wanted.  As it stands, the executible is only 183k and I wanted to
keep it small.  Besides, the complied version I made will probably only run
under Windows anyway.

Mike

PS - same scene, different lighting

Post a reply to this message

Attachments:
Download 'mars_craters2.jpg' (48 KB)

Preview of image 'mars_craters2.jpg'

Mike Sobers wrote:

>>
> Mike
> 
> PS - same scene, different lighting

Looks nice but, yes there is one :) , it looks to me that the bottom of some
craters is actually higher then the surrounding surface. That way it looks
to me that the crater is added onto the land and not smashed into it.

See attachment


-- 
Ger

Post a reply to this message

Attachments:
Download 'mars_craters2_high_craters.jpg' (47 KB)

Preview of image 'mars_craters2_high_craters.jpg'

Among other things, EagleSun saw fit to write:

>> No, it's true, even though the light comes from below, I have no problem
>> seeing craters and I just can't get my brain to "see" bubbles.
> 
> Just flip it... craters will turn into bubbles.. or bubbles will turn into
> craters.  Same thing happens when I see bubbles--I mean craters on the
> moon.

Not really... the perspective makes it unreal when flipped, and I see
craters anyway :D

-- 
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby

Post a reply to this message

Jellby <me### [at] privacynet> wrote:
> Among other things, EagleSun saw fit to write:
>
> >> No, it's true, even though the light comes from below, I have no problem
> >> seeing craters and I just can't get my brain to "see" bubbles.
> >
> > Just flip it... craters will turn into bubbles.. or bubbles will turn into
> > craters.  Same thing happens when I see bubbles--I mean craters on the
> > moon.
>
> Not really... the perspective makes it unreal when flipped, and I see
> craters anyway :D
>
> --

Didn't we already have this conversation?  ;)

http://news.povray.org/povray.binaries.images/thread/%3Cweb.438b0e52708b6d64f7ce4c3a0%40news.povray.org%3E/?ttop=229667

Post a reply to this message

Ger <No.### [at] ThankYou> wrote:
> Mike Sobers wrote:
>
> >>
> > Mike
> >
> > PS - same scene, different lighting
>
> Looks nice but, yes there is one :) , it looks to me that the bottom of some
> craters is actually higher then the surrounding surface. That way it looks
> to me that the crater is added onto the land and not smashed into it.
>
> See attachment
>
>
> --
> Ger

Yes, that can happen.  The program takes an average ground level and creates
the crater at that height (the bottom of the crater is always below the
average height).  Unfortunately, if there is a slope at that location
(which there always is when a small crater is inside a larger one), the new
crater may have a bottom that is higher than the lowest point on the ground
in that area.  The new craters are always parallel to the original ground
plane.  To fix this we'd have to calculate a normal to the average slope at
the location of the new crater and then create the crater parallel to the
slope.  For now I'm willing to live with it, since tweaking the command
line settings can usually produce a scene that looks realistic enough for a
given situation.  You'll find that after a few million craters, areas with
many medium/large craters will evolve upward, while areas with mostly small
craters will evolve downward.  The simulation can look very unrealistic for
some seed values if the number of craters exceeds 10 million or so, and if
there are many large craters.

Mike

Image - 800 x 800, max crater size 760 across, 5 million crater impacts.

Post a reply to this message

Attachments:
Download 'lotsocraters.jpg' (26 KB)

Preview of image 'lotsocraters.jpg'

"Mike Sobers" <sob### [at] mindspringcom> wrote:
> "PM 2Ring" <nomail@nomail> wrote:
> > "Mike Sobers" <sob### [at] mindspringcom> wrote:
> > > I compiled the crater field generator code by PM 2Ring with a few
> > > modifications:

> If you want, I can post a link to the source files, and hand the project
> back over to you. I don't think I'll have time to work on them much in the
> near future.  The only reason I went to BMP is because I am using Windows,
> and I wanted immediate feedback on the look of the craterfield.

I'd probably work from my sources, but I wouldn't mind looking at your code:
I'm curious about the geometry of your central peaks. I'll get back to you.

> Also, the
> random number generator didn't work when I compiled it under Microsoft
> Visual Studio (something about the syntax on the bit shift commands) so it
> only produced 1 crater at X,Y = 0,0.

Hmmm. I'll have to take another look at that.

> Other than that, it would probably be
> better to have a PGM output, especially since that could get you to 16 bit.

Yes. Older NetPBM programs can only read 16-bit files in ASCII format, which
are huge, but all modern compilations should be able to read & write 16-bit
in binary, if they use the standard NetPBM headers. I wanted to keep the
program as compact as possible, so didn't bother using the standard NetPBM
headers, since the original program only does output, not input.

> I was going to include .jpg and .png output options, but I didn't want to
> have to wade through the class definitions to pick out the small bit of
> code I wanted.  As it stands, the executible is only 183k and I wanted to
> keep it small.  Besides, the complied version I made will probably only run
> under Windows anyway.

I don't have a Windows C compiler, which is why I only posted a Linux
version (I don't think anybody wants the Amiga version :). I've only done
non-platform-specific coding on the PC: Javascript & HTML, Postscript, and
of course, POV SDL.


Here's a pic, with exaggerated heights, from when the "outer wall blending
into the background" algorithm was not quite right...

Post a reply to this message

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

Preview of image 'planetf7s.jpg'

"PM 2Ring" <nomail@nomail> wrote:
>
> I don't have a Windows C compiler, which is why I only posted a Linux
> version (I don't think anybody wants the Amiga version :). I've only done
> non-platform-specific coding on the PC: Javascript & HTML, Postscript, and
> of course, POV SDL.
>
>
> Here's a pic, with exaggerated heights, from when the "outer wall blending
> into the background" algorithm was not quite right...


Looks great!  These craters seem volcanic in origin - maybe another option
to add?

You can download my source from
http://michaelsobers.home.mindspring.com/tests/NewCrater2.zip

The random number code is now:
//#define random(x) (((x)*(rand()>>15UL))>>16UL)
#define random(x) (( (x)*rand() )/RAND_MAX)

Where RAND_MAX is an identifier (maybe Windows only?) that is the maximum
number that can be returned by rand() (I think it's the maximum integer
value).

The central peak code is simply adds to the current crater interior profile:

 if(d<irad) {
     float rmax = irad;
     float radius = d;
  c = c + pow8((rmax-radius)/rmax)*h/4;
 }

Where the variable redefinition to float forces the code to use floating
point operations on the division (using integers didn't work).  From trial
and error, it seemed that h/2 was the height of the rim of the crater, so
the function varies from zero at the edge, to a peak about 1/2 the crater
rim height at the center.

Here's the function pow8, which is just a function to raise the argument to
the eighth power:

float pow8(float x)
{
  float x2 = x*x;
  float x4 = x2*x2;
  return (x4*x4);
}

The rest is just command line options and logic to decide when to implement
the central peaks and when to avoid it.  I'm sure there are more elegant
approaches than mine, especially to minimze the number of operations in
each cycle, which becomes important when running the loop 10 million times
or so.

My smoothing function is crummy so I'd avoid using it and just postprocess
the image with Gaussian blur to simulate erosion.

Mike

Post a reply to this message

I can see both. My first impression was also bubbles. I think the crater 
centres should be deeper. There are small craters on the edges of larger 
craters that are too high IMO. I also think the colour differences of the 
edges are too drastic.

Keep up the good work.


-- 
-Nekar Xenos
"The truth is out there"

Post a reply to this message