continuing a trace ( +c ) doesn't work apparently

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

"triple_r" <nomail@nomail> wrote:
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> > there seems to be an error with png-output, I get ridiculously large files
> > (a 64x64 rendering of the cornell-box gives me a 65MB png, or a 13KB BMP),
> > and after a few iterations (ranging from 10 to 300, so far), I get the
> > error-message:
>
> That's the same thing I get, but I think the answer is just that png output is
> not really supported yet.  Since it renders in passes, the BMP output has been
> altered so it overwrites the image, rather than appending.  Solution?  Use BMP
> for now?
>
>  - Ricky
Thanks Ricky, It is exactly the problem, only bmp format is supported. I thank I
will do in an other way : instead of wrapping the rendering (and changing source
dependant of the plateform), I will rename the file of the previous pass and
create a new one. Code should be in this case plateform independant.

Fidos

Post a reply to this message

"fidos" <fid### [at] wanadoofr> wrote:
> "triple_r" <nomail@nomail> wrote:
> > "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> > > there seems to be an error with png-output, I get ridiculously large files
> > > (a 64x64 rendering of the cornell-box gives me a 65MB png, or a 13KB BMP),
> > > and after a few iterations (ranging from 10 to 300, so far), I get the
> > > error-message:
> >
> > That's the same thing I get, but I think the answer is just that png output is
> > not really supported yet.  Since it renders in passes, the BMP output has been
> > altered so it overwrites the image, rather than appending.  Solution?  Use BMP
> > for now?
> >
> >  - Ricky
> Thanks Ricky, It is exactly the problem, only bmp format is supported. I thank I
> will do in an other way : instead of wrapping the rendering (and changing source
> dependant of the plateform), I will rename the file of the previous pass and
> create a new one. Code should be in this case plateform independant.
>
> Fidos

Modification done. It works fine. I tested on Windows and Linux Debian 4.0r1 (I
think that on MAC OS X it should be the same because I had the same compilation
error than Ricky).

Fidos

Post a reply to this message

Hello,

I put in line (http://pagesperso-orange.fr/fidos/MCPov/MCPov.html) the version
0.0.2 of MCPov patch :
- it compiles now correctly under Linux.
- It uses a fast high-quality RNG as provided by Wrap.

Any feedback wellcome.

Regards,
Fidos.

Post a reply to this message

fidos <fid### [at] wanadoofr> wrote:
> - It uses a fast high-quality RNG as provided by Wrap.

  Who?-)

  (Btw, it would be interesting to see some side-by-side comparisons,
to see if there's any visual or rendertime differences compared to the
older version.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> fidos <fid### [at] wanadoofr> wrote:
> > - It uses a fast high-quality RNG as provided by Wrap.
>
>   Who?-)
Oops, sorry for the big mistake.
>
>   (Btw, it would be interesting to see some side-by-side comparisons,
> to see if there's any visual or rendertime differences compared to the
> older version.)
I know that there is only a slight rendertime improvement.
But there is a visual difference. I'm rendering the office of Jaime Vives
Piqueres and it is less bright and the overall result is quite good.

Fidos

Post a reply to this message

fidos <fid### [at] wanadoofr> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > fidos <fid### [at] wanadoofr> wrote:
> > > - It uses a fast high-quality RNG as provided by Wrap.
> >
> >   Who?-)
> Oops, sorry for the big mistake.

  Anyways, the original RNG algorithm (and implementation) is by
Bob Jenkins, if you want to give proper credit. (I just wrapped his
code into an easy-to-use C++ class.)

-- 
                                                          - Warp

Post a reply to this message

"triple_r" <nomail@nomail> wrote:
> "fidos" <fid### [at] wanadoofr> wrote:
> So here's a question at least.  Is there a reason the following scene renders so
> differently with the three different options?  Cases one and three produce the
> smooth focal blur I would expect, but case 2 produces a sharp cutoff.  I have
> tried to boil this down to the simplest scene that causes unexpected behavior,
> but I just can't see what the problem is.
I found the reason. It was a bug... Because I change the origin of the camera
with dof on, the vista buffer return a wrong object intersection. I will make a
new release. Thank you for your testing infos.

Regards,
Fidos

Post a reply to this message

Hello,

Version 0.0.3 of MCPov is released
(http://pagesperso-orange.fr/fidos/MCPov/MCPov.html) :
- bugfix : sometimes wrong results when depth of feild is activated.
- bugfix : wrong results if a CSG object is defined as portal.
- bugfix : segmentation fault if the mc_sky keyword is used in a CSG object.
- bugfix : wrong results with mc_sky.
- Max grid dimension for sky is now 1000 (instead of 100).

Any comments wellcome.

Regards,
Fidos.

Post a reply to this message

> Any comments wellcome.
>
> Regards,
> Fidos.

I have installed your patch, and it looks like there's great potential, but the
only thing that renders for me properly is the csg. Any geometry I do this with
(#include "Backdrop_POV_geom.inc" //Geometry) and then create the object renders
black for me. Regular Povray, megapov or povman there's no problem with the
geometry.

Post a reply to this message