Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Rather than have an entire CLR, you could have the program structured to 
>> have C libraries (or C++ classes, I suppose), and clearly document how 
>> they're used. Then the SDL parser would invoke constructors building the 
>> classes, then invoke the "render" method.
> 
>   That would mean that 1% of the povray community could benefit from that,

The point of doing it that way would primarily be to allow those writing 
the SDL to use one of the many languages that already exist to avoid 
having to reimplement anything in the SDL except the ray-tracing. Need 
formatted input/output? Need to read CSV files? Want to store objects or 
libraries in a database, or in google-file-system? Want to send a 
message over a socket each time a frame finishes? If you use an existing 
language that can interface to C, like Java, Tcl, Python, Lisp, etc etc 
etc, you get all that sort of stuff "for free". Of course, munging your 
SDL syntax to match the language you pick can be a bit problematic, but 
it's not *that* hard to solve, especially if you pick an appropriate 
"base" langauge.

Hope that clarifies.

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

Bryan Valencia wrote:
> If there was a suite of POV components that plugged into Visual Studio 
> Express (the FREE version), we could let Microsoft's strong languages 
> enhance POV's incredible rendering engine.
> 
You are forgetting (or ignoring) that VS is Windows only.  POV-Ray is 
*NOT* limited to Windows only.

      -=- Larry -=-

Post a reply to this message

In article <web.47055ba7bcc3cc02773c9a3e0@news.povray.org>, 
nam### [at] gmailcom says...
> Warp <war### [at] tagpovrayorg> wrote:
> >   A precompiled library alone is useless in C/C++. You need the non-com
piled
> > public interface to use the library.
> 
> That's a problem with C/C++ and their reliance on header files for functi
on
> prototypes AFAIK.  Besides, even then, with documentation about functions
> written in other languages, even in a C/C++ enviroment you can call these
:
> just write the proper header files by prototyping the functions as
> documented.
> 
> Say you write a class in JRuby and bytecompile it.  You can use that clas
s
> from a regular Java problem without worries.
> 
> > It must
> > be usable from POV-Ray directly, using its native scripting language.
> > How are you going to use it without an interface?
> 
> I agree povray *must* have its own scripting language.  And if it's JITte
d,
> only the better.  I was just pointing out that it is possible to interfac
e
> with compiled code given a common binary format, documentation and suppor
t
> from the infrastructure (compilers, linkers, runtime).
> 
Hmm. If I get what you are saying, then I may agree with you. Make the 
POVRay system into a library, which is of a type capable of easily being 
integrated into any other language, while "still" keeping an internal 
language for the scene. In other words, make similar to what it would be 
if you wanted to use IE using COM:

a = createobject("explorer.application")
if typename(a) = "explorer" then
  a.load("c:\Mydocs\fred.html")
end if

The language you use to tie the engine into shouldn't care what the 
engine was written in, as long as the library is one that can be easily 
linked/instanced/whatever. For the current version this is pointless, 
since there are issues with having to have it announce its copyrights, 
etc. (which I suggested one possible solution to, at least under 
windows), but 4.0 is supposed to be a lot nicer about that sort of 
thing, allowing it to be more closely integrated.

This however says *nothing* about what the SDL itself should be doing, 
nor about how anything, beyond the functions/events supported in that 
interface, allow for integration of plugins or any other elements that 
are "specific" to the engine, and thus "not" part of the application its 
been embedded into.

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

On Thu, 04 Oct 2007 15:57:22 -0700, Bryan Valencia wrote:

> If there was a suite of POV components that plugged into Visual Studio
> Express (the FREE version), we could let Microsoft's strong languages
> enhance POV's incredible rendering engine.

Let me say this again:  This is great if you use windows, but NOT 
EVERYONE USES WINDOWS!!!!!

(Sorry, I just get tired of repeating myself here)

Jim

Post a reply to this message

On Thu, 04 Oct 2007 14:58:54 -0300, Nicolas Alvarez wrote:

> They would have to pay me to get me to install VisualStudio.

They couldn't pay me enough, and I have an MSDN subscription for work.

Jim

Post a reply to this message

