POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
16 Jul 2025 08:54:21 EDT (-0400)
  Re: New SDL for POVRay  
From: Patrick Elliott
Date: 2 Oct 2007 00:39:16
Message: <MPG.216b793a2214691598a031@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.