Source for my TC-RTC entry, including version 0.2 of my tree planting 
macro. inthewild-output.txt contains the Povray output from my final 
render, if you're curious about the statistics.

I included the meshes for the terrain and the machines, but not the 
trees. The trees would have added about 15MB to the archive (!!!), and 
it's easy enough to generate them yourself with Povtree, anyway.

Finally, inthewild.pov has an Easter egg in it: Set the variable "RSOCP" 
to 1, and the file will render my Reflective Sphere on a Checkered Plain 
scene. Special thanks to Archpawn for the pun. :-)

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

    They laughed. Photons rained on their skin, most shooting right 
through them. Here they were, transparent to the world.
     -- Kim Stanley Robinson, _Blue Mars_

Post a reply to this message

Attachments:
Download 'inthewild.zip' (54 KB)

The archive has a password.

Post a reply to this message

Nicolas Alvarez wrote:
> The archive has a password.

Damnit.

I used 7zip with the flag:

-pass=15

Which I thought would do compression with 15 passes.

Instead, it set a password of:

ass=15

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

Now we know everything there is to know about ML, except how to program!
     -- Jeffrey D. Ullman, _Elements of ML Programming_

Post a reply to this message

William Tracy escribió:
> Which I thought^Wassumed would do compression with 15 passes.

Hmm... I don't know any lossless compression with such thing as 'passes'.

Shows how useful it is to rtfm, and how bad it is to assume :)

Post a reply to this message

William Tracy escribió:
> and it's easy enough to generate them yourself with Povtree, anyway.

Even for those who have never used POV-Tree before? :)

I would like to know exactly what parameters you used, so I can recreate 
the same meshes as you.

Post a reply to this message

From the 7z manual:

"pass={NumPasses}
     Sets number of passes for Deflate encoder. It can be in range from 
1 to 15 for Deflate and from 1 to 10 for BZip2. Usually big number gives 
a little bit better compression ratio and slower compression process."

As it turns out, the correct flag was -mpass=15, and it makes 
compression take significantly longer without noticeably reducing the 
file size (nearly double the time for a 0.1% size improvement).

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

If we were told to parse starting *after* the supplied String, then do 
what we need to do to indicate pilot error.
     -- Laird Nelson, blogging on Java programming

Post a reply to this message

William Tracy escribió:
>  From the 7z manual:
> 
> "pass={NumPasses}
>     Sets number of passes for Deflate encoder. It can be in range from 1 
> to 15 for Deflate and from 1 to 10 for BZip2. Usually big number gives a 
> little bit better compression ratio and slower compression process."
> 
> As it turns out, the correct flag was -mpass=15, and it makes 
> compression take significantly longer without noticeably reducing the 
> file size (nearly double the time for a 0.1% size improvement).
> 

Sounds like increasing isosurface accuracy, antialiasing recursion 
level, max_trace_level to numbers where you don't see the extra 
reflections anyway, etc. :)

Post a reply to this message

Nicolas Alvarez escribió:
> William Tracy escribió:
>> and it's easy enough to generate them yourself with Povtree, anyway.
> 
> Even for those who have never used POV-Tree before? :)
> 
> I would like to know exactly what parameters you used, so I can recreate 
> the same meshes as you.

Actually, didn't you keep the include files generated by POV-Tree, the 
non-mesh ones? Those are 5KB, and I can make the mesh from it.

Post a reply to this message

Nicolas Alvarez wrote:
> Actually, didn't you keep the include files generated by POV-Tree, the 
> non-mesh ones? Those are 5KB, and I can make the mesh from it.

No, I didn't. :-P If you give me a few days (sorry, I've run out of free 
time right now) I can reconstruct what I did. It's just the Linden tree 
with a few tweaks.

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

    You can never go back. Free Mars.
     -- Kim Stanley Robinson, _Green Mars_

Post a reply to this message

William Tracy escribió:
> Nicolas Alvarez wrote:
>> Actually, didn't you keep the include files generated by POV-Tree, the 
>> non-mesh ones? Those are 5KB, and I can make the mesh from it.
> 
> No, I didn't. :-P 

POV-Tree manual recommends you should *always* save to that other 
format, and only export to mesh when you're done.

> If you give me a few days (sorry, I've run out of free time right
> now) I can reconstruct what I did.

Well... can you send me the huge meshes, at least? :) I want to try 
rendering your scene!

Post a reply to this message

Nicolas Alvarez wrote:
> POV-Tree manual recommends you should *always* save to that other 
> format, and only export to mesh when you're done.

