On 13/06/2010 11:20 AM, SharkD wrote:
> On 6/13/2010 5:58 AM, Stephen wrote:
>> It looks like it might be worth it. :-D
>
> Well, the last time I rendered the full scene it took all night. That
> was before the recent changes. :(
>

Quality is not cheap ;-)

-- 

Best Regards,
	Stephen

Post a reply to this message

On 6/13/2010 10:30 AM, Stephen wrote:
> On 13/06/2010 11:20 AM, SharkD wrote:
>> On 6/13/2010 5:58 AM, Stephen wrote:
>>> It looks like it might be worth it. :-D
>>
>> Well, the last time I rendered the full scene it took all night. That
>> was before the recent changes. :(
>>
>
> Quality is not cheap ;-)
>

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.

-- 
http://isometricland.com

Post a reply to this message

Another render showing another new building type and a variety of other 
objects.

-- 
http://isometricland.com

Post a reply to this message

Attachments:
Download 'gh_scene_buildingstrip_curve_d.png' (322 KB)

Preview of image 'gh_scene_buildingstrip_curve_d.png'

"SharkD" <pos### [at] gmailcom> 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

Post a reply to this message

On 14/06/2010 7:11 AM, SharkD wrote:

>>
>> Quality is not cheap ;-)
>>
>
> 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.
>

Not for me to answer as I seldom use radiosity. 10 seconds a pixel, WOW!
-- 

Best Regards,
	Stephen

Post a reply to this message

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] gmailcom>  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