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 () {

    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 () {

    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

> 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