Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> And if the shader language is, in fact, an existing language, like C or Ruby,
> or any smart choice, making use of POV-Ray-specific classes, efficient
> compilation shouldn't be a problem (I think).

  There's a difference between something being inside the core C++ codebase,
and something JIT-compiled at runtime.

  Modern C++ compilers are quite good at optimizing, and it would be quite
hard for the JIT-compiler of any given scripting language to match that
level of optimization.

  Even if some JIT-compiler of some scripting language would achieve the
same speeds, the C++ compiler still has some advantages, such as being
able to inline certain functions for added speed (which naturally cannot
be done with JIT-compiled functions because they are unknown at the core
code compilation stage). Not that this matters a whole lot, but still.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > And if the shader language is, in fact, an existing language, like C or Ruby,
> > or any smart choice, making use of POV-Ray-specific classes, efficient
> > compilation shouldn't be a problem (I think).
>
>   There's a difference between something being inside the core C++ codebase,
> and something JIT-compiled at runtime.
>
>   Modern C++ compilers are quite good at optimizing, and it would be quite
> hard for the JIT-compiler of any given scripting language to match that
> level of optimization.
>
>   Even if some JIT-compiler of some scripting language would achieve the
> same speeds, the C++ compiler still has some advantages, such as being
> able to inline certain functions for added speed (which naturally cannot
> be done with JIT-compiled functions because they are unknown at the core
> code compilation stage). Not that this matters a whole lot, but still.
>
> --
>                                                           - Warp

I agree with Warp, with the following remarks:

-) We do not need that much speed for parsing, and if this allows us to meet
our requirements (object-orientedness and object-oriented notation, modules,
user-defined classes & methods, addons & new features,  user-definable
stuff, etc ...), we can sacrify some speed for it.

-) We need maximum computation power at render time. What are the quickest
langages for heavy computations? Basically, C++ is quick and very popular
among programmers (hackers or in industry) and benefits a lot of stuff.
FORTRAN (yes, I dared!) is also quick and takes better advantage of
vectorized computations and of processor pipelines, specialized in maths,
still very used in the industry yet much less popular, and benefits also a
lot of stuff.

-) What are the current langages supporting JIT? What are their
performances?

-) What are the langages which are best cross-platform and OS-independent?

Maybe we can make a round and see what we have at our disposal that is
likely to satisfy us for what we want.


    Bruno

Post a reply to this message

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

nemesis wrote:
> until you realize it's something, like Perl6 itself, that has been in the
> works for about 6 years, without ever managing to get out of beta status.

Ah. Okay, then. :-)

> I was thinking... the next Povray supposedly is going to be GPL.  Would you
> guys find it feasible to ship it together with GCC?  My point is:
> JIT-compilation is still a relatively new area and there aren't sufficient
> open-source implementations out there.  But traditional ahead-of-time
> compilation is easily achieved.  If it was possible for a povray SDL script
> to be compiled before running, performance wouldn't be a problem any more.

I really can't say how SDL would take to being compiled; I can say that
GCC is going to be a little bit of overkill for our needs. ;-)

Writing a new GCC frontend for SDL would be a big project in itself.

That said, GCC already supports a huge set of processor architectures. I
would not look forward to having to support a custom JIT compiler on
every conceivable processor, and I would not like to see POV stop
working on machines that are currently supported, either.

> then, I could even suggest getting a Scheme implementation like chicken to
> be a possible SDL frontend... :)

If you want to get yourself lynched, sure... ;-)

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

You know you've been raytracing too long when you consider 2D art that
of fools.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHARSDcCmTzQ++ZncRAiN7AJ9P9/tPUU/7LIQiCbxD7bpnKcQ6PgCfR42c
2WRRkq7Yt7pHjl+0qETtokY=
=gdTu
-----END PGP SIGNATURE-----

Post a reply to this message

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

Bruno Cabasson wrote:
> -) What are the current langages supporting JIT? What are their
> performances?

How about the Java runtime? Sun has already opened up the parts that
we'd actually need. (We have no use for the Java class libraries, and
once you strip those out the runtime binaries are only a couple
megabytes in size.)

