[GRASS-dev] Ignored enhancements

[Seth Price]

It's been a while, but I think one motivating factor is the limiting GPU RAM. If we can't fit everything on the GPU, then it needs to be tiled. The only way to accurately tile is to make each tile independent of its surroundings. This can be done arbitrarily small with pre computed horizons.

I think the other reason is the whole pre computation (but only once) thing you mention.

I don't think it bothers me too much at the moment what you decide to do with it, but the shadowing & tiling code becomes more complicated to compensate.
~Seth


via iPhone

On Feb 12, 2013, at 2:10 AM, Hamish <hamish_b at yahoo.com> wrote:

> Doug wrote:
>> I appreciate the effort.
> 
> (me too :)
> 
>>  Working with  large rasters, this will make a big difference! 
> 
> with respect to r.hozion, I'm still trying to understand where
> the best use case for it is.
> 
> the idea as I understand it (which is not completely) is that
> it precomutes some of what r.sun does, so that the r.sun module
> runs faster. But the r.sun module places the sun exactly where
> it wants it, while r.horizon must make some compromise and
> approximate the position. to get any sort of reasonable placement
> you'd need upwards of 100 seed maps, but since r.sun must open
> them all at once the performance hit you take from the extra
> overhead cancels out the speed gain. And so you have more disk
> I/O with worse positioning -- better not to have used r.horizon
> at all?
> 
> see further discussion and benchmarking in "r.sun2 commissioning
> trials":
>  http://trac.osgeo.org/grass/ticket/498
> 
> and on the r.sun page in the wiki:
>  http://grasswiki.osgeo.org/wiki/R.sun#Seed_maps
> 
> 
> thanks for any light you can shed on this, it has puzzled me
> for a while.
> 
> 
> Hamish