Hi all, I just saw over at Jeremy Birn's lighting challenges site (he's the
lighting/rendering technical director for Pixar) that there's actually a POV-Ray
scene included as part of this month's rendering challenge (for the first time
ever?).

I thought it was really cool to see POV-Ray included along with the SoftImage
XSI, Maya, 3d Studio Max, OBJ, and Lightwave formats and wanted to share the
info in case anyone here wants to show off their POV-Ray texturing, lighting,
and rendering skills head to head against the big dogs (I know I'm tempted :)

You can download the scene file over at
http://www.3drender.com/challenges/index.htm and read about the challenge at
http://forums.cgsociety.org/showthread.php?f=185&t=829311

The challenge deadline is Dec 31...

Cheers,
Rob

http://www.McGregorFineArt.com

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> http://www.3drender.com/challenges/index.htm and read about the challenge at
> http://forums.cgsociety.org/showthread.php?f=185&t=829311

That is so friggin' cool!

I wish I had the talent...

Post a reply to this message

Robert McGregor wrote:

> Hi all, I just saw over at Jeremy Birn's lighting challenges site (he's the
> lighting/rendering technical director for Pixar) that there's actually a POV-Ray
> scene included as part of this month's rendering challenge

if anyone is interested to play with this but doesn't want to
work with a single 76MB pov file (sort of impractical), I just
hacked a little perl script to extract the individual object
geometries and texture definitions to separate inc files:

split_geometry.pl:
------------------------------------------------------
open (POV, "$ARGV[0]") || die "can't open input file";

$object_name = "";
$triangles   = 0;

open (TEX, ">textures.inc") || die "unable to create textures.inc";

while (<POV>)
{
   if ($triangles)
   {
     if (/smooth/)
     {
       print INC $_;
     }
     else
     {
       if (/^texture/)
       {
         $texture_name = "T_$object_name";
         print "texture {$texture_name}";
         print TEX "#declare $texture_name = texture {lambert1}\n";
       }
       else
       {
         print $_;
       }
       $triangles = 0;
       close(INC);
     }
   }
   else
   {
     if (/Triangles for object '(.*)'/)
     {
       $object_name = $1;
     }

     if (/smooth_triangle/)
     {
       $inc_file = "inc/$object_name.inc";
       open (INC, ">$inc_file") || die "unable to create $inc_file";
       print '#include "' . $inc_file . '"' . "\n";
       print INC $_;
       $triangles = 1;
     }
     else
     {
       unless (/object \{/ || /End of triangles/)
       {
         print $_;
       }
     }
   }
}
------------------------------------------------------

Usage: perl split_geometry.pl Bedroom.pov > Bedroom_split.pov
A subdirectory inc must already exist in the current directory.
You will need to #include the new file textures.inc as well.

Note that the scene will render black initially as it comes
originally without any light source.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> Robert McGregor wrote:
>
> > Hi all, I just saw over at Jeremy Birn's lighting challenges site (he's the
> > lighting/rendering technical director for Pixar) that there's actually a POV-Ray
> > scene included as part of this month's rendering challenge
>
> if anyone is interested to play with this but doesn't want to
> work with a single 76MB pov file (sort of impractical), I just
> hacked a little perl script to extract the individual object
> geometries and texture definitions to separate inc files:


Greatly appreciated, but the problems with the scene are actually even worse
than that.  Some objects are not labeled, almost all have the same texture
declarations, and it is using a union of smooth_triangles instead of a mesh or
mesh22.  There are also A LOT of degenerate triangles and a few other odd
things.  I don't know what exporter was used, but it must be pretty old (the
specified language version is 3.1!).

Anyway, I wound up downloading the obj file and opened that with wings.
Massively slow at first, but I am in the process of splitting it into separate
files, which will let me organize the includes better.

-Reactor


P.S. As can be expected, the z axis is flipped in this scene as many modelers
use the left hand system instead of the right hand.

Post a reply to this message

> Greatly appreciated, but the problems with the scene are actually even
> worse than that.  Some objects are not labeled, almost all have the same
> texture declarations, and it is using a union of smooth_triangles instead
> of a mesh or mesh22.  There are also A LOT of degenerate triangles and a
> few other odd things.  I don't know what exporter was used, but it must
> be pretty old (the specified language version is 3.1!).

   Yeah... A Poseray export would have been much better, although the