> -) What are the langages which are best cross-platform and OS-independent?

Some of the existing Open Source JVMs support more processors than Sun's
OpenJDK; at the same time, Sun's implementation seems to be better
optimized on those platforms that are supported.

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

Penelope20k <pen### [at] caramailfr> wrote:
> > t'es la o boulot ... avec un cle USB?
  Yeah.
    -- Warp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHARZRcCmTzQ++ZncRAipgAJ9fp+WPZOXFYmEJ2eiTRv4zFHsAjQCfTXXi
tcCuvWJh2K84EzHH+SxwWsA=
=jYQu
-----END PGP SIGNATURE-----

Post a reply to this message

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

Jim Henderson wrote:
> Only so far as the features one wants are in the OS that one is using.  
> If you've used any OS other than Windows in the last 10 years, you've 
> come to expect that full functionality may not be available in the OS of 
> your choice.

Yeah. Vista *still* doesn't seem to support sed, or even grep. I don't
know how anyone even gets anything done on Windows. :-D

> Now extend that to features in the language itself - that's a recipe for 
> chaos, because the POVRay you use on *nix may not necessarily have the 
> same functionality as the Windows version, and your scene files won't 
> actually render because of missing functionality.  You end up with an SDL 
> that is *not* portable.  Nonportability is BAD.
...
> That's a bit different than limiting the featureset of POVRay itself for 
> users of some OSes.

I am seeing your point.

In all fairness, there *are* platform-independent uses for this sort of
thing. How about being able to call Python from SDL? You don't want to
just hard-code links to Python in POV...because then the Perl and Ruby
hackers would get mad. ;-)

Anyway, I think we both agree on the fundamental points--cross-plaform
is good, and flexibility is also good. Possibly we're just disagreeing
on how this sort of feature would end up getting used.

In any case, POV bindings to external programs are probably not going to
happen, so this discussion is mostly moot, anyway.

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

You know you've been raytracing too long when you want to cheat and look
at nature's source code.
    -- Mark Stock
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHARn+cCmTzQ++ZncRAnaJAJsHnJ80MGbPORS49u+t/sZj1uni8QCdE7XX
ORqhZ9bBxFYtHCOhXB2I9+M=
=YT2M
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> nemesis wrote:
> > I was thinking... the next Povray supposedly is going to be GPL.  Would you
> > guys find it feasible to ship it together with GCC?  My point is:
> > JIT-compilation is still a relatively new area and there aren't sufficient
> > open-source implementations out there.  But traditional ahead-of-time
> > compilation is easily achieved.  If it was possible for a povray SDL script
> > to be compiled before running, performance wouldn't be a problem any more.
>
> I really can't say how SDL would take to being compiled; I can say that
> GCC is going to be a little bit of overkill for our needs. ;-)
>
> Writing a new GCC frontend for SDL would be a big project in itself.

That's not what I had in mind:  we'd likely ship both GCC (for the backend
compilation) and a front-end language system capable of producing C code
which would in turn get compiled.  Many high level languages today target C
as a lowlevel portable assembly.

I certainly wouldn't like to program SDL in C (nor C++).  My point was to
adapt a particular high-level language to suit the needs of Povray SDL and
program in that subset.  An then, get it compiled to C, which would in turn
get compiled to native code by GCC.  Too much of a trouble?  chicken does it
in a single pass with a high-level script.

> > then, I could even suggest getting a Scheme implementation like chicken to
> > be a possible SDL frontend... :)
>
> If you want to get yourself lynched, sure... ;-)

No need to fear once you get past the parentheses (with proper indentation
and structural editing)...

but then again, perhaps we should stop daydreaming and first help rewrite
all that old C/C++ code...

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bruno Cabasson wrote:
> > -) What are the current langages supporting JIT? What are their
> > performances?
>
> How about the Java runtime? Sun has already opened up the parts that
> we'd actually need. (We have no use for the Java class libraries, and
> once you strip those out the runtime binaries are only a couple
> megabytes in size.)
>
> > -) What are the langages which are best cross-platform and OS-independent?
>
> Some of the existing Open Source JVMs support more processors than Sun's
> OpenJDK; at the same time, Sun's implementation seems to be better
> optimized on those platforms that are supported.
>
> - --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu

