Tradeoffs, tradeoffs, tradeoffs.

First some background, which I vainly imagine would be interesting to 
people other than myself.  I started writing a prefab render rig a 
couple days after I downloaded POV-Ray in 2003, and I've been obsessed 
with tweaking successive rigs ever since.  My first try included an 
infinite checkered plane with outdoorsy lighting.  Why outdoors? 
Because I like the visual effect of the warm direct lighting and cool 
shadows.

It didn't take long before I was struggling with moiré artifacts.  In my 
first reboot, I simply gave up on the checkered plane.  My second reboot 
in 2004 had two modes: an outdoor mode with a grassy bozo pattern that 
is not prone to distracting artifacts; and an indoor mode with a finite 
checkered floor.  (I absolutely had to keep a checkered plane in some 
form, as I was still carefully considering my first p.b.i post.  I was 
planning to post a workaround for the Fresnel/dispersion bug using a 
reflective glass sphere, but then the dev team fixed that bug in v3.6, 
leaving me at a loss for ideas.  I think my first p.b.i post was "RSOCP 
overkill.")

There the grassy plain remained for the next few years, with little more 
than the occasional surface normal tweak.  Then for Thanksgiving 2007, I 
was invited to my brother's girlfriend's family's place in the 
Shenandoah Mountains, and I knew I had to have some hills for my render 
rig.  (Funny how the hills in my native Virgin Islands never inspired me 
that way.  New Yorkers don't visit the Statue of Liberty either.)  I 
just threw up a layered pigment onto my sky_sphere, and was done for the 
next few years.

Over the years, the code grew increasingly disorganized, and I was 
becoming concerned about namespace issues, so in 2012, I decided it was 
time for another reboot.  This time I used a height field for the hills 
instead of a sky_sphere pigment.  At first I just used a bumpy texture 
to simulate a forest, but 3 years ago I made the fool decision to 
include actual tree objects.  Since finished art products are strictly 
off-label for this project, the tree models could be very rudimentary. 
Spheres and simple CSG forms would do.

As it turns out, forests are extremely memory intensive, so now I'm 
looking at mesh trees to see if they will save memory over CSG objects, 
with a bonus of looking more realistic.  But before I can do the memory 
test, I must have a tree model.  POV-Tree?  TomTree?  Bah, PERL, Java, 
and real life in too much disarray to tolerate the learning curve.  OK, 
I'll just roll my own /slightly/ more realistic trees.

An isosurface forest is another option, which vanquishes memory 
concerns, but I haven't yet come up with a function that I'm satisfied with.


TL;DR: I'm now working on very low detail mesh trees.


I found the black borders on the smooth triangles unexpectedly 
disturbing.  They do show up on my height field hills under some 
circumstances, but are quite tolerable.  But seeing them cap my trees 
sent me straight to double_illuminate.  Disappointingly, double 
illumination had its own peculiarities near the shadow lines.  And when 
I added surface normals to the trees, it got really weird.  As you can 
see, with double illumination the facet edges at the shadow lines are 
far more noticeable, the shadow contrast is weaker on the normal 
pattern, and the lit areas near the shadow lines are just surreal.

Tradeoffs.  I'm looking to skip the double illumination and tolerate the 
black borders.

P.S.  These images use the indoor setting of the 4th prefab render rig.

Post a reply to this message

Attachments:
Download 'make_sotd_tree_meshes-pbi.jpg' (105 KB)

Preview of image 'make_sotd_tree_meshes-pbi.jpg'