Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> [...]
>> 
>> If you think that I should re-implement PRTRenderer's functionality
>> using plain C and use PRTImageData and PRTTileHeap for their
>> purposes, I will very likely consider doing that.
> 
> PRTImageData and PRTTileHeap are both completely undocumented 
>
No, they are not. The header file contains a small comment on the 
functionality of the methods. I normally put my docu into the header 
and not into the .cpp files because when I want to use the code 
lateron, I using the headers is more convenient. 

But of course, more comments explaining some general ideas and 
workings should be added. 

> and they
> do some really strange things - using 16 bit values for the image for
> example is understandable for memory size reasons but this makes it
> essentially incompatible to other patches (HDR output, post processing).
> 
Ah, you are right. In case there are other patches or parts of the code 
which need the complete image in memory, one should design and implement 
exactly one class which can do so if needed and can be used by all other 
parts. This class should be able to handle 16 bit precision if required. 

It should, however, not be the default, because the row-by-row 
working of povray enables users to generate images of real large size 
(6000x6000 which would use 200Mb for the PRT image buffer alone). 

BTW, Since when did I have access to HDR output and post processing code?

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> [...]
> 
> I consider the introduction of these two classes as good design. 

Speaking of good design:

static inline void PRT_interpolate_linear(COLOUR *dest,
	COLOUR *l,COLOUR *r,float p)
{
	for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
	{  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
}

For constructions like this you deserve to get shot.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Wolfgang Wieser wrote:
>>and they
>>do some really strange things - using 16 bit values for the image for
>>example is understandable for memory size reasons but this makes it
>>essentially incompatible to other patches (HDR output, post processing).
>>
> 
> Ah, you are right. In case there are other patches or parts of the code 
> which need the complete image in memory, [...]

No, this is not about keeping the whole image, it is about keeping the 
unclipped full precision color values.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <ofa### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Speaking of good design:
>
> static inline void PRT_interpolate_linear(COLOUR *dest,
>  COLOUR *l,COLOUR *r,float p)
> {
>  for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
>  {  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
> }
>
> For constructions like this you deserve to get shot.

Hey, that is *my* line! ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>>>and they
>>>do some really strange things - using 16 bit values for the image for
>>>example is understandable for memory size reasons but this makes it
>>>essentially incompatible to other patches (HDR output, post processing).
>>>
>> Ah, you are right. In case there are other patches or parts of the code
>> which need the complete image in memory, [...]
> 
> No, this is not about keeping the whole image, it is about keeping the
> unclipped full precision color values.
> 
...probably including transparency and filter which sums up to 20 bytes 
per pixel which may get a problem when storing the whole image. 

So, my idea would be a class which can save the complete image at 
different resolutions: 8bit, 16bit, full float. If there are several 
code parts in need of such a storage, the one with the highest resolution 
demand will set the internally used format. 
The interface would use COLOUR, but the internal data representation 
would allow different formats to save memory. 

(And I am not only talking about it, I would also consider writing 
such a class if it is needed.)

Wolfgang

Post a reply to this message

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> [...]
>> 
>> I consider the introduction of these two classes as good design.
> 
> Speaking of good design:
> 
> static inline void PRT_interpolate_linear(COLOUR *dest,
> COLOUR *l,COLOUR *r,float p)
> {
>       for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
>       {  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
> }
> 
> For constructions like this you deserve to get shot.
> 
(1) This does not come from one of the two classes. 
    I explicitly put the functions doing the dirty things as 
    some inline functions at the beginning of the file. 
    (pure C guys would use macros here...)
(2) These functions are actually older than the PRT patch. 
    They go back to my IPT patch. 
(3) What would you suggest as the "best" solution? 
    I'll be happy to replace it. 

Wolfgang

BTW, I like these much much better:

#define Assign_Colour_Express(d,s)  {(d)[pRED] = (s)[pRED]; (d)[pGREEN] = \
        (s)[pGREEN]; (d)[pBLUE] = (s)[pBLUE]; (d)[pFILTER] = (s)[
#define Make_Colour(c,r,g,b) {(c)[pRED]=(r);(c)[pGREEN]=(g);\
        (c)[pBLUE]=(b);(c)[pFILTER]=0.0;(c)[pTRANSM]=0.0;}
#define Make_ColourA(c,r,g,b,a,t) {(c)[pRED]=(r);(c)[pGREEN]=(g); \
        (c)[pBLUE]=(b);(c)[pFILTER]=(a);(c)[pTRANSM]=t;}
#define Make_Vector(v,a,b,c) { (v)[X]=(a);(v)[Y]=(b);(v)[Z]=(c); }
#define Make_UV_Vector(v,a,b) { (v)[U]=(a);(v)[V]=(b); }
#define Destroy_Colour(x) if ((x)!=NULL) POV_FREE(x)
#define Make_RGB(c,r,g,b) {(c)[pRED]=(r);(c)[pGREEN]=(g);(c)[pBLUE]=(b);}

What about shooting the author(s) with a machine gun? :p

Post a reply to this message

In article <401411d2@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> What about shooting the author(s) with a machine gun?

You will have a hard time doing this in 3.6...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <221### [at] tritonimagicode>, chr### [at] gmxde 
says...
> Patrick Elliott wrote:
> > 
> > Actually it is more of an issue with an external program. It is called 
> > wasted time. It may only be 4-5 minutes, but it is still time you spend 
> > screwing with an external program (that may even crash in some cases with 
> > an image 1G in size)[...]
> 
> Sorry but this is complete nonsense, i have been cutting subsets from 
> large images for a long time now and it does not take any longer than to 
> parse such images in POV (why should it - it is essentially the same 
> operation).  And the  memory use while doing that is minimal.
> 
> Christoph
> 
> 

Umm. Then I am a tad confused... Do you mean executing that program from 
inside POV? Unless this is what you mean, then I haven't a clue what you 
are talking about here. I am talking about limited the total size of the 
file you load in POV-Ray by chopping up the original into smaller bits, 
so when you do use them, you are loading much smaller ones.

As for it being the same operation. Some programs are memory hogs, have 
glitches when dealing with truly hug files, etc. And not all of us can 
afford to buy one that doesn't to replace whatever we are already using. 
The fewer extra programs you have to fiddle with to get something done 
the better imo.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

In article <4012d99e@news.povray.org>, wwi### [at] gmxde says...
> Patrick Elliott wrote:
> 
> > a height field, c) some other thing... You might have better luck
> > convincing people 
> >
> I do NOT want to convince anybody. 
> I just had that idea and implemented it (in a dirty way) for me 
> because I need it. 
> Just in the unlikely event that several people were saying 
> "Ah, I've been looking for that already", I would have considered 
> making a real patch from it and ask for inclusion. 
> 
Missing the point. You stated that you made a change, gave the code, but 
never actually said how or why you are using it. This is sadly one of the 
reasons why some great ideas never see the light of day. It is not enough 
to toss code into people's laps and say, "Here is something I did. Maybe 
someone will find it useful." You also have to tell them what the heck 
you thought it was useful for. You didn't do that until someone a great 
deal brighter than me questioned 'how' you did it and suggested 
transparency.

> > that filling the image, instead of simply clipping is
> > better, if we had an example of what you are doing with it. ;)
> > 
> http://www.cip.physik.uni-muenchen.de/~wwieser/render/img/mars/#landingspirit
> 
> BTW, I have to thank Christoph for the idea to make the angle of the 
> light sooo flat. (And my atmosphere is basically the earth rendering 
> atmosphere with red and blue components exchanged and absorption 
> removed ;)
> 
Now, there is what I meant. A wonderful example. Now someone can look at 
it as say, "Heh, that's something I could really use. Where is the 
patch?" I may even use it myself some time. I have a program I designed a 
while back involving a GPS locations database, but always wanted to put a 
map in with it. The problem was a) I didn't want a 1G files, which I 
couldn't put on a CD anyway and b) I couldn't find any smaller version 
that where not pure junk. Being able to take a 1G file of the place I 
want and render a series of smaller images that are easier to load would 
be very helpful. Now I just need to find the damn map I need to do it 
with... lol

Of course I also don't have, want to, or plan to compile a patch myself, 
so unless this does find its way into MegaPOV or something, I probably 
still won't use it. My philosophy is that if you don't understand even 
10% of how a program works, don't screw with any of it yourself. ;) lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

On Sun, 25 Jan 2004 19:58:02 +0100, Wolfgang Wieser <wwi### [at] gmxde> wrote:
> #define Assign_Colour_Express(d,s)  {(d)[pRED] = (s)[pRED]; (d)[pGREEN] = \
>         (s)[pGREEN]; (d)[pBLUE] = (s)[pBLUE]; (d)[pFILTER] = (s)[
> What about shooting the author(s) with a machine gun? :p

Apart all others things mentioned in this thread I find:

  (d)[pRED] = (s)[pRED]

much better "designed" than

  sizeof(COLOUR)/sizeof(float)

ABX

Post a reply to this message