Java provides many of what has been evocated (OO, modularity, JIT,
platform/OS comptibility, etc ..). But how could we take advantage of it
without ending with something too heavy?

Java cannot be the choice for the rendering engine for obvious performance
reasons, but it might be a good candidate for the language/syntax aspect,
provided we can define some restrictions and rules. But I absolutely don't
know what and how ... Alladin's lamp welcome! (Might be a good name for
something, no? You just polish, and something magic comes out!)

Java provides JNI, an interface for external libraries, with the concern
that was evocated earlier in the thread, but which might be a 'ready-made'
solution.

OTOH, I cannot imagine we can do something new and entirey specific from
scratch. It represents way too much work and maturation.

We can (have to) reuse POV syntax, augment it with the new features, keep
the POV spirit. We can write an efficient and powerful rendering engine,
whatever language it is written in, the pure technical/math part is never
much of a problem. And we have some skilled and genius people here. My
opinion is that the difficulty resdes in between, between the syntax itself
and the rendering engine.

In conclusion, we have the following chain:

Features -> Syntax -> Parse and make features take form -> Rendering engine

And the related questions:

WHAT features? (not answered yet, first thing to do)
WHAT syntax? (not answered yet, in conjuction with features)
HOW linguistic features are implemented? (here resides the core problem and
main choices, possibly needs loop-back with features for compromise)
HOW the rendring engine is implemented? (only technical, not easy at all but
not really blocking)

People here can write some significant pieces of code to illustrate features
they have in mind with the syntax they envision, or to show what they would
have liked to have at least once in their POVer's life, and blocked them
more or less. Can we open a new group for that purpose? Or use rather the
povray.programming group?


    Bruno

Post a reply to this message

William Tracy escribió:
> In all fairness, there *are* platform-independent uses for this sort of
> thing. How about being able to call Python from SDL? You don't want to
> just hard-code links to Python in POV...because then the Perl and Ruby
> hackers would get mad. ;-)

I honestly don't know either of those three languages. What about PHP? :P

Post a reply to this message

Warp escribió:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> And if the shader language is, in fact, an existing language, like C or Ruby,
>> or any smart choice, making use of POV-Ray-specific classes, efficient
>> compilation shouldn't be a problem (I think).
> 
>   There's a difference between something being inside the core C++ codebase,
> and something JIT-compiled at runtime.
> 
>   Modern C++ compilers are quite good at optimizing, and it would be quite
> hard for the JIT-compiler of any given scripting language to match that
> level of optimization.
> 
>   Even if some JIT-compiler of some scripting language would achieve the
> same speeds, the C++ compiler still has some advantages, such as being
> able to inline certain functions for added speed (which naturally cannot
> be done with JIT-compiled functions because they are unknown at the core
> code compilation stage). Not that this matters a whole lot, but still.
> 

So why not use a modern C++ compiler for JIT? Have a look at this:

http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/patches/jitc-patch/

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> So why not use a modern C++ compiler for JIT? Have a look at this:
>
> http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/patches/jitc-patch/

really cool!  sad it's last version is from 2004.  That's the kind of thing
I have in mind, though I'm not sure it can be appropriately called a JIT...

Post a reply to this message

William Tracy nous apporta ses lumieres en ce 2007/09/30 18:37:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alain wrote:
>> There is a way, it's called "sandboxing". The process runs in a limited,
>> closed, virtual machine and only have access to what YOU want it to see.
> 
> So, you propose that every time POV code loads an external program, you
> launch a full-scale virtual machine? Are we going to license something
> from VMware? Are you going to ask people to buy extra licenses from
> Microsoft for the copies of the operating system running inside the VM?
> (Jeez, I'm starting to sound like Warp.)
> 
> Sandboxing is great for your language's own scripts/bytecode, but is
> less than helpful for _external_ libraries and arbitrary programs, which
> is what we were talking about.
> 
> - --
> William Tracy
You don't need a full-scale virtual machine, only a prety limited one only 
supporting what you need it to support. You don't need to launch several of 
those, you can reuse the same one for several modules. How about one that 
simulate some opensource, limited linux-like environment. In fact, you may not 
even need to have an OS running in that sandbox! A little like running a ROM 
based application on a diskless box. That way, you gain an OS independance, 
whitch allows you to use those external modules regardless of what OS you use.

-- 
Alain
-------------------------------------------------
What happens if you get scared half to death twice?

Post a reply to this message

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

Bruno Cabasson wrote:
> Java provides many of what has been evocated (OO, modularity, JIT,
> platform/OS comptibility, etc ..). But how could we take advantage of it
> without ending with something too heavy?

Remove the Java class libraries. :-) Seriously, the VM itself is not
that bad.

