I have created what may turn into a nice macro which can generate "anatomically
correct" impact craters for a planet or moon by simply specifying the desired
diameter of the crater and it's longitude and latitude on the planet's surface.
 For the most part I am happy with the results but would like to add a few
enhancements before sharing it with the community. The macro currently handles
the situation of "older" craters being partially obliterated by later impacts
and appropriately sized craters will display features such as peak rings and
central peaks. The per crater parse time is not to bad and is the same
regardless of how large or small the desired crater is.

My first goal is to reproduce the craters on the moon and I have downloaded and
database of some 6000 craters to work with.  Obviously, this takes some time to
parse especially when the macro has to check for and then handle instances of
crater overlapping. But rendering of the craters as separate objects runs very
quickly afterwards.

The slowdown (and I mean SLOOOOOOOOOOOOWWWWWWWDDDDDOOOOWWNNNNN!!!!!!!!) Occures
when I have to merge these craters with the "uncratered" parent planet
(sphere).
The floor inside an impact crater is always lower than that of the original
surface outside of the crater this means I have to remove enough of the
original sphere's surface where the crater will "sit" so the inside of the
crater is below the surface it impacts on. Every time I do this by subtracting
the craters from the planet using a difference CSG, the render time goes from a
couple of min to literaly days (almost a week). If I just render the planet with
the needed "excavations" the render takes hours (2 to 3) but that is tolerable
compared to a week. It is when I try to unite the craters and the "excavated"
planet that render time becomes downright glacial.  I have tried this with both
union and merge with no change in the slowness of the render any ideas on how to
speed this up would be greatly appreciated.

Post a reply to this message

"COMPATT" <com### [at] hotmailcom> wrote:
> The floor inside an impact crater is always lower than that of the original
> surface outside of the crater this means I have to remove enough of the
> original sphere's surface where the crater will "sit" so the inside of the
> crater is below the surface it impacts on. Every time I do this by subtracting
> the craters from the planet using a difference CSG, the render time goes from a
> couple of min to literaly days (almost a week).

is the crater an isosurface or insane amount of blobs?  sure difference with
that will be slow...


> I have tried this with both
> union and merge with no change in the slowness of the render any ideas on how to
> speed this up would be greatly appreciated.

hmm, if union isn't any faster than merge... have you rendered the crater alone
to measure its render time?

supposing the planet is a sphere (or a blob), if you just make a difference with
an unevenly scaled sphere (component) and union the result with the crater, does
it get any slower than the rendering time of the crater alone?

Post a reply to this message

"COMPATT" <com### [at] hotmailcom> wrote:
> I have created what may turn into a nice macro which can generate "anatomically
> correct" impact craters for a planet or moon by simply specifying the desired
> diameter of the crater and it's longitude and latitude on the planet's surface.
>  For the most part I am happy with the results but would like to add a few
> enhancements before sharing it with the community. The macro currently handles
> the situation of "older" craters being partially obliterated by later impacts
> and appropriately sized craters will display features such as peak rings and
> central peaks. The per crater parse time is not to bad and is the same
> regardless of how large or small the desired crater is.
>
> My first goal is to reproduce the craters on the moon and I have downloaded and
> database of some 6000 craters to work with.  Obviously, this takes some time to
> parse especially when the macro has to check for and then handle instances of
> crater overlapping. But rendering of the craters as separate objects runs very
> quickly afterwards.
>
> The slowdown (and I mean SLOOOOOOOOOOOOWWWWWWWDDDDDOOOOWWNNNNN!!!!!!!!) Occures
> when I have to merge these craters with the "uncratered" parent planet
> (sphere).
> The floor inside an impact crater is always lower than that of the original
> surface outside of the crater this means I have to remove enough of the
> original sphere's surface where the crater will "sit" so the inside of the
> crater is below the surface it impacts on. Every time I do this by subtracting
> the craters from the planet using a difference CSG, the render time goes from a
> couple of min to literaly days (almost a week). If I just render the planet with
> the needed "excavations" the render takes hours (2 to 3) but that is tolerable
> compared to a week. It is when I try to unite the craters and the "excavated"
> planet that render time becomes downright glacial.  I have tried this with both
> union and merge with no change in the slowness of the render any ideas on how to
> speed this up would be greatly appreciated.

A lot of objects in a CSG can be very slow, espscially if using intersection or
difference.  Perhaps try using blobs as I did for a golf ball some time ago,
which ends up rendering a lot faster.  You can either create the whole planet
as a single blob entity, or just the craters (still create all the craters as a
single blob item though) and union/difference them with the planet.

-tgq

-tgq

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> is the crater an isosurface or insane amount of blobs?  sure difference with
> that will be slow...

Actually I am currenly using a complex series of unions, intersection, and
differences of various "primitive" shapes for each crater (especially the
larger ones which have central peaks or peak rings) Have not considered using
blobs becaues I need the crater walls to end in sharp peaks and the central
peaks to also be sharp.

After getting the bugs out of this version I a planning to do implement same
thing as an isosurface so I can have a more rugged edge to the crater walls,
rims, and central peak or peak ring while maintaining a relativley smooth
crater floor.