> Warp wrote:
>> Bryan Valencia <no### [at] waycom> wrote:
>>> The Rendering engine should accept only strictly formatted bytecode.
>>
>>   Btw, this is a bad idea. It ties the hands of the developers.
>> It would make it impossible to change and improve the format of the
>> bytecode without breaking existing libraries.
>>
>>   It would work if the bytecode format could be PERFECTLY designed on
>> the very first try, and then fixed and engraved in stone. However,
>> developers are imperfect humans, so it's not gonna happen.
>>
> thats just wrong.  thats like saying that Microsoft can never improve 
> Word because Word for DOS version 1 doesn't have that.

Word has been improved since version 1 ?

Fabien.

Post a reply to this message

> 
> Word has been improved since version 1 ?
> 
> Fabien.

I don't know if it has been improved, but a few broken features were 
fixed, and new broken features were introduced. Percentage of brokenness 
is around the same, though.

Post a reply to this message

Warp  wrote in message <47054da9@news.povray.org>:
>   Changing radically the scripting language is not going to be well received.

I think you miss a point: if POV-Ray's rendering features are available as
library functions call from some languages or, even better, from several
languages, you can then write in that language whatever parser you want.

Let us say, for the sake of the argument, that these features are accessible
as a Caml module. Then you can write a parser for the SDL, the very current
SDL, in Caml. Maintaining a separate parser like that would be easier than
maintaining a parser built in the core system, provided the language is good
for parsers (and Caml is good for parsers).

Now, a basic user of POV-Ray can write his scene in plain old SDL, the
front-end will automatically call the Caml parser, and the user does not see
any change.

On the other hand, an user that want to do complex programmatic features in
his scene can write them in Caml, and plug the result in his scene.

Post a reply to this message

Nicolas George  wrote in message <4707448b$1@news.povray.org>:
> I think you miss a point: if POV-Ray's rendering features are available as
> library functions call from some languages or, even better, from several
> languages, you can then write in that language whatever parser you want.

Just to have things clear, here is the outline of a plan for this solution.

1. Make the rendering features of POV-Ray into a clean c++ library. That
   gives us libpov4.so and pov4.hh.

2. Chose a language that you like and that makes writing parsers and
   interpreters easy. Let us say, just to avoid writing "that language"
   everywhere, that this is Caml -- if you prefer INTERCAL, replace
   everywhere.

3. Write a wrapper library to use libpov4.so from Caml.

4. Write a clean parser and interpreter for the current SDL in Caml.

5. Chose a language that you like and that can easily be fully embedded.
   Again, just to have a name, let us say this is Lua.

6. Write a wrapper library to use libpov4 from Lua.

7. Extend the parser-interpreter to allow loading new features from a shared
   object and calling them.

8. Build a front-end, linked with libpov4.so, including 3, 4, 6, and 7 (and
   making sure that 7 is directly aware of 6).

Now, let us consider the result:

- Current basic users of POV-Ray just call the resulting binary (8) with
  their unchanged scenes. The scene is parsed and interpreted by 4 and
  rendered by 1.

- Developers of POV-Ray can slowly extend the parser-interpreter to make the
  SDL a little bit less clumsy (with "for" loops for example).

- Medium-level users of POV-Ray can learn Lua, and include Lua code from
  their SDL scenes.

- Advanced users of POV-Ray can add brand new features as c++ objects.

- Other advances users can write wrappers around libpov4.so for other
  languages, and write their scenes with their favorite language. Wrappers
  that are good code can be included in the official POV-Ray distribution.

In the long run, I have the hope that someone could write, for example, a
robot in Scheme, some other person could write a space shuttle in Perl, a
third may write a solar system (with accurate orbits) in Fortran, and a
basic user could just use these scene parts from his SDL scene:

#declare Robot = friendly_robot {
  left_shoulder 90
  right_shoulder 20
  ...
}
#declare Planets = solar_system { 2007, 10, 06, 09, 56, 00 }
...

(Well, actually, I do not hope exactly that, since I hope that Fortran would
be really dead by then.)

Post a reply to this message

Btw, how do you envision the basic user being able to write shaders in
this system? Note that the basic user wants to use the current SDL, only
enhanced with shaders.

-- 
                                                          - Warp

Post a reply to this message