> Java cannot be the choice for the rendering engine for obvious performance
> reasons, but it might be a good candidate for the language/syntax aspect,
> provided we can define some restrictions and rules. But I absolutely don't
> know what and how ... Alladin's lamp welcome! (Might be a good name for
> something, no? You just polish, and something magic comes out!)

I'm not suggesting Java the _language_, I was suggesting the Java _VM_.

That said, now that I've thought about it, Mono might be a better
choice. Much as I dislike using something that has Microsoft's fingers
in it, .Net is much better suited to building other languages on. The
Java VM is fairly tied to the Java language (though that is improving,
these days).

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

You know you've been raytracing too long when your 18 year-old daughter
asks if she can marry one of the POV Team, and you give her your
complete blessing.
    -- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAVhocCmTzQ++ZncRAhAOAJ9bZ5/kDQfiSCg/p7kSaamAeAGhswCdGdK2
J2AEP1Qp2LSFsEiXC3gVOhI=
=9S33
-----END PGP SIGNATURE-----

Post a reply to this message

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

Alain wrote:
> You don't need a full-scale virtual machine, only a prety limited one
> only supporting what you need it to support. You don't need to launch
> several of those, you can reuse the same one for several modules. How
> about one that simulate some opensource, limited linux-like environment.
> In fact, you may not even need to have an OS running in that sandbox! A
> little like running a ROM based application on a diskless box. That way,
> you gain an OS independance, whitch allows you to use those external
> modules regardless of what OS you use.

I think we've been talking past each other here. :-P I'm assuming that
"external libraries" means being able to execute arbitrary, existing
software. I can't think of any good Windows examples (launch Halo, do a
screen capture, and use it as a texture?), but it would be cool to, say,
 automatically run ffmpeg to convert your frames into a move, or run the
Gimp in batch mode to do post-processing (automatic convert to jpeg?).
Maybe control X10 devices from SDL? ;-)

Now that I've read your description, though, I'm intrigued. You're
talking about only running programs written _for_ this POV virtual
machine? In that sense, it would be a sort of heavyweight extension to
the SDL.

You could have your run-of-the-mill SDL code running in an interpreter
heavily optimized for speed, and then have the option of launching this
VM code when you need flexibility more than speed.

That's kind of cool. :-)

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

You know you've been raytracing too long when your electricity bill is
extortionate because you refuse to let any rooms in your house be unlit,
even overnight.
    -- Richard Morton
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAVq8cCmTzQ++ZncRAgAUAKCVIea1K+62Yl4Cevbqd9zIczK0SgCfbbZ7
kY0JEseEoF+C7azbi6s1BSs=
=SXSO
-----END PGP SIGNATURE-----

Post a reply to this message

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

Sorry, now that I've re-read your post...

Bruno Cabasson wrote:
> People here can write some significant pieces of code to illustrate features
> they have in mind with the syntax they envision, or to show what they would
> have liked to have at least once in their POVer's life, and blocked them
> more or less. Can we open a new group for that purpose? Or use rather the
> povray.programming group?

+1 on creating a povray.v4 discussion group. :-)

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

You know you've been raytracing too long when you collapse in the middle
of a sermon in church, mumbling about CSGs, #declares, and finishes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAVuGcCmTzQ++ZncRAlmSAJ9bE18avq9u5Tzfy56Sgp/spCA0kwCfQ6JG
s/kePTx1jvhdO0xhWeCXNB0=
=3jgN
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy escribió:
> but it would be cool to, say,
> automatically run ffmpeg to convert your frames into a move, or run the
> Gimp in batch mode to do post-processing (automatic convert to jpeg?).
> Maybe control X10 devices from SDL? ;-)

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

