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

Warp  wrote in message <47076431@news.povray.org>:
>   Btw, how do you envision the basic user being able to write shaders in
> this system?

Actually, I do not know exactly what a shader is. Would a basic user be able
to write one, in any system?

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> Warp  wrote in message <47076431@news.povray.org>:
> >   Btw, how do you envision the basic user being able to write shaders in
> > this system?
>
> Actually, I do not know exactly what a shader is.

A user-definable function that accepts some information about a scene,
object, surface or ray and returns information that the renderer then uses
to modify the shading, illumination, any other aspect of the rendered
image.

I suspect though  that the shading language under consideration is solely to
replace only what other packages would call surface shaders: these shaders
accept information about a ray and the object it intersects, and return a
final surface colour using some internal process. POV's support for this is
quite focussed on colour, rather than surface properties; almost that you
can have any BDRF so long as it's Lambert.

> Would a basic user be able to write one, in any system?

Yes. Although the actual shader language is usually quite low-level (often
C-like), and therefore not particularly artist-friendly, most applications
provide a specialised visual editor. These days they are usually based on
nodes (plug a texture node into a diffuse shading node to get a texture
mapped diffuse surface, for example). Some systems opt to use layers, but
it ends up being the same. The systems are very powerful indeed, much more
powerful than my textured diffuse example.

I guess the plan in POV is not to ship any such visual support by default,
and make the underlying shader language artist-friendly enough to use. As
far as I know this will be a unique achievement, both in terms of
originality and, as always, difficulty.

Some further reading:

http://www.janwalter.com/
(the shader writing bits show how a few other packages handle this in their
C-like shading language)

http://www.xsi-blog.com/archives/118
(clever use of the visual shading language to speed up ambient occlusion in
XSI/mental ray)


Tom

Post a reply to this message