> hmm, if union isn't any faster than merge... have you rendered the crater alone
> to measure its render time?
  Render time for a single crater (regardless of size or complexity) - SECONDS

   Render time for 5000+ craters with correct overlapping and longitude and
lattitude coordinates, but no parent planet - ~2 MIN

  Render time of Parent planet only with the needed "pre-excavation" for the
crater floor done using either an appropriatly sized simple sphere or cylinder
- 2 HOURS

  Render time if I combine the "pre-excavated" planet and all the craters -
NEARLY A WEEK


> supposing the planet is a sphere (or a blob), if you just make a difference with
> an unevenly scaled sphere (component) and union the result with the crater, does
> it get any slower than the rendering time of the crater alone?

YES! that seems to be where the slowdown occurs.

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> A lot of objects in a CSG can be very slow, espscially if using intersection or
> difference.  Perhaps try using blobs as I did for a golf ball some time ago,
> which ends up rendering a lot faster.  You can either create the whole planet
> as a single blob entity, or just the craters (still create all the craters as a
> single blob item though) and union/difference them with the planet.


I was not expecting (and greatly appreciate!) the quick responses to my problem.
 Since this is the second time (2 out of 2) that the use of blob objects for
creating craters has been mentioned as a possible solution, I would like to try
this approach.  I can understand how "negative" blobs could be used to simulate
the smooth dimples of a golfball, but the rim of an impact craters wall is
usually sharp, jagged and abrupt. the same is true for the more complex
features of the inside of very large impact craters such as central peaks and
peak rings.  Is is possible to get such "sharp" effects and still use blobs?

Post a reply to this message

Removing tons of objects from a main object will result in a very slow
render. I don't think there's currently any way around that.

  If you can create a single mesh from your cratered planet, that would
render very fast.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Removing tons of objects from a main object will result in a very slow
> render. I don't think there's currently any way around that.
>
>   If you can create a single mesh from your cratered planet, that would
> render very fast.
>
> --
>                                                           - Warp

Yes, no real way around it, sometimes manually bounding can give a little speed
boost, but not much.  The original object can be broken into smaller pieces as
well and manually bound, but this can be difficult to implement very well, at
least for a significant speed improvement.

But, removing a single blob entity consisting of several blobs is considerably
faster than removing the equivalent in spheres, if the objects can be made of
blobs (using the basic formula in the docs, you can mathematically get the
blobs the same size as spheres of a specific radius)

A mesh would likely be far quicker (at rendering) and likely far more versatile.

-tgq

Post a reply to this message

This doesn't look like a Windows-specific problem ;-)

Post a reply to this message

COMPATT nous apporta ses lumieres en ce 2008/01/08 21:29:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
>> A lot of objects in a CSG can be very slow, espscially if using intersection or
>> difference.  Perhaps try using blobs as I did for a golf ball some time ago,
>> which ends up rendering a lot faster.  You can either create the whole planet
>> as a single blob entity, or just the craters (still create all the craters as a
>> single blob item though) and union/difference them with the planet.
> 
> 
> I was not expecting (and greatly appreciate!) the quick responses to my problem.
>  Since this is the second time (2 out of 2) that the use of blob objects for
> creating craters has been mentioned as a possible solution, I would like to try
> this approach.  I can understand how "negative" blobs could be used to simulate
> the smooth dimples of a golfball, but the rim of an impact craters wall is
> usually sharp, jagged and abrupt. the same is true for the more complex
> features of the inside of very large impact craters such as central peaks and
> peak rings.  Is is possible to get such "sharp" effects and still use blobs?
> 
> 
Create the planed as a blob. Use negative blob components to dig the rough 
outlines of the craters into the planet.
Once that's done, add, with an union, all your craters with ther sharp and 
jagged edges and peaks.

-- 
Alain
-------------------------------------------------
EVERYTHING HAS A GENDER

You may not know this but many nonliving things have a gender...

A Hot Air Balloon is Male, because, to get it to go anywhere, you have to light 
a fire under it, and of course, there's the hot air part.

Post a reply to this message

Thanks again for all the help.

When I created the planet using a blob then subtracted out negative blobs the
size of crater floors, the rendering of the planet including my crater objects
increased immensly. Now when I create the moon using the entire 8000+ crater
database it only takes 2.5 min to render the whole 2048x1024 image!!!

Now I can focus on reducing the parse time for the files (which is over 4 hours)
I already know how to do that part by pre-processing the crater data so POV-Ray
will not have to test each crater against all of the already existing ones for
the overlap condition. This is not to hard to do using C++ I just didn't want
to waste time trying to reduce parse time when it would still take almost a
week to render the scene after parsing was over.

If I can end up reducing parse time half as much as I have the rendering (with
the help of all your advice)This macro may even be useful in animations.

I had planned on adding blobs to the macro down the road for making craters on
irregular shapes like asteroids.  It never occured to me I could use a blob
object for the spherical planets and moons as well.

Thanks so much for providing the missing puzzle piece!!

Post a reply to this message