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'

On 2-8-2018 1:33, Cousin Ricky wrote:
> Tradeoffs, tradeoffs, tradeoffs.
> 
> [snip]
> 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.

A bell is tolling in the back of my mind but I am unable to find it in 
the mental mist, yet.

Without too much memory load increase you could increase the mesh 
resolution. Between 2 and four times should do the trick.

Your mention of an isosurface forest could be horribly slow to render. 
Gilles Tran used isosurface trees in some of his scenes but you 
certainly know that.

-- 
Thomas

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> TL;DR: I'm now working on very low detail mesh trees.

> I found the black borders on the smooth triangles unexpectedly
> disturbing... Disappointingly, double
> illumination had its own peculiarities near the shadow lines.
>
> Tradeoffs.  I'm looking to skip the double illumination and tolerate the
> black borders.
>

IMO, the trees with double_illuminate ON look (tolerably) better than with it
off.  The trees appear to blend in better with your background sky pigment. From
a practical viewpoint, I think the non-smooth 'appearance' of the outside tree
borders (the straight triangle edges) would be more noticable to someone's eyes
than the double_illumination artifacts. Ditto the triangle edges within the body
of the tree. Since the trees are *designed* to be very low-memory-intensive (and
will not the 'central focus' of any render that you use them in), they look
quite decent. (Although, I would suggest upping the triangle count just a
little, to make them a bit smoother overall-- which, I admit, might erase the
nice 'angular' effect of the outside tree edges!)

Another *possible* way around the problem would be to use an interior texture as
well-- maybe with the color of the sky (or the tree itself?), and a high ambient
or emission value for its finish. Then those edge normals might 'pick up' that
interior color rather than, say, black. Just a theory.

And a gentle reminder: #declaring the tree meshes themselves beforehand will
allow almost unlimited copies with very little memory increase.

As for the double_illuminate artifacts at the edges of the trees: Does the
width/size of those rendered artifacts diminish if the trees are placed far into
the distance? Or does the width remain constant (i.e., possibly becoming as
large as an entire distant tree?) In other words, are the artifacts independent
of camera-tree distance? I don't think I've ever tried such an experiment to
see.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> 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.

Have you considered using isosurfaces for *individual* tree models? I'm thinking
of maybe an egg-shaped function, plus some f_noise(...) to break up the surface.
I would imagine that maybe five to ten different tree models might suffice to
populate an entire (random) forest. And AFAIU currently, copies of the
isosurfaces *may* not take up much extra memory; Clipka mentioned this in a
recent thread (the last entry there)...

http://news.povray.org/povray.advanced-users/thread/%3C5b57c158%241%40news.povray.org%3E/
>
> As you can see, with double illumination [on]...the lit areas near the shadow
> lines [in the body of the tree] are just surreal.
>

I've noticed that too, when rendering low-resolution height_fields. It *does*
seem to be a tradeoff, between using smooth triangles vs. unsmooth, and
double_illuminate vs. no D_I. I've not been able to come up with a satisfactory
compromise.

Post a reply to this message

On 2018-08-02 03:10 PM (-4), Kenneth wrote:
>
>  (Although, I would suggest upping the triangle count just a
> little, to make them a bit smoother overall-- which, I admit, might erase the
> nice 'angular' effect of the outside tree edges!)

More striking than the edge effect are the cast shadows.  The smooth, 
round shadows of the spheres I'm currently using are quite jarring when 
cast on the other trees, especially against the texture normals.  (See 
the cast shadow near the right edge of show_sotd_hills_res-hf1-3.jpg. 
The other image is of the height field at the same scale.  In general, 
though, the hills would be *much* farther away, with the details that 
much less noticeable.  The 'max' figure is the scaling of the noise 
function in feet[1], but my default is 5000.)

> And a gentle reminder: #declaring the tree meshes themselves beforehand will
> allow almost unlimited copies with very little memory increase.

That's exactly what I had in mind.

> As for the double_illuminate artifacts at the edges of the trees: Does the
> width/size of those rendered artifacts diminish if the trees are placed far into
> the distance? Or does the width remain constant (i.e., possibly becoming as
> large as an entire distant tree?) In other words, are the artifacts independent
> of camera-tree distance? I don't think I've ever tried such an experiment to
> see.

The artifacts are an effect of the fake normals on the triangles 
themselves (search Smooth Triangle Artifact in the wiki), so they would 
scale down with the tree distance.

_________________
[1] I did not choose my country of birth, but if I ever release the 
source code, meters will be an option.

Post a reply to this message

Attachments:
Download 'show_sotd_hills_res-hf1-3.jpg' (53 KB) Download 'show_sotd_hills_res-hf0-3.jpg' (43 KB)

Preview of image 'show_sotd_hills_res-hf1-3.jpg'

Preview of image 'show_sotd_hills_res-hf0-3.jpg'

On 2018-08-02 02:43 AM (-4), Thomas de Groot wrote:
>
> Your mention of an isosurface forest could be horribly slow to render.

So it is.

> Gilles Tran used isosurface trees in some of his scenes but you
> certainly know that.

I haven't examined how he did most of his scenes; although I am 
impressed at how he managed to render a rainy scene in "The Wet Bird" 
without rendering any rain.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> [1] I did not choose my country of birth, but if I ever release the
> source code, meters will be an option.

Miles, baby.  Miles.

Post a reply to this message

Attachments:
Download '870608197461278720.jpg' (123 KB)

Preview of image '870608197461278720.jpg'

On 02/08/2018 21:50, Bald Eagle wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> 
>> [1] I did not choose my country of birth, but if I ever release the
>> source code, meters will be an option.
> 
> Miles, baby.  Miles.
> 

:D

Ells baby, ells. :)

"Gie 'im an inch, an he'll tak an ell"

https://en.wikipedia.org/wiki/Ell#Ell_(Scots)

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> Ells baby, ells. :)
>
> "Gie 'im an inch, an he'll tak an ell"
>
> https://en.wikipedia.org/wiki/Ell#Ell_(Scots)


Bloody Ell.   That's interesting  :)   And I have learned something new.

Well done, Lord McAvoy, well done.

Post a reply to this message

On 02/08/2018 23:14, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
> 
>> Ells baby, ells. :)
>>
>> "Gie 'im an inch, an he'll tak an ell"
>>
>> https://en.wikipedia.org/wiki/Ell#Ell_(Scots)
> 
> 
> Bloody Ell.   That's interesting  :)   And I have learned something new.
> 

It makes an ell of a difference. ;)

> Well done, Lord McAvoy, well done.
> 
> 
> 
No it was Tim Cook, of yore, who had the top hat and cane. I'm the one 
brandishing the pitchfork and guiding the tumbrel. :)

-- 

Regards
     Stephen

Post a reply to this message