Post a reply to this message

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message 
news:web.47012662e7dc7428e8ba46670@news.povray.org...
> William Tracy <wtr### [at] calpolyedu> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Bruno Cabasson wrote:
>> > -) What are the current langages supporting JIT? What are their
>> > performances?
>>
>> How about the Java runtime? Sun has already opened up the parts that
>> we'd actually need. (We have no use for the Java class libraries, and
>> once you strip those out the runtime binaries are only a couple
>> megabytes in size.)
>>
>> > -) What are the langages which are best cross-platform and 
>> > OS-independent?
>>
>> Some of the existing Open Source JVMs support more processors than Sun's
>> OpenJDK; at the same time, Sun's implementation seems to be better
>> optimized on those platforms that are supported.
>>
>> - --
>> William Tracy
>> afi### [at] gmailcom -- wtr### [at] calpolyedu
>
> Java provides many of what has been evocated (OO, modularity, JIT,
> platform/OS comptibility, etc ..). But how could we take advantage of it
> without ending with something too heavy?
>
> Java cannot be the choice for the rendering engine for obvious performance
> reasons, but it might be a good candidate for the language/syntax aspect,
> provided we can define some restrictions and rules. But I absolutely don't
> know what and how ... Alladin's lamp welcome! (


    Mr. Gena Obukhov springs to mind here for some reason.


     ~Steve~









>    Bruno
>
>

Post a reply to this message

nemesis wrote:
> That's not what I had in mind:  we'd likely ship both GCC (for the backend
> compilation) and a front-end language system capable of producing C code
> which would in turn get compiled.  Many high level languages today target C
> as a lowlevel portable assembly.

As Thorsten mentioned, check llvm.org.

-- Chris

Post a reply to this message

In article <web.47012662e7dc7428e8ba46670@news.povray.org>, 
bru### [at] alcatelaleniaspacefr says...
> Java provides many of what has been evocated (OO, modularity, JIT,
> platform/OS comptibility, etc ..). But how could we take advantage of it
> without ending with something too heavy?
> 
Umm.. Yuck! For two reasons>

1. The language isn't too friendly when it comes to figuring out what 
the heck its doing. Its almost as bad as C++, if you don't know it. 
Going so far towards that level of language is imho, unnecessary, 
especially if you sacrifice understandability.

2. We are dealing with a "lot" of data types here that are not handled 
when at all by "most" languages. Well, not without some overly 
complicated things to make it work anyway.

I would suggest something like Lua. It has more readability, less syntax 
pickiness, at least as much functionality, once you add "necessary" 
libraries, which most you won't need anyway. 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. From what I understand, it 
only gets worse if you are trying to cram such data across ActiveScript, 
but that issue isn't really relevant. Tables, and the ease of 
integration where *huge* factors in the client's maker deciding in favor 
of Lua, instead of every other option, including Java.

Put simply, if you wanted to make an array/table containing every aspect 
of a named object in POVRay, it would be relatively simple to do that in 
Lua. Doing it in any other language would instead require that you 
create a mess of function calls, to retrieve individual parts of the 
object, and manipulate them. I.e., it naturally produces a result that 
"looks" like:

Now, how you handle changing the content of a table, then having it take 
effect as an object, may be more complicated, but your looking at doing 
this:

table = getobject("myobject")
table.leg.rotate = ...
setobject("mynewobject", table)

Presuming that "setobject" used the data in "table" to generate the 
internal representation of all the data that was copied from the call to 
"getobject". In fact, this is, from what I understand, even how Lua 
links to external libraries. Its creates a table, which contains the 
functional layout of the data types it needs, the Lua function name and 
the reference address for the libraries entry points. When you make a 
call to something in Lua's IO libraries, its actually looking in the 
table for you function, like io.systemdate, then *calling* the external 
function referenced by that name in the table. You don't have to do 
anything but set up the table to point at the right things.

Its not hard to imagine how that type of flexibility in its most basic 
data manipulations could make handling a 3D scene easier to work with.

