Ken wrote:

> you run the risk of being in the same boat as if you were
> to just use photoshop.exe to do your post processing work.
> Even though the way the processing is accomplished is
> different you are requiring a seperate outside utility
> that is not part of the internal rendering engine. I think

Every commercial 3D package does it with separate programs,
even though it appears transparently to the user.  
The "no post-process" rule looks now ridiculous.  It was intended
to avoid abuse of after-effects, but the literal rule isn't anymore
suited to that.  We could let that rule down as well.  Anyway,
no amount of effects can turn a bad image into a good one, and
it rather tends to destroy it.  There's an excellent example
of that problem in the "sea" images.

So, let's post-process all the way !  It doesn't matter anymore !

Fabien.

Post a reply to this message

"Peter Popov" <pet### [at] usanet> wrote...
> On Fri, 01 Sep 2000 02:59:19 -0700, Ken <tyl### [at] pacbellnet> wrote:
>
> >If you mean the distribution would contain:
> >
> >pvengine.exe
> >postproc.exe
> >
> >you run the risk of being in the same boat as if you were
> >to just use photoshop.exe to do your post processing work.
>
> Then how about MAX and all its plugins and post-processing filters?
> They are separate executables (well, not exes but still machine code)

Exactly.  It'd be great to be able to do something like that with POV (using
DLL-like things), but there is currently no possible way to do that in a
completely platform-independent way.  Using two separate executables,
passing information between them using a file, and linking them together
using some sort of a script (or POV's current built-in functionality for
running other processes before and after each frame) provides very similar
functionality as a DLL, but in a platform-independent way.  If it's legal
for those commercial rendering engines, it should be legal for POV, too.

Maybe this would require changing the rule in the IRTC.  If so, I think we
should change the rule.  If anything, the rules should encourage use of
POV-Ray, not discourage it.

-Nathan

Post a reply to this message

"Fabien Mosen" <fab### [at] skynetbe> wrote...
>
> So, let's post-process all the way !  It doesn't matter anymore !

That may not be the best idea, since it would allow more junk images in (a
little bit of rendering, but most of the stuff done in Photoshop).  A
re-wording of the rule to capture more of the original intent would be
better, IMHO.

-Nathan

Post a reply to this message

On Sat, 2 Sep 2000 14:00:30 -0400, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Exactly.  It'd be great to be able to do something like that with POV (using
>DLL-like things), but there is currently no possible way to do that in a
>completely platform-independent way.  

How about Java? Post-processing does not usually account for a large
chunk of the total production time of a render so speed is not an
issue. Or if not java, maybe some other cross-platform language like
python.

>If it's legal
>for those commercial rendering engines, it should be legal for POV, too.

Is it currently not?

>Maybe this would require changing the rule in the IRTC.  If so, I think we
>should change the rule.  If anything, the rules should encourage use of
>POV-Ray, not discourage it.

Ditto that.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Nathan Kopp wrote:
> 
> "Fabien Mosen" <fab### [at] skynetbe> wrote...
> >
> > So, let's post-process all the way !  It doesn't matter anymore !
> 
> That may not be the best idea, since it would allow more junk images in (a
> little bit of rendering, but most of the stuff done in Photoshop).  A
> re-wording of the rule to capture more of the original intent would be
> better, IMHO.

Sure.  Could be something like "post-processing is admitted, as long
as it couldn't have been done in a strictly 2D paint program".. or
".. as long as 3D information is used in the process".. or "as long
as it is an automated process".. or maybe all that together !

Regarding my last entry (fmsea.jpg), I'm very happy that the
post_process focal blur exists !  Thanks programmers !!

Fabien.

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: How about Java?

  It's not available for every platform povray is.
  And why use a separate programming language when povray itself suffices?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote:
: Sure.  Could be something like "post-processing is admitted, as long
: as it couldn't have been done in a strictly 2D paint program".. or
: ".. as long as 3D information is used in the process".. or "as long
: as it is an automated process".. or maybe all that together !

  Better: "... as long as it's made with the same program that created
the 3D rendered image."

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Fabien Mosen wrote:
> 
> It could be a separate executable, something like "POV-Process" maybe :)
> When rendering, POV-Ray would write every information (depth,
> normals,..)
> to suited files, and you just have to indicate them to "POV-Process",
> along
> with a processing script (much like the current post_process {..} ).
> 
	Actually I would favor having one executable for each post process
filter (with a common library of helper functions probably). It would be
much more flexible and extensible (you wouldn't need to recompile the
whole thing to add a new filter) and probably easier to use too.



PS: Shouldn't this thread go to unofficial.patches?
-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote...
> Fabien Mosen <fab### [at] skynetbe> wrote:
> : Sure.  Could be something like "post-processing is admitted, as long
> : as it couldn't have been done in a strictly 2D paint program".. or
> : ".. as long as 3D information is used in the process".. or "as long
> : as it is an automated process".. or maybe all that together !
>
>   Better: "... as long as it's made with the same program that created
> the 3D rendered image."

With "program" not being limited to an single file.  Unfortunately, I think
"program" would be difficult, due to third-party plug-ins and stuff like
that.  With a good definition of "program", I like this the best.

-Nathan

Post a reply to this message

> 
>         Actually I would favor having one executable for each post process
> filter (with a common library of helper functions probably). It would be
> much more flexible and extensible (you wouldn't need to recompile the
> whole thing to add a new filter) and probably easier to use too.
> 

> 
> PS: Shouldn't this thread go to unofficial.patches?
> --

Somewhat off-topic for this group my message will be, so I set followups
to unofficial.patches (this is the very first time I use this feature,
so probably I just make mess of it ;-)

With all this post processing I thought that for implementing it similar
approach to my shader patch could be used: user writes post-processing
filter in "shading language" (C-alike syntax with common graphical
operations and types: color, point, normal, vector), compiles it into
byte-code and it is "added" to scene in POV-Ray script for
post-processing. This way it will be easy to create new filters and
change existing ones. This will not be as fast as built-in processing
(but I think that during post-processing it will not be issue), but it
allows greater flexibility. RenderMan (R) uses similar approach with the
imager shaders (
http://www.pixar.com/products/rendermandocs/toolkit/RISpec/section12.html#Imager.shaders
)
I had no time to examine post-processing and I don't know, what is
needed (in terms of POV-Ray internal variables/values/etc.) for running
post-processing filter, so if someone can sum it up or give me a link to
document, then I can say, whether it could be done easily with some
modifications of my (not-yet-released, i.e. vaporware;-) shader patch.

Post a reply to this message