problems with the names will be still there. This is no problem for people
working with GUI, but for us POVers it is really a "challenge". ;)

> Anyway, I wound up downloading the obj file and opened that with wings.
> Massively slow at first, but I am in the process of splitting it into
> separate files, which will let me organize the includes better.

   I used Poseray to convert the OBJ to POV, then loaded the OBj also on
Wings just to identify the objects, so I can give each one a different
texture on the Poseray export.

   Another problem seems to be missing UV info on some objects, and badly
mapped UV on some others... I don't know if this is perhaps due to the
conversion.

   Indeed, there are already some terrific entries that will be hard to
beat... ;)


-- 
Jaime Vives Piqueres

http://www.ignorancia.org

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
>    Indeed, there are already some terrific entries that will be hard to
> beat... ;)

That's because they still haven't met you! :D

Post a reply to this message

Reactor wrote:

> Greatly appreciated, but the problems with the scene are actually even worse
> than that.  Some objects are not labeled, 

yeah, unless you count 'polySurface10933' as a label ...
but I reckon their not labelled in the obj version either?

> almost all have the same texture declarations

forgot to mention that the script replaces the texture definitions
for easier replacement ;) Of course texturing is supposed to be part
of the challenge so I assume that is why it's all lambert1

Here's a sample how my pov file now looks like:

// Triangles for object 'Bedframe' (12140 triangles)
union {    // Surface 'lambert1'
#include "inc/Bedframe.inc"
texture {T_Bedframe}}

> I don't know what exporter was used, but it must be pretty old (the
> specified language version is 3.1!).

PolyTrans, see http://www.okino.com/conv/conv.htm
It's actually a professional tool, heard of it earlier in CAD
context. I didn't know it had any kind of POV-Ray output.

> P.S. As can be expected, the z axis is flipped in this scene as many modelers
> use the left hand system instead of the right hand.

I thought POV-Ray also uses a left-handed system too? A small test
render seemed to show geometry oriented like in the forum thread.

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
>
> yeah, unless you count 'polySurface10933' as a label ...
> but I reckon their not labelled in the obj version either?
>

They are not, but Wings has a full GUI so it is easy to relabel them before
export.

> forgot to mention that the script replaces the texture definitions
> for easier replacement ;) Of course texturing is supposed to be part
> of the challenge so I assume that is why it's all lambert1
>
> Here's a sample how my pov file now looks like:
>
> // Triangles for object 'Bedframe' (12140 triangles)
> union {    // Surface 'lambert1'
> #include "inc/Bedframe.inc"
> texture {T_Bedframe}}
>

That's nifty!  Probably faster than doing it in Wings, but I am also adding uv
mapping info...

>
> I thought POV-Ray also uses a left-handed system too? A small test
> render seemed to show geometry oriented like in the forum thread.

POV uses the right hand system, and you are correct that rendering the scene as
downloaded does show the same orientation, but this is a consequence of the
right vector being declared as along the negative x axis (which I kind of
consider to be backwards :D ).  Anyway, this isn't too big of a deal.  I can't
remember whether or not that flips textures also, but those are easily
re-flipped by scaling a negative amount.

I am hoping that the geometry files will be much smaller after re-export, since
mesh2 is usually more compact, so that should help with the parsing time.  I am
curious as to how MCPov would do on this, but I have trouble running it under
XP64

-Reactor

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> schreef in bericht 
news:web.4b2184198fd451f8822e880c0@news.povray.org...
> POV uses the right hand system, .....

Sorry, no. POV uses the left-hand system See Docs 2.2.1.1  Understanding 
POV-Ray's Coordinate System   ;-)

Thomas

Post a reply to this message

Thomas de Groot <tDOTdegroot@interdotnlanotherdotnet> wrote:

> "Reactor" <rea### [at] hotmailcom> schreef in bericht 
> news:web.4b2184198fd451f8822e880c0@news.povray.org...
> > POV uses the right hand system, .....

> Sorry, no. POV uses the left-hand system See Docs 2.2.1.1  Understanding 
> POV-Ray's Coordinate System   ;-)

  Correction: POV-Ray uses the left-handed system *by default*. It can be
changed.

-- 
                                                          - Warp

Post a reply to this message