Warp wrote:

> Ger <No.### [at] thankyou> wrote:
>> >   I would prefer 1000 times more to do post-processing of the final
>> >   image
>> > with POV-Ray itself than having to code a separate program for that
>> > purpose. It would simply be way too cumbersome, waste disk space, waste
>> > time, and waste everything.
>> > 
>> I just wonder how you would want to integrate things like
>> Photoshop/Gimp/Krita etc and MainActor/VisualStudio into POV.
> 
>   You didn't understand me.

Not impossible :)

> 
>   When POV-Ray renders the image it has tons of additional information
> about it besides simply the pixels. It has depth information, normal
> information, all kinds of other things. In order to post-process the
> image using this information you need to either save it all in files
> and then write a program which reads them and does the post-processing,
> or you can write a simple script in the future SDL to do the same thing.

Agreed, and this is something that I would call  "Stuff that acts upon the
render" ie. work that is done before the final image is saved to disk.

> 
>   Something like cell-shading or edge finding will probably take a few
> lines of SDL code, while with the gimp or photoshop it's *impossible*
> to do (at least with the same accuracy).
> 
Agreed again, but what I was referring to is the myriad of functions, like
JPG conversion/scaling/rotating and whatnot.
-- 
Ger

Post a reply to this message

Warp wrote:
> Shay <Sha### [at] cccc> wrote:
>> can be accomplished 
>> more easily with outside tools.
> 
>   I disagree in two counts:
> 
> 1) "Can be accomplished" is not always true. You can't add new
> rendering features to POV-Ray with outside tools. It's just
> impossible.

Nice how you clipped "much of what" from my post.

> 
> 2) Even when using a supported rendering technique, "more easily"
> is often just not true. Using things like third-party converters,
> automatic mesh manipulation programs and such is usually much more
> cumbersome than if you could do the exact same thing in POV-Ray
> itself by simply writing one #include line and one function call.
>   Possible? Yes. More easily? Often not. Not even equally esily.

This is all assuming the #include file has been produced. Now, which 
sounds easiest for producing that include file?

A) Code the algorithm into the POV source code.

B) Code the algorithm (ugly hacks and all) into current or slightly 
expanded and debugged SLD.

C) Invent and code a new programming language and then code the 
algorithm in that language.

  -Shay

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> C) Invent and code a new programming language and then code the 
> algorithm in that language.

  Right, because all that is necessary for every single algorithm which
will be ever made for POV-Ray.

-- 
                                                          - Warp

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Alvarez wrote:
> That is already possible, since 3.something. Have you ever seen
> "shell-out commands"? Post_Scene_Command and stuff?

Fair enough.

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you spend 11 days on a
makefile for a *strange* flavor of Unix, just to 'do a POV benchmark'.
    -- Neil Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHApKzcCmTzQ++ZncRAjF1AJ9WJjfJoIFUq++f0ksx5XIqRzAFlgCfc73w
fljWQUNPHEdR3Adkv4TypwY=
=/i/v
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> andrel wrote:
>> It could also make the POV community diverge in groups with different sets
>> of libraries. E.g. because some libraries are only available for a
>> subset of OSes.
> 
> If that were the only problem, the extra flexibility would be well worth it.
>

My main concern is that if you do allow linking to other (binary) 
libraries, someone will be creating some shader stuff in visual basic, 
somebody else will do the same using gcc and another one will decide 
that most windows users don't have a c-compiler, nor access to a 
proprietary language and starts implementing something more or less the 
same but with a slightly more adequate syntax in perl. While, of course 
Haskell is the language that is conceptually the best match for shaders. ;)

> This is one of those things that I would only expect 10% of the userbase
> to even touch--if lots of people wind up needing it, it's because we
> screwed something up.

yes

Post a reply to this message

> Ger <No.### [at] thankyou> wrote:
>> I think you need to make the distinction between "Stuff that acts upon the
>> render" and "Stuff that acts upon the finished image". The former has to be
>> inside POV. The latter better stay out.
> 
>   I would prefer 1000 times more to do post-processing of the final image
> with POV-Ray itself than having to code a separate program for that purpose.
> It would simply be way too cumbersome, waste disk space, waste time, and
> waste everything.

As long as "doing it with POV-Ray itself" gives the same flexibility as 
doing it externally.  If you have to re-render to change a post-process 
parameter, as currently in MegaPOV, it's (mostly) useless...

If, in a first move, POV-Ray gave the ability to output data (in the 
form of images, probably) about depth, normal, full color values, etc...
alongside with the actual render, it would already allow many post-
process operations with existing software (why not a specific GIMP
version...).  Flexibility is the word, in any case.

Fabien.

Post a reply to this message

>   When POV-Ray renders the image it has tons of additional information
> about it besides simply the pixels. It has depth information, normal
> information, all kinds of other things. In order to post-process the
> image using this information you need to either save it all in files
> and then write a program which reads them and does the post-processing,
> or you can write a simple script in the future SDL to do the same thing.

How, in this model, do you adjust a parameter like focal point (in
the case of a blur process) and get a new image within seconds ?

>   Something like cell-shading or edge finding will probably take a few
> lines of SDL code, while with the gimp or photoshop it's *impossible*
> to do (at least with the same accuracy).

That's mostly how commercial (I mean : production-ready) 3D does...

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:


> >   When POV-Ray renders the image it has tons of additional information
> > about it besides simply the pixels. It has depth information, normal
> > information, all kinds of other things. In order to post-process the
> > image using this information you need to either save it all in files
> > and then write a program which reads them and does the post-processing,
> > or you can write a simple script in the future SDL to do the same thing.

> How, in this model, do you adjust a parameter like focal point (in
> the case of a blur process) and get a new image within seconds ?

  I'm not really sure what you are asking.

-- 
                                                          - Warp

Post a reply to this message

I am a bit disappointed. All I can see here is blah-blah, little polemics,
and verbal fights. Nothing constructive. If somebody has in mind something
that ressembles a solution, please express and propose actual ideas,
examples of how you see things in the future! You seem to prefer replying
endlessly for nothing worth. If we go on like this, we'll never know WHAT
we want, and never have any new SDL ...


Bruno

Post a reply to this message

Bruno Cabasson wrote:
> I am a bit disappointed. All I can see here is blah-blah, little polemics,
> and verbal fights. 
This one is so deeep in the thread that I cannot even see to which this 
is a reply, so I will assume you mean all of us except yourself.
> Nothing constructive. 
On the contrary this is very constructive. Many people contributing on 
many levels.
> If somebody has in mind something
> that ressembles a solution, please express and propose actual ideas,
> examples of how you see things in the future! 
I, and probably many others with years of (bad) experience with 
premature programming, am not ready yet to express solutions yet. I 
haven't even decided very fundamental issues for myself. Such as if POV4 
should be a scene description language or a ray tracer. The difference 
being whether the scene is fundamental and you happen to get an image if 
you place a camera in it or if its main purpose is to generate an image. 
For most applications that will not matter, but technology may change 
and a computer screen or a poster on the wall may not be the only 
available options. New technology like 3D display techniques and 3D 
printers for instance and no doubt in the next decade many other will 
follow. Such fundamental decisions may have an enormous impact on the 
language. Another fundamental issue that is discussed is it's relation 
to other programs. That one is not resolved yet either. And there are 
many more of those. This phase may take another few weeks and I assume 
in the mean time people will start 'coding' things that should stay 
possible and things that should become possible.
> You seem to prefer replying
> endlessly for nothing worth. If we go on like this, we'll never know WHAT
> we want, and never have any new SDL ...
> 
As you might have noticed, not everybody is convinced we should have one.

Post a reply to this message