Jan Walzer wrote in message <396a1818@news.povray.org>...
>But other way around, what were if you paint a nice Pic' with
>maybe PS, take it as a texture for the only Object I have in my
>Scene, a box, put my camera into the right angle, tweak the

>POV...


I did just that as a joke for my "Gardens" entry.  (I was rather busy at the
time rendering my "Robots" animation, so I didn't have the time for a
serious entry.)  I got the expected low score.

Mark

Post a reply to this message

Fabien Mosen wrote in message <396A33C4.63192B27@skynet.be>...
>Given
>that 5% of them doesn't even understands what is a topic, such a rule
>would be useless.


From a quick glance at my votes for this round and the "Landmarks" round,
this is about correct.  In each of them, there were four entries that I felt
had no connection whatever with the topic, out of about 80 entries total.

Mark

Post a reply to this message

On Mon, 10 Jul 2000 19:41:09 +0200, "Jan Walzer"
<wal### [at] informatikuni-hallede> wrote:

>But other way around, what were if you paint a nice Pic' with
>maybe PS, take it as a texture for the only Object I have in my
>Scene, a box, put my camera into the right angle, tweak the

>POV...

>I'm sure it would perfectly considered as rule violation ....????

Tecnically, no. You should expect low scores on "Technical". Some time
back, though, an entry won which was, judjing by the description, just
some textures and objects from the MAX package. Granted, it was a nice
image (that's why people pay $$$ for MAX and the like) but if it
hadn't won, I truly doubt it would have had the Technical Merit award
:)


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

Post a reply to this message

Warp wrote:

>   As someone already noted, the post_process of megapov is really a 3D effect
> since it uses the depth information (and also other information as normal
> vectors etc). Although they are applied to the final image, in practice they
> still use information from the 3D scene to make the job.

Except of course, for:

12.5. Other Filters
12.5.1. Patterned Blur
12.5.2. Stars
12.5.3. Posterize
12.5.4. Normal
12.5.5. Multiply, Add, Exponent
12.5.6. Clip Colors
12.5.7. Invert
12.5.8. Find Edges
12.5.9. Convolution Matrix
12.5.10. Color Matrix

Post a reply to this message

Greg M. Johnson <gre### [at] my-dejanewscom> wrote:
: 12.5.4. Normal
: 12.5.8. Find Edges

  I think those use 3D-information from the 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

Greg M. Johnson wrote in message <39AEAA72.B76729B9@my-dejanews.com>...
>Except of course, for:
>
>12.5. Other Filters
>12.5.1. Patterned Blur
>12.5.2. Stars
>12.5.3. Posterize

>12.5.5. Multiply, Add, Exponent
>12.5.6. Clip Colors
>12.5.7. Invert


>12.5.9. Convolution Matrix
>12.5.10. Color Matrix

I believe that these use the unclipped colors, which are completely
unaccessable to external programs.

Mark

Post a reply to this message

"Fabien Mosen" <fab### [at] skynetbe> wrote...
> Nathan Kopp wrote:
> >
> > ...which is a big reason why I think POV needs post-processing built in.
> > Actually, I think that POV should have post-processing utilities as part
of
> > the distribution, specifically designed to work with POV, though not
part of
> > the primary EXE.  Of course, in that case the IRTC rules would have to
be be
> > changed.
> >
> > I don't know how to change the IRTC rules, but they currently seem to
favor
> > other rendering engines over POV (I'm talking about the official POV
here,
> > not MegaPov), and to me that seems a bit "backwards".
>
> To me, the true spirit of that rule is that every effect should be
> 3D-related.  Applying gaussian blur all over, or manually, is not
> 3D-related.  But if the blur, even post-processed, uses 3D information
> to know where and how it applies, it's fine.

The exact rule is: "Images must not be enhanced or altered
('post-processed') by use of paint programs such as PhotoShop(tm) etc"

What I'm wondering about is this:
Instead of having post-processing built into the core of POV, it is provided
(with the package distribution) as a separate tool.  The core POV-Ray would
output a data file containing the 3d data, along with the image file.  The
post-processing tool would then be used to read in the original image and
the 3d data and produce a new image file.

This post processing tool _could_ be considered to be part of the rendering
tool, since it is part of the package.  It definately could not be
considered to be a "paint program such as PhotoShop(tm)".  So, would such an
implementation be acceptable under the current rule?

-Nathan Kopp

Post a reply to this message

Nathan Kopp wrote:

> This post processing tool _could_ be considered to be part of the rendering
> tool, since it is part of the package.  It definately could not be
> considered to be a "paint program such as PhotoShop(tm)".  So, would such an
> implementation be acceptable under the current rule?

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.
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
you would be walking a fine line with this one and the
armchair lawyers could present reasonable arguments against
it.

My 2c only.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Nathan Kopp wrote:

> What I'm wondering about is this:
> Instead of having post-processing built into the core of POV, it is provided
> (with the package distribution) as a separate tool.  The core POV-Ray would
> output a data file containing the 3d data, along with the image file.  The
> post-processing tool would then be used to read in the original image and
> the 3d data and produce a new image file.

This is a very good idea, indeed, and this would correct the main
problem with current implementation, where you have to re-render the
whole image to change the post process !!

> This post processing tool _could_ be considered to be part of the rendering
> tool, since it is part of the package.  

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 {..} ).

> It definately could not be
> considered to be a "paint program such as PhotoShop(tm)".  So, would such an
> implementation be acceptable under the current rule?

Of course, if it's part of the package, no objection could arise.

Fabien.

Post a reply to this message

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)
but still they are lost without the main renderer because they need
information which is only available there (for example to motion-blur
a single object etc.) A paint program has access to the final image
data only and thus can't have depth-, object-, unclipped brightness-
etc. dependant functions.

So I think that even if the post processing engine is a separate
executable, or it's even some kind of plug-in engine, it will still
lie within the rules.


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

Post a reply to this message