I created a few files that I actually couldn't open again because I 
screwed something up, and quit trying. A poor excuse, I know.

> Well... can you send me the huge meshes, at least? :) I want to try 
> rendering your scene!

The smallest I can squeeze it down to is 13 megs, and that's with the 7z 
compression format--15 megs is still the best I can get out of zip. Do 
you want me to try emailing it to you?

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

I'm sorry Dave, I'm afraid I can't do that.
     -- HAL 9000

Post a reply to this message

William Tracy escribió:
>> Well... can you send me the huge meshes, at least? :) I want to try 
>> rendering your scene!
> 
> The smallest I can squeeze it down to is 13 megs, and that's with the 7z 
> compression format--15 megs is still the best I can get out of zip. Do 
> you want me to try emailing it to you?
> 

I have 7-zip; and even 20 megs would be acceptable, I can download at 
70KB/s (now that my connection got back working correctly!).

Post a reply to this message

Nicolas Alvarez escribió:
> Well... can you send me the huge meshes, at least? :) I want to try 
> rendering your scene!

Takes one whole minute to parse the meshes! I'm sure it's not the loops 
on placeLandscape; I added debug statements before each #include. 60 
seconds to parse loop-less code seems extreme :D

And rendering with +q2 and no area light takes 18 seconds. I would 
really like to save the meshes in binary format so they can be loaded 
instantly :(

Post a reply to this message

I'm planning to render the scene at a silly-high resolution. Stay tuned.

Post a reply to this message

Nicolas Alvarez escribió:
> I'm planning to render the scene at a silly-high resolution. Stay tuned.

Render times between tiles vary way too much. I can't stand a 1m 14s 
parse and 42 second render; but if I make tiles bigger, some may go up 
to hours.

So, the idea of biggest-damn-render-you-have-ever-seen is suspended 
until I get dynamic tiles to work.

Post a reply to this message

Nicolas Alvarez wrote:
> Takes one whole minute to parse the meshes! I'm sure it's not the loops 
> on placeLandscape; I added debug statements before each #include. 60 
> seconds to parse loop-less code seems extreme :D

Wow--I still thought it was the loops that were taking all the time.

I need to see about cranking down the Pov-Tree mesh resolution, then.

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

    A ’a ThingCollection value is constructed from OneThing, TwoThings, 
ManyThings, and Nothing constructors
to store a collection of ’a values. Write a function flatten collection 
that takes a ’a ThingCollection as
an argument and that returns a ’a ThingCollection that is constructed 
from a single ManyThings and a single
Nothing.
     -- Professor Keen, homework assignment 1, CSC 430

Post a reply to this message

Nicolas Alvarez wrote:
> I'm planning to render the scene at a silly-high resolution. Stay tuned.

The grass textures barely hold up as it is. :-P The rest of the scene 
should look reasonable at higher resolutions, though.

Are you rendering the RSOCP, or the robots? :-)

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

Post a reply to this message

William Tracy escribió:
> Nicolas Alvarez wrote:
>> I'm planning to render the scene at a silly-high resolution. Stay tuned.
> 
> The grass textures barely hold up as it is. :-P The rest of the scene 
> should look reasonable at higher resolutions, though.

I want to see a single f***ing tree being 600 pixels high. That should 
give you an idea.

Post a reply to this message

Nicolas Alvarez wrote:
> I want to see a single f***ing tree being 600 pixels high. That should 
> give you an idea.

Wow. I have no idea how it will look at that resolution. Even if the 
full file is too big to share, I would definitely like to see some 
details from it. :-)

I'm now playing with optimizing the scene for fast rendering, since I 
want to re-use some of the code for an animation. I could share the 
faster code with you when it's together, but I have no idea if my 
"improvements" would introduce additional artifacts at that resolution.

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

    "I don't hink it helps to make analagies between the physical and 
social worlds," Sax said primly.
    "Shut up, Sax. Go back to your virtual reality."
     -- Kim Stanley Robinson, _Red Mars_

Post a reply to this message

Nicolas Alvarez escribió:
> I'm planning to render the scene at a silly-high resolution. Stay tuned.

In the usual tiling method (setting +w and +h to the full res, and using 
+sc +ec +sr +er), I can't do it. POV-Ray crashes, because it still 
attempts to allocate memory for the whole image. However, I successfully 
managed huge tiled renders with zoomin.inc, where I set +w and +h to the 
size of a single tile.

I'll post a 2048x1536 render on p.b.i. It's not too big, as I was just 
testing, and rendering only on my machine.

Post a reply to this message