In article <390380D7.3DF36E34@videotron.ca>, pk <thi### [at] videotronca> 
wrote:

> Don't you think that encapsulating(system call) the code would be
> better?
> And, what if i want to program in basic or pascal or whatever...
> I think that you might want to add some feature directly in MegaPOV's
> code, but still offer the opportunity to use your own post-processing
> stuff on a single image, instead of doing a patch for one job...

Uh, what? I don't understand what you mean...I don't think you are 
saying POV should have a built in C/Pascal/BASIC interpreter/compiler so 
you could write post-process filters with those, but I don't see what 
else you could mean...
POV is written in C, but that language doesn't have anything to do with 
POV syntax. The syntax of these "film types" has already been designed 
and implemented, it would just be another post_process filter. And the 
code is probably pretty well encapsulated already, I think most of the 
post_process stuff is in postproc.c and postproc.h. And what do you mean 
by "system call"?

Are you trying to say that these filters should be implemented as 
separate programs written in any language that are called by POV? I 
doubt this is possible to do in a cross-platform way...and how would it 
would it be an improvement over the current post_process patch? The 
source is available already, you could just modify that. The C code 
should be easy enough to copy and modify, even if you don't completely 
understand it. And if you insist on writing a filter in a language other 
than C, or don't want to put it in the POV-Ray program, you might as 
well make it a stand-alone utility.


> > Also, I think the post_process stuff really belongs in the camera, not
> > global_settings. This is just personal preference, though...
> Well... it'd fit better there in most ways of thinking, but if you see
> it in a hierarchical way, where the cam is part of the scene, it'd
> belong in the global settings, i think....

If you viewed the scene that way, the camera should also be in 
global_settings...which, of course, it isn't.
It just seems more logical to have things that directly affect the 
output image part of the camera statement, rather than global_settings 
(which seems to be intended more for settings than for specification of 
special effects).

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message