|
![](/i/fill.gif) |
In article <390380D7.3DF36E34@videotron.ca>, pk <thi### [at] videotron ca>
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] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |