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

In article <470208a9@news.povray.org>, war### [at] tagpovrayorg says...
> Ger <No.### [at] thankyou> wrote:
> > Does POV really need a new language
> 
>   Yes. You yourself gave the reason why:
> 
> > lets
> > not forget that POV needs 3 things most. Speed, more speed and some spe
ed.
> 
>   The new language doesn't have to look very different from the current S
DL,
> but some changes are necessary (for example related to macros).
> 
Precisely. It would be useful if a) it looked at least "close" to what 
we are already using, b) didn't make using it overly complicated and c) 
if they just clean up the SDL, to make it have certain features, there 
is no reason why one can't discuss the merits of other languages, so we 
have some idea what feature we *may* in fact want to add to it. If the 
choice happens to be to keep the SDL as is and "not" separate object 
handling or the like from the code level (at least enough so you can 
declare objects separate from the code, instead of burying them 
throughout the code, like they are now).

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <4701e40f@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > In *any* other language you need to do something like:
> 
> That's not true. There are a number of other possibilities, including 
> languages that have been around a lot longer than Lua and specifically 
> designed for this sort of work (as Lua was).
> 
> But since I got seriously harshed for even mentioning possibilities last
 
> time, I'm not going to continue on with this discussion.
> 
Ok, I should have said, "any language I am aware of". Point is, its a 
nice trick, which Java and many other supposed "modern" languages don't 
allow for.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <47024d79$1@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > And its method of 
> > representing arrays allow you to *literally* drop complex data 
> > structures in to the array, for immediate use. For example, in the 
> > client I use it in, if you want to get data on something as simple as a
 
> > line of text, you need to just push the data into a table in Lua, then
 
> > access it like an array. The method for transferring such data "into"
 
> > Lua is fairly trivial. Other languages *can't* handle the transfer of
 
> > such structured data. They are forced to rely on creating multiple 
> > arrays, to hold each subtype of data. So while Lua uses a single table
 
> > that looks like:
> > 
> > mytable (position)
> >   \---Letter
> >   \---Font
> >   \---Color
> >   \---Ect.
> > 
> > In *any* other language you need to do something like:
> > 
> > dim letter()
> > dim font()
> > dim color()
> > dim etc()
> > 
> > Then load **each** of those independently.
> 
> Umm... Isn't that how things work on *any* loosely-typed language?
> 
> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3)];
> 
> A valid Javascript array containing a number, another array, a string, a
 
> regular expression, and a Sphere (provided that the Sphere object was 
> defined).
> 
Well, all I know is that it wasn't, for what ever reason, possible with 
the client. That *may* be due to the fact that Java is *not* normally 
that loosely typed, or that some serious problem existed in ActiveScript 
which seriously fracked it (since it relies a lot of that for every 
language except Lua. Though, mind you, half the ActiveScript languages 
seem to not follow spec anyway and suffer from bloody silly 
inconsistencies even in how you instance them, never mind get them to do 
anything after they are linked.)

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> In article <47024d79$1@news.povray.org>, 
> nic### [at] gmailisthebestcom says...
>> Umm... Isn't that how things work on *any* loosely-typed language?
>>
>> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3)];
>>
>> A valid Javascript array containing a number, another array, a string, a 
>> regular expression, and a Sphere (provided that the Sphere object was 
>> defined).
>>
> Well, all I know is that it wasn't, for what ever reason, possible with 
> the client. That *may* be due to the fact that Java is *not* normally 
> that loosely typed, or that some serious problem existed in ActiveScript 
> which seriously fracked it (since it relies a lot of that for every 
> language except Lua. Though, mind you, half the ActiveScript languages 
> seem to not follow spec anyway and suffer from bloody silly 
> inconsistencies even in how you instance them, never mind get them to do 
> anything after they are linked.)
> 

You're mixing up Java and Javascript (they have nothing to do, name 
similarity is apparently because of marketing reasons). Java is 
strongly-typed, Javascript is loosely-typed. Java is compiled into 
bytecode, Javascript is interpreted. Java has classes, Javascript has 
prototype-based OOP instead.

Post a reply to this message