Hi.  First post to this newsgroup.  I'm constantly impressed with povray, so
I wanted to see what I could produce for the sponza radiosity challenge
found here:

http://hdri.cgtechniques.com/~sponza/

I've downloaded the megapov file contained on that site, and made some
changes to it:

1.  Set all ambient values for materials to 0.0
2.  Changed the camera posn to that of a maxwell render which I'm using as a
reference
3.  Altered the posn of the sun light and its intensity
4.  Multiplied the normal bump_size by a factor of 10 - which doesn't appear
to affect the render
5.  Added an .ini file and IndoorLQ radiosity
6.  I've also added "normal on" in rad_def.inc

However, my render still looks flat and imho lacks contrast.  Here is my
result:

http://img208.imageshack.us/img208/1516/test4vv.png

Here is the maxwell render I'm trying to imitate:

http://img203.imageshack.us/img203/9802/sponzapalace1ac.jpg

I think the noise in the maxwell render adds alot to its realism.  I've
tarred up the entire scene with all my changes in it, which can be found
here.  I simply execute "megapov test.ini"

http://jsnake.googlepages.com/sponza_megapov.tar.gz

I have no doubt that povray can produce a render which looks very similar to
the maxwell render, I'm just not quite sure how to go about it :)

Post a reply to this message

lakcaj <nomail@nomail> wrote:
> I have no doubt that povray can produce a render which looks very similar to
> the maxwell render, I'm just not quite sure how to go about it :)

  After playing with it a bit (with povray 3.6; it doesn't really need
megapov per se) I got something which perhaps resembles a bit more (but
not completely) the original:

http://warp.povusers.org/sponza.jpg

  It took 11 hours 23 minutes to render in my computer, though (3.4GHz P4).

  It's interesting to open your rendering and mine in a browser and switch
between the two to see the differences:

http://img208.imageshack.us/img208/1516/test4vv.png

-- 
                                                          - Warp

Post a reply to this message

lakcaj wrote:

> I have no doubt that povray can produce a render which looks very similar to
> the maxwell render, I'm just not quite sure how to go about it :)

After looking at the comparison to Warp's version, I'd recommend adding 
a "normal on" statement to the radiosity block. I think this is whats 
happening.

-- 
~Mike

Things! Billions of them!

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:
> After looking at the comparison to Warp's version, I'd recommend adding 
> a "normal on" statement to the radiosity block. I think this is whats 
> happening.

  What I did was to deepen the normals ten-fold, reverse them (for some
reason they are reversed and need a negative bump_size), changed the
normal accuracy (I don't know if it has a real effect or not), added a
background color (which the original scene didn't seem to have for some
reason), copied the radiosity settings from rad_def.inc and increased
the 'count' and added 'normal on' and changed the assumed_gamma to get
a higher contrast.

  (Besides that, I reduced the disk space needed by the scene from 18 MB
to 9 MB. I did this simply by converting all the tgas to pngs and by
removing 2 megabytes of no-op content from sponzaM_o.inc.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   What I did was to deepen the normals ten-fold, reverse them (for some
> reason they are reversed and need a negative bump_size), changed the
> normal accuracy (I don't know if it has a real effect or not), added a
> background color (which the original scene didn't seem to have for some
> reason), copied the radiosity settings from rad_def.inc and increased
> the 'count' and added 'normal on' and changed the assumed_gamma to get
> a higher contrast.

Wow. I would have never guessed. OOC, what happened with just simply a 
normal on statement?

>   (Besides that, I reduced the disk space needed by the scene from 18 MB
> to 9 MB. I did this simply by converting all the tgas to pngs and by
> removing 2 megabytes of no-op content from sponzaM_o.inc.)

Wow. Why use tga in this day and age?


-- 
~Mike

Things! Billions of them!

Post a reply to this message

Warp wrote:
> 
>   After playing with it a bit (with povray 3.6; it doesn't really need
> megapov per se) I got something which perhaps resembles a bit more (but
> not completely) the original:
> 
> http://warp.povusers.org/sponza.jpg
> 

That looks quite reasonable for a straight away render of a converted 
scene.  What has to be said however is that competitions of the type 
"supplying a scene designed with application X and having programs 
compete how well they render this scene" is not a good estimate for 
renderer abilities in general - it just benchmarks the conversion 
programs and how close the abilities of the renderer match the 
requirements of application X and the scene (in this case indirect 
illumination of bump mapped meshes).

For an unbiased comparison the rendering problem would have to be 
described in a more generic way - and in this case this would of course 
be as much a modeling competition as a rendering one.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 14 Mar. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Mike Raiford <mra### [at] hotmailcom> wrote:
> Wow. I would have never guessed. OOC, what happened with just simply a 
> normal on statement?

  If you look at his attempt, the normals are not very visible even under
direct lighting. 'normal on' in the radiosity block wouldn't affect that.

-- 
                                                          - Warp

Post a reply to this message

Warp,

Wow - your image looks fantastic.  Thanks alot for taking the time to get
such a great render.  Again, the power of povray has really come through.
The more I learn about povray, the more confident I am that it can do just
about anything I want it to, provided it is given the proper settings.

Post a reply to this message

> What has to be said however is that competitions of the type "supplying a
> scene designed with application X and having programs compete how well they
> render this scene" is not a good estimate for renderer abilities in general -
> it just benchmarks the conversion  programs and how close the abilities of
> the renderer match the requirements of application X and the scene (in this
> case indirect illumination of bump mapped meshes).

Almost all renderers understand same scene description. Polygons, textures,
bumpmaps and so on. Conversion between formats is simple task.

> For an unbiased comparison the rendering problem would have to be
> described in a more generic way - and in this case this would of course
> be as much a modeling competition as a rendering one.

Scene to render is good rendering problem, but it requires accurate light
setup and dynamic range description.

Matti

Post a reply to this message