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

On 2-8-2018 23:11, Stephen wrote:
> 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.
>>

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

LOL

If everybody (ever) switches over to metres, the world will become a 
poorer place.

-- 
Thomas

Post a reply to this message