 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.06.2010 08:11, schrieb SharkD:
> How good is the radiosity pretrace as an estimator of how long a scene
> will take to render? Right now it takes about 10 seconds to render a
> pixel, even with a reduced texture quality.
It's usually not a good estimator, because there are various factors
involved:
The Good News:
- Unless radiosity pretrace settings are poor, the pretrace will take a
significantly higher ratio of radiosity samples per pixel (with each
sample requiring tens, hundreds, or even up to 1600 more rays to be
shot, albeit with a few simplifications).
- Using low_error_factor significantly increases the "cost" of sample
lookup (i.e. looking up samples that have already been taken nearby)
during pretrace, while leaving the "cost" during main render unchanged.
The Bad News:
- As the pretrace progresses, the total number of samples keeps
increasing (of course), which also increases the overhead of checking
which samples are suitable for re-use; thus, sample re-use is
comparatively more "expensive" during the main render than during the
first pretrace steps.
- Some features are disabled during pretrace, most notably antialiasing
and focal blur, so these added "costs" don't show during pretrace.
So, all in all, pretrace may or may not be slower or faster than main
render - it depends.
A smaller-sized render is probably a much better indicator of the main
render performance.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/14/2010 3:20 AM, Thomas de Groot wrote:
> "SharkD"<pos### [at] gmail com> schreef in bericht
> news:4c15c9b4@news.povray.org...
>> Another render showing another new building type and a variety of other
>> objects.
>>
>
> This is looking really good!
>
> Thomas
>
>
Yeah, clipka's advice on compensating for gamma really helped a bunch!
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What kinds of things might be the causes of all the slowdown? I've
turned off all media and reflection and it is still abysmally slow.
One major revision I've made to Chris Colefax's CityGen include file is
that each building is now called by a macro and generated individually
at runtime. Whereas originally a single copy (more or less) of a
building was stored in an array and replicated/duplicated when needed.
The other difference of course is that buildings now have greater
complexity. They make use of more CSG operations and feature a greater
number of storeys.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-06-14 18:12, SharkD a écrit :
> What kinds of things might be the causes of all the slowdown? I've
> turned off all media and reflection and it is still abysmally slow.
>
> One major revision I've made to Chris Colefax's CityGen include file is
> that each building is now called by a macro and generated individually
> at runtime. Whereas originally a single copy (more or less) of a
> building was stored in an array and replicated/duplicated when needed.
>
> The other difference of course is that buildings now have greater
> complexity. They make use of more CSG operations and feature a greater
> number of storeys.
>
You have a "concave" geometry composed of many objects made out of
coaxyal cylinders slices. This can very easily lead to bounding problems
where most objects bounding boxes overlap each other, and are
excessively large.
Try manualy bounding the individual buildings. Try to see if you can use
some mesh.
Use simple boxes or prisms for narrow buildings and some of the farder
ones. Some/most broad buildings probably can do with only a texture that
curves instead of the actual floors.
Except for the closest buildings, don't model individual floors. A flat
topped conical building can be a simple truncated cone. The flat base
beed hiden under the ground. If needed, remove a small cylindrical part
from it's top.
Only model the interior of a building IF you look from it's inside or
take a closeup look into it. Use conditional statements, possibly based
on insideness test or bounding box test to toggle the insides as needed.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/14/2010 7:03 PM, Alain wrote:
> Le 2010-06-14 18:12, SharkD a écrit :
>> What kinds of things might be the causes of all the slowdown? I've
>> turned off all media and reflection and it is still abysmally slow.
>>
>> One major revision I've made to Chris Colefax's CityGen include file is
>> that each building is now called by a macro and generated individually
>> at runtime. Whereas originally a single copy (more or less) of a
>> building was stored in an array and replicated/duplicated when needed.
>>
>> The other difference of course is that buildings now have greater
>> complexity. They make use of more CSG operations and feature a greater
>> number of storeys.
>>
>
> You have a "concave" geometry composed of many objects made out of
> coaxyal cylinders slices. This can very easily lead to bounding problems
> where most objects bounding boxes overlap each other, and are
> excessively large.
>
> Try manualy bounding the individual buildings. Try to see if you can use
> some mesh.
> Use simple boxes or prisms for narrow buildings and some of the farder
> ones. Some/most broad buildings probably can do with only a texture that
> curves instead of the actual floors.
>
> Except for the closest buildings, don't model individual floors. A flat
> topped conical building can be a simple truncated cone. The flat base
> beed hiden under the ground. If needed, remove a small cylindrical part
> from it's top.
>
> Only model the interior of a building IF you look from it's inside or
> take a closeup look into it. Use conditional statements, possibly based
> on insideness test or bounding box test to toggle the insides as needed.
>
>
>
> Alain
Here's the macro I use to generate the concave cylinder sections:
#macro cyl_box(in_star, in_stop)
#local in_star_height = city_radius - in_star.y;
#local in_stop_height = city_radius - in_stop.y;
#local in_star_z_angle = in_star.x/city_circum * 360;
#local in_stop_z_angle = in_stop.x/city_circum * 360;
difference
{
cylinder {<0,0,in_star.z-0>, <0,0,in_stop.z+0>, in_star_height}
cylinder {<0,0,in_star.z-1>, <0,0,in_stop.z+1>, in_stop_height}
plane {+x, 0 rotate z * in_star_z_angle}
plane {-x, 0 rotate z * in_stop_z_angle}
bounded_by {cylinder {<0,0,in_star.z-0>, <0,0,in_stop.z+0>,
in_star_height}}
}
#end
Can I use an object produced by this macro as a bounding object? Would
it be better to use a mesh instead? Does bounding work on unions and
merges as well as differences and intersections?
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.06.2010 01:31, schrieb SharkD:
> difference
> {
> cylinder {<0,0,in_star.z-0>, <0,0,in_stop.z+0>, in_star_height}
> cylinder {<0,0,in_star.z-1>, <0,0,in_stop.z+1>, in_stop_height}
> plane {+x, 0 rotate z * in_star_z_angle}
> plane {-x, 0 rotate z * in_stop_z_angle}
> bounded_by {cylinder {<0,0,in_star.z-0>, <0,0,in_stop.z+0>,
> in_star_height}}
> }
That bounded_by gives you no benefit; try computing a snugly fitting box
instead.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD <pos### [at] gmailcom> wrote:
> Can I use an object produced by this macro as a bounding object? Would
> it be better to use a mesh instead?
> Does bounding work on unions and
> merges as well as differences and intersections?
Difference and intersection benefit most from manual bounding, because in many
cases the auto bounding box can be orders of magnitude larger than the result of
the CSG operation. I once wrote a curved-brick macro that achieved something
like 10x speedup once I sorted the bounding out.
Meshes will be faster (non-csg meshes, at least), although presumably that would
mean more work for you... :-(
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I seem to have resolved most of the bounding image. The following test
render only took about an hour to render. Not bad.
--
http://isometricland.com
Post a reply to this message
Attachments:
Download 'gh_scene_spinner_cubemap_r.png' (554 KB)
Preview of image 'gh_scene_spinner_cubemap_r.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/17/2010 4:54 AM, SharkD wrote:
> I seem to have resolved most of the bounding image. The following test
> render only took about an hour to render. Not bad.
>
"Bounding issues", rather. Also forgot to mention that I replaced all
the cylinders, spheres and so forth with meshes. However, I wasn't able
to detect any performance improvement in this particular instance.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A new building type, as well as pedestrians, trash cans and potted plants.
--
http://isometricland.com
Post a reply to this message
Attachments:
Download 'gh_scene_buildingstrip_curve_f.jpg' (111 KB)
Preview of image 'gh_scene_buildingstrip_curve_f.jpg'
|
|
| |
| |
|
|
|
|
| |
|
|