Mostly though, I just hate Java when it comes to syntax. lol I suppose I 
would have to learn if it was picked.

-- 
void main () {
  If Schrödingers_cat is alive  
    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 <47015269$1@news.povray.org>, ele### [at] netscapenet 
says...
> William Tracy nous apporta ses lumieres en ce 2007/09/30 18:37:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Alain wrote:
> >> There is a way, it's called "sandboxing". The process runs in a limite
d,
> >> closed, virtual machine and only have access to what YOU want it to se
e.
> > 
> > So, you propose that every time POV code loads an external program, you
> > launch a full-scale virtual machine? Are we going to license something
> > from VMware? Are you going to ask people to buy extra licenses from
> > Microsoft for the copies of the operating system running inside the VM?
> > (Jeez, I'm starting to sound like Warp.)
> > 
> > Sandboxing is great for your language's own scripts/bytecode, but is
> > less than helpful for _external_ libraries and arbitrary programs, whic
h
> > is what we were talking about.
> > 
> > - --
> > William Tracy
> You don't need a full-scale virtual machine, only a prety limited one onl
y 
> supporting what you need it to support. You don't need to launch several 
of 
> those, you can reuse the same one for several modules. How about one that
 
> simulate some opensource, limited linux-like environment. In fact, you ma
y not 
> even need to have an OS running in that sandbox! A little like running a 
ROM 
> based application on a diskless box. That way, you gain an OS independanc
e, 
> whitch allows you to use those external modules regardless of what OS you
 use.
> 
> 
Actually, this isn't that horrible an idea. There are full linux-like 
environments that run off something as small as a floppy. You don't even 
need the console or video code, since the only data in/out is going to 
go through the engine and you can do the same thing that DOSBox does, 
and only "mount" specific folders, and subfolders, as valid places to 
run things from.

The only real issue is that this makes it hardly any better than just 
coding it all in the JIT anyway, since anything you wanted to run in it 
would have to be coded/recoded to run in that modified environment. 
Rewriting it as a module for the script language might be easier than 
writing it for the sandbox. And you "can" sandbox some languages too. 
The client application I have does that, defining the "io" and some 
other high risk libraries as "null", so that any attempt to call them 
generates a runtime error.

-- 
void main () {
  If Schrödingers_cat is alive  
    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

Patrick Elliott wrote:

<snip long story about programming language>

In all this talk about this or that programming language I feel that one
question is being side stepped. Does POV really need a new language or can
all this be accomplished with a good spring cleaning of the SDL. Most of
the discussion going on at the moment is far too technically language
specific. Mind you, I know zip about the innards of any language, but I do
know that if and when the current SDL is replaced by something entirely
different you are going to upset a large portion of the POV user group.

And then there is that other discussion going on about what all one would
want inside POV. Do I want it to convert my images to JPG? Heck no. I want
them in a lossless format. Top quality. For the occasional post here I'll
compress it separately. Do I want POV to be able to create animations on
the go? Nope. There are plenty programs out there that will do a much
better job will all the thrills and frills of an editing studio. I
personally use MainActor and I don't see any way one could combine that
into POV. The same goes for any form of post processing. The best one can
do is a very limited form of The Gimp and the likes. 

Don't get me wrong. I'm not saying all these discussions are wrong but lets
not forget that POV needs 3 things most. Speed, more speed and some speed.
In my view POV is a (restructured) SDL and parser with a lean and mean
render engine behind it. 
-- 
Ger

Post a reply to this message

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.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

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 speed.

  The new language doesn't have to look very different from the current SDL,
but some changes are necessary (for example related to macros).

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott escribió:
> 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).

Post a reply to this message

Ger wrote:
> 
> In all this talk about this or that programming language I
> feel that one question is being side stepped. Does POV really
> need a new language or can all this be accomplished with a
> good spring cleaning of the SDL.

What POV does NOW could be accomplished with a good spring cleaning, and 
I agree with you that much of what others want to do can be accomplished 
more easily with outside tools. I do not care for the idea of renderer 
+second-rate image processor +second-rate text converter +second-rate 
animation studio +second-rate... +++.

However, outside programs cannot be used to build shaders. I believe 
development should be focused in that area. I can't see how objects 
would be necessary to program shaders, but someone else might. There is 
a clear need for object-like stuff like MyObject.rad.

  -Shay

Post a reply to this message

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.

  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.

-- 
                                                          - Warp

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.

I fully agree that rendering features should be integrated into the POV
render engine. But things like JPG conversion and creating animations have
no business there. It's simply not possible to create a program that "does
it all"

> 
>   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.
> 

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.

-- 
Ger

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.

-- 
                                                          - Warp

Post a reply to this message

Today, nothing prevents all the stuff we produce to be orginized more or
less like a mess. I guess it actually is for some of us, and I guarantee
you it is the case for me. The #include approach is too limited and
prevents from modularity, visibility, naming range, etc ..., and the
reusability is somewhat limited and puzzling. A well known and mature
solution for these features is Object Orientedness. Let's make POV4 be
object-oriented. Not too much, but enough to benefit of what can be good
for our purpose.

If we want (still more or less):
    - OO
    - inheritance (prevents useless re-writing of common properties)
    - modularity
    - reusability
    - visibility rules
    - locatability
    - avoid code duplication

And considering that Java was mentionned in the discussion thread as
providing such features, and considering that Java is also a very popular
language, let's try to make POV4 be inspired by Java for these aspects.
Thus, we can talk about 'packages', 'classes', and 'inheritance'. The
following lines can express that we are definig a new 'module' in our
'organisation'.


// Let's make the relationship stuff-we-write/location be bijective,
// and therefore force a minimal organisation: we express how we are
// organised, and where we locate this module in the organisation.
// Like Java, we can say that this code is in the file
// <some root directory>/household/furniture/Stool.pov4
package household.furniture;

// Reuse already defined stuff (can be/is already compiled)
import hormann.IsoWood3;
import pov.math.vector.*;
import pov.Metals;
import decoration.Velvet;
import tools.NiceStuff;

// We define a type of object 'Stool' that inherits main behaviour from
// 'FourLegged' (defined in the same package).
class Stool extends FourLegged
{
    [CLASS_BODY]
}

It is quite direct from Java, but it is not much of a problem at this level:
Java's OK for that according to me. Only this can satisfy the main
structural concerns, whatever we put in the [CLASS_BODY]. And the code is
as compact as POV.

The use of a Stool in a scene could be like:

package scenes.rooms;

// Only a scene is renderable. The name 'RoomByNight' can be used as the
// default name for the output image.
scene RoomByNight
{
    global_settings {...}
    light_source {...}

    // The stool. POV-like syntax, as if it were a primitive object. Can be
    // considered as a POV-like notational shortcut for a constructor.
    Stool
    {
        [stool properties]
    }
}

Until now, POV is C-like syntax and is limited. Why not Java-like
features/syntax for some aspects? For the rest of the language and
features, we can see later what syntax is most appropriate.

My idea here is to find an agreement on this main structural aspect. These
lines are just an example, an effective start point to help thinking. There
are surely pros and contras.

Comments welcome.

Post a reply to this message

Warp 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. I'm not
saying it can't be done but, to me, it would be a tremendous waste of
programmer time. And if you extend this towards the SDL/parser you would
also need to add Wings/Blender/Poseray etc to the frontend.
-- 
Ger

Post a reply to this message

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.

  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.

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

-- 
                                                          - Warp

Post a reply to this message

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

Warp a écrit :
> 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

Warp a écrit :

>   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:
> Warp a écrit :

> >   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 () {
  If Schrödingers_cat is alive  
    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 () {
  If Schrödingers_cat is alive  
    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...
> Patrick Elliott escribió:
> > 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 () {
  If Schrödingers_cat is alive  
    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

Patrick Elliott escribió:
> 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

Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> Warp a écrit :
> 
>>>   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.

Let's say I have a scene that takes 3 hours to render. It shows an 
orange, an apple and a banana, on a table.

I use post-processing to apply heavy focal blur (no oversampling
with the camera, it would take too long). Initially, the focal
point is the orange.  But then, I want it to be the banana.

How, in the system you envision, will I be able to change the
focal point and get a new image within a few seconds, instead
of taking 3 hours to re-render everything ?

Fabien.

Post a reply to this message

Morpheus is fighting William Tracy!
>
[...]
> In all fairness, there *are* platform-independent uses for this sort of
> thing. How about being able to call Python from SDL? You don't want to
> just hard-code links to Python in POV...because then the Perl and Ruby
> hackers would get mad. ;-)
>
There's no need to fight : < http://www.parrotcode.org/ >
;)

> William Tracy

Slawek
-- 
  ________ 
_/ __/ __/ Kopernik ruszyl ziemie i dlatego zobaczyl, ze jest okragla
 \__ \__ \_______________________________________________________________
 /___/___/ S�awomir Szczyrba                          steev/AT/hot\dot\pl

Post a reply to this message

> How, in the system you envision, will I be able to change the
> focal point and get a new image within a few seconds, instead
> of taking 3 hours to re-render everything ?

We could expose images as assignable objects during
the post_process stage, which would allow layering and
other tricks that now are done with other software. And
we could expose the depth of the rays to make certain
filtering options much more accurate. Syntax might be
something like...

pre_process {...}
// scene
post_process {
   #declare A = output_image;
   #declare B = file_image "file";
   #declare A = blurByDepth(A,focus_point,depth_of_field);
   #declare C = layerImages(A,B);
   final_image {
      use_image C
      type PNG
      image_name "newfile.png"
   }
}

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Warp a écrit :
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >> Warp a écrit :
> >
> >>>   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.
>
> Let's say I have a scene that takes 3 hours to render. It shows an
> orange, an apple and a banana, on a table.
>
> I use post-processing to apply heavy focal blur (no oversampling
> with the camera, it would take too long). Initially, the focal
> point is the orange.  But then, I want it to be the banana.
>
> How, in the system you envision, will I be able to change the
> focal point and get a new image within a few seconds, instead
> of taking 3 hours to re-render everything ?
>
> Fabien.

Is it still ray-tracing? You only get an image that is based on a ray-traced
one. But if you end up with what you want, then OK.

My opinion is that ray-tracing is a technique that allows to apply physical
laws in order to match reality. I prefer 'match' than 'fake': POV's focal
blur matches a physical phenomenon, post-processing 'only' fakes. But in
many cases one may get satisfied. That's an essential point.

Bruno

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:

> As you might have noticed, not everybody is convinced we should have one.

Right.

But the concern is so present that the question of a new SDL is 'on air'
since quite a while, made this discussion happen, and interests a lot of
people (I think). And I bet that those people you mentionned, once/if ever
POV has its new nice syntax with new long-awaited features, will be the
first to use it with greed ... The demand for new POV-SDL araised from the
lacks and drawbacks of POV, even if it is a marvelous tool.

Bruno

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> How, in the system you envision, will I be able to change the
> focal point and get a new image within a few seconds, instead
> of taking 3 hours to re-render everything ?

  Regardless of which method is used it's clear that povray must keep
all the necessary information in files (or at the very least in memory)
between renders.

  There could be a few possibilities:

1) An option to tell POV-Ray to write all the necessary information on files.
   Then if you want to re-post-process, you just use the option +C to skip
   the rendering.
   One disadvantage of this is that you have to remember to use the option
   if you want to be able to post-process multiple times.

2) POV-Ray could always write the extra info on files, allowing
   post-processing whenever you want.
   The disadvantage is that it will consume disk space and the user would
   have to manually delete those unneeded files to clean it up.

3) POV-Ray could automatically write the info on files and keep them there
   as long a it's running, and when it's closed, it removes them (unless
   an option is given). This would allow re-post-processing the image as
   many times as necessary as long as POV-Ray is running.
   The disadvantage is that this idea doesn't work with the command-line
   version. Another slight disadvantage is that if the execution of the
   program is ended abruptly, the files will be left there.

4) As 3, but the info is kept in memory until next render.
   Doesn't garbage the disk, but has the same disadvantages.

  Make your pick, or suggest something better.

-- 
                                                          - Warp

Post a reply to this message