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

"Thorsten Froehlich" <tho### [at] trfde> wrote:

> ... is a great example for a design broken from
>the beginning...

Is there a way to talk about (may be even discuss :-) some design
aspects of the V4.0 without starting a flame war?

Andreas

Post a reply to this message

In article <40153b45.617729628@news.povray.org> , kai### [at] siemenscom 
(Andreas Kaiser) wrote:

>> ... is a great example for a design broken from
>>the beginning...
>
> Is there a way to talk about (may be even discuss :-) some design
> aspects of the V4.0 without starting a flame war?

No.  As the status update says, we do not want to and will not enter into
any public discussion about 4.0 at this time.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

ABX wrote:
> Apart all others things mentioned in this thread I find:
> 
>   (d)[pRED] = (s)[pRED]
> 
> much better "designed" than
> 
>   sizeof(COLOUR)/sizeof(float)
> 
Is there a define/const int anywhere which tells me the size 
of the COLOUR array?

Hard-coding the size 5 into MY code seems to be the worst solution. 

Wolfgang

Post a reply to this message

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

> Is there a define/const int anywhere which tells me the size
> of the COLOUR array?
>
> Hard-coding the size 5 into MY code seems to be the worst solution.

Well, there is nothing in there that says it has to be a float, does it?  So
this should read sizeof(COLOUR)/sizeof(COLC) if you really insist on the
rather pointless idea to assume the COLOUR could ever change its number of
componenents in 3.x code...

The "correct" way to implement you interpolation would be to follow current
implementation, which is to put the interpolation into a macro or inline
function in colour.h .  This way anybody who might really want to try to
change the number of color components could easily find your code next to
the other code operating on colors.

    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

Thorsten Froehlich wrote:

> In article <40197115@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> Is there a define/const int anywhere which tells me the size
>> of the COLOUR array?
>>
>> Hard-coding the size 5 into MY code seems to be the worst solution.
> 
> Well, there is nothing in there that says it has to be a float, does it? 
> So this should read sizeof(COLOUR)/sizeof(COLC) if you really insist on
> the rather pointless idea to assume the COLOUR could ever change its
> number of componenents in 3.x code...
> 
Actually, I had in mind that color is "an array of 5 floats" and I did 
not look it up to see that it is really COLC when writing the code. 
But, right, COLC is certainly better. 

> The "correct" way to implement you interpolation would be to follow
> current implementation, which is to put the interpolation into a macro or
> inline
> function in colour.h .  This way anybody who might really want to try to
> change the number of color components could easily find your code next to
> the other code operating on colors.
> 
Yes. But in order to make hand-patching future versions of POVRay more 
easy for me, I decided to put as much code as possible into one extra 
file. 

There is no doubt that in case one actually wants to integrate this 
patch into megapov or povray, some code has to be placed at different 
locations. 

Wolfgang

Post a reply to this message