I have just stopped my IRTC entry render 2 days into a very long render{12 -
48 days!) without thinking I clicked on stop render instead of render
priority. Oh well. Try again and hope!

I've been following the 3dMax thread. Pov can do almost anything any other
program can and almost as well. Many programs do some things faster. Vue
d'esprit for instance produces excellent very fast landscapes and with it's
current import facilities it is posible to produce some very serious work.

But I still prefer Pov it is capable of the unexpected.... part of the joy
of creating. I don't get that with other programs.

The problem with Pov is media.
    1. Very slow when combined with complex CSG contructs. My IRTC entry for
example takes two hours to render without media. the media by itself takes
two hours, together though I'm looking at a very, very long render.
    2. I'm still unconvinced by the noise function correction - yes it's
mathmatically correct but it doesn't produce good clouds, I've tried. If you
have time try rerendering Mike Andrews clouds scene in Megapov 05a. As I've
said before what is needed is user control over the noise function - why not
should be easy to implement.

Radiosity is getting better all the time and I'm sure we'll learn to use it.

Pov is a great tool, fun, suprising, exciting and free...... who could ask
for more.

Me, more speed please.

Mick

Post a reply to this message

In article <399062bf@news.povray.org>, "Mick Hazelgrove" 
<mic### [at] mhazelgrovefsnetcouk> wrote:

> The problem with Pov is media.
>     1. Very slow when combined with complex CSG contructs. My IRTC entry 
> for example takes two hours to render without media. the media by 
> itself takes two hours, together though I'm looking at a very, very 
> long render.

I can't think of a reason media would be much slower in complex CSG's, 
and I haven't experienced this problem myself...


>     2. I'm still unconvinced by the noise function correction - yes it's
> mathmatically correct but it doesn't produce good clouds, I've tried. 
> If you have time try rerendering Mike Andrews clouds scene in Megapov 
> 05a. As I've said before what is needed is user control over the 
> noise function - why not should be easy to implement.

The new noise function is easier to use(because it stays within the 
expected range), and can already be used to simulate the old one. You 
could even make a function which behaves like the old one, hard-coding 
it into the program isn't necessary. Or you could just adjust the 
color_maps to simulate the "plateaus" at each end of the map.
It will produce clouds which are just as good as the old noise, just not 
with the exact same code.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Mick Hazelgrove wrote:

> I have just stopped my IRTC entry render 2 days into a very long render{12 -
> 48 days!) without thinking I clicked on stop render instead of render
> priority. Oh well. Try again and hope!

Aargh, sucks to be you! The IRTC period is two months, right? So if you take 48
days to render, that didn't leave much coding time...

--
David Fontaine     <dav### [at] faricynet>     ICQ 55354965
Please visit my website: http://www.faricy.net/~davidf/

Post a reply to this message

48 days is my worst case scenario, I hope that past a certain point it will
speed up again.

took a month to code - have my doubts as to whether it will render in time.

Mick

"David Fontaine" <dav### [at] faricynet> wrote in message
news:399077CA.2F2BB51B@faricy.net...
> Mick Hazelgrove wrote:
>
> > I have just stopped my IRTC entry render 2 days into a very long
render{12 -
> > 48 days!) without thinking I clicked on stop render instead of render
> > priority. Oh well. Try again and hope!
>
> Aargh, sucks to be you! The IRTC period is two months, right? So if you
take 48
> days to render, that didn't leave much coding time...
>
> --
> David Fontaine     <dav### [at] faricynet>     ICQ 55354965
> Please visit my website: http://www.faricy.net/~davidf/
>
>

Post a reply to this message

I hope you didn't restart the render!  Just have it render the missing
portion and put the two parts together with copy and paste.  I had to do
this one round when I had the superpatch continually crashing on me.
All the pixels are raytraced so it's not cheating.

Then again, if it's taking 48 days to render, you really should look
into speeding that sucker up.

-Mike

Post a reply to this message

"Mike" <Ama### [at] aolcom> wrote in message
news:399091E6.91B796C1@aol.com...
| I hope you didn't restart the render!  Just have it render the missing
| portion and put the two parts together with copy and paste.  I had to do
| this one round when I had the superpatch continually crashing on me.
| All the pixels are raytraced so it's not cheating.

Why not use +C to continue the trace from where it left off?

Bob

Post a reply to this message

Excellent idea Mike!  I for one am hoping to see Micks image, whether he
completes it in time
for the next round or not.

--
Doug Eichenberg
http://www.nls.net/douge
dou### [at] nlsnet

Post a reply to this message

> Why not use +C to continue the trace from where it left off?

Doesn't that only work if you have that set when you begin the render?
I seem to recall never being able to restart a render because I forgot
to do that.

-Mike

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote...
> Or you could just adjust the
> color_maps to simulate the "plateaus" at each end of the map.
> It will produce clouds which are just as good as the old noise, just not
> with the exact same code.

Very true.  In fact, you could use a pigment_pattern with a color_map to
reproduce the old noise (bozo) very easily.  It is just a linear correlation
between the old and the new, except that the old one would clip values, so
you couldn't reverse-transform the old one to the new one.

The following code should work, though it has not been tested at all:

#declare OldBozo = pigment
{
  bozo
  color_map
  {
    [(0-0.5+1.05242 )*0.48985582, 0]
    [(1-0.5+1.05242 )*0.48985582, 1]
  }
}

#declare MyPigmentUsingOldBozo = pigment
{
  pigment_pattern{OldBozo}  // instead of "bozo"
  color_map
  {
    ...your color map goes here...
  }
}

The mapping is (if I did the math correctly):

old_value = (new_value / 0.48985582) - 1.05242 + 0.5

-Nathan Kopp

Post a reply to this message

In article <3990d2af$1@news.povray.org>, "Nathan Kopp" 
<Nat### [at] Koppcom> wrote:

> Very true.  In fact, you could use a pigment_pattern with a color_map 
> to reproduce the old noise (bozo) very easily.  It is just a linear 
> correlation between the old and the new, except that the old one 
> would clip values, so you couldn't reverse-transform the old one to 
> the new one.
> 
> The following code should work, though it has not been tested at all:
...snip...
> The mapping is (if I did the math correctly):
> old_value = (new_value / 0.48985582) - 1.05242 + 0.5

Actually, I was thinking of a function...how does this look?
#declare OldBozo =
function {max(0,min(1,noise3d(x,y,z)/0.48985582 - 1.05242 + 0.5))}

This has the advantage of being a direct replacement for isosurfaces 
which use the old noise3d() function...and it is probably noticeably 
faster than running a pigment through a function, and maybe even faster 
than pigment_pattern.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message