Christoph Hormann wrote:

> As Chris Cason has mentioned in the status report 3.6 does not introduce
> significant new features in the core functionality.
> 
...which is perfectly acceptable (to me). 

> I don't think this would be a very useful patch - selecting and copying
> a rectangle from a larger image is the task for an external program,
>
Yes, but there are two reasons for my approach: 
(1) Opening a 1Gb file in an external program, selecting some part, 
    saving it... all that for every view port is too much work for me. 
(2) The cut-down chunk needs extra calculations to make sure the 
    image map projection is exactly correct. 
My patch saves me from both these. 

Still it is probably a very special thingy and of little use for 
most people. 

> what would be really useful would be a patch that adaptively loads those
> parts on an image into memory that are actually used - without the need
> to specify a rectangle and that also unloads those parts that are no
> more needed during render progress to free space for new parts.  Of
> course such a feature would not only be useful for images but also for
> meshes for example.  AFAIK some other raytracing programs also have such
> a feature.
> 
I actually had the plan to implement something like that for meshes 
before I came accross the possibility using the isosurface for the topo. 

In-memory (de)compression of the data was another approach I thought of. 

> This is of course no way my decision but to be frank - it does not seem
> to me that you propose to be allowed source access primarily to fix
> bugs, this is perfectly possible with the 3.5 code and some of your
> proposals have already been included in 3.6 (and the last two probably
> will be as well).
> 
But...
> Well i only suggested you might *save* time by waiting.

I was told the same argument some time ago. It read like "we did a 
complete rewrite of unix.cpp but you can do everything with the old 
version so feel free to send us patches for the old code". 

I could consider that as an expression of no interest in what other 
people are doing. It's a bit like preaching water and drinking wine. 

Don't you think that this effectively hinders futher development?
It makes me waste time writing patches for old code which have to 
be converted to the new code. It makes the POVRay team waste time 
getting patches based on one-year old code base. And finally, most 
of the bugs I see come from looking at the source, not from using 
a binary. 

Don't understand me wrong: I respect any decision the POVRay team 
makes. 

But I see a further possibility using the following roadmap:
(1) get povray 3.6 out
(2) bring out long awaited new megapov based on 3.6
(3) more frequent megapov updates

In this case I'd be more happy to see current megapov development 
and to be able to write patches for (or even contribute to) megapov 
[than to mainline povray] anyways. 

To me (as looking at it from outside) it seems like there would be 
enough ideas, code and manpower around here for quite some innovation 
but there is somebody somewhere out there actively pulling the break. 

I learned that in most cases it turns out negatively to hinder those 
people who want to work (and have the ability to do it well) from 
doing their work. 

Wolfgang

Post a reply to this message