POV-Ray : Newsgroups : povray.binaries.images : Unexpected double_illuminate tradeoffs : Re: Unexpected double_illuminate tradeoffs Server Time
6 May 2024 01:35:24 EDT (-0400)
  Re: Unexpected double_illuminate tradeoffs  
From: Cousin Ricky
Date: 12 Aug 2018 17:47:19
Message: <5b70aae7$1@news.povray.org>
On 2018-08-04 07:33 PM (-4), Cousin Ricky wrote:
>
> TL;DR: I'm now working on very low detail mesh trees.

After a memory test, my priority has switched from revamping the trees 
to implementing units.

First of all, I can't seem to find any memory usage statistics in the 
POV-Ray 3.7 messages, so I did the test in 3.6.  These are the results 
for my original model, which uses a sphere for broadleaf trees and a 
simple CSG intersection for conifers:

   Smallest Alloc:                   9 bytes
   Largest  Alloc:              492040 bytes
   Peak memory used:          73732329 bytes
   Total Scene Processing Times
     Parse Time:    0 hours  0 minutes 55 seconds (55 seconds)
     Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
     Render Time:   0 hours  0 minutes  8 seconds (8 seconds)
     Total Time:    0 hours  1 minutes  3 seconds (63 seconds)

These are the results of the mesh test:

   Smallest Alloc:                   9 bytes
   Largest  Alloc:              492040 bytes
   Peak memory used:          85738823 bytes
   Total Scene Processing Times
     Parse Time:    0 hours  0 minutes 54 seconds (54 seconds)
     Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
     Render Time:   0 hours  0 minutes  9 seconds (9 seconds)
     Total Time:    0 hours  1 minutes  3 seconds (63 seconds)

It appears that for low-detail models, there is near parity, at least in 
POV-Ray 3.6, with the original system having a slight edge.  A third 
test with more complex CSG used a lot more memory, confirming that for 
increased detail, meshes are definitely the way to go.  But as long as 
I'm not saving memory in the short term, the tree project doesn't seem 
urgent.

Meanwhile, my patio is not wheelchair accessible.  (What patio?  Oh, I 
forgot, in rig #4, I added an outdoor mode with a finite checkered 
plane.  Gotta have that checkered plane.)  Of course, this is entirely 
academic in a virtual universe, but if practical necessity were the only 
factor, I wouldn't be worrying about hills and trees.

 From the beginning of this 4th rig, I incorporated unit conversion 
constants, because having a hardwired unit had already been a problem. 
However, I haven't yet gotten around to integrating scaling factors into 
the rig itself.  In this state, the unit conversion constants are mostly 
useless.  This deficiency has reared its head in some of my Object 
Collection projects, even though the rig itself is not part of the 
uploaded scenes.  When I added unit conversions to lrchairs (Leroy is 
also an American, and his chair was sized accordingly), I had to fudge 
the scaling in my test suite; and I had to do an unreasonable amount of 
math to set the camera for the gem settings I posted last year.  This is 
work a prefab render rig should relieve me of.

I think I should best retrofit my existing code to incorporate 
user-chosen units before embarking on a major project entailing 
demolition and reconstruction of brick walls, or growing a new forest, 
for that matter.  As I see it right now, the horticulture can wait.

When the time comes, I am leaning strongly toward an increased triangle 
count, without double illumination or interior texture.  It turns out 
that the current triangle count (95) leaves a disturbingly jagged 
silhouette in the forest context, so I'd be going in that direction anyway.

Note: the hills in the attached image are just a textured height field.


Post a reply to this message


Attachments:
Download 'non-accessible.jpg' (103 KB)

Preview of image 'non-accessible.jpg'
non-accessible.jpg


 

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.