POV-Ray : Newsgroups : povray.advanced-users : AI for Povray? : Re: AI for Povray? Server Time
28 Jul 2024 18:27:34 EDT (-0400)
  Re: AI for Povray?  
From: Patrick Elliott
Date: 9 Jan 2006 16:07:38
Message: <MPG.1e2c7e5391e38ae4989ec7@news.povray.org>
In article <web.43c27a93d1a8490fed196ef10@news.povray.org>, 
mik### [at] hotmailcom says...
> Patrick Elliott <sha### [at] hotmailcom> wrote:
> > In article <web.43c02225d1a8490fe4dd611c0@news.povray.org>, nomail@nomail
> > says...
> > > Warp <war### [at] tagpovrayorg> wrote:
> > > >   You lost me with the "XML" part. I couldn't follow your logic.
> > >
> > > Is POV-Ray rendering engine or is it script based rendering software?
> > > Rendering engine should input data from other tools and XML is easy to
> > > parse and generate. There is no use for editor in rendering engine. That
> > > should be different program.
> > >
> > We have been through this before. XML may be easy to generate or parse,
> > but its a) inefficient compared to the existing SDL, which means parsing
> > would take longer, and b) in many cases SDL uses macros and loops to
> > generate multiple objects, trace surface and perform other complex tasks
> > that are supported by "languages", not "documents". XML is a "document"
> > format, not a script language. The only instance I know of where XML is
> > even used for scripts involves using the XML to define secondary things,
> > then placing the real language portion in a CDATA block. In other words,
> > even the people that developed XML realized the difference between
> > documents and imbedded script, which can't be converted to XML.
> >
> > So, you have lost me with that too. I am not sure what everyone's
> > fascination with XML is, but it smacks of the old hammer and nail
> > fallacy, which says, "To someone that does nothing but use a hammer to
> > pound nails, everything starts to look like a nail."
> >
> > --
> > void main () {

> >     call functional_code()
> >   else
> >     call crash_windows();
> > }
> 
> It seems clear to me that he is stating that if POV_ray is going to employ a
> scripting based SDL then it should be robust enough to do AI. POV_SDL is
> only about half way towards perfection. And as we all know nothing ever
> reaches perfection.
> 
> I also got out of his statements that if the SDL is only to be used in a
> limited way then some other structure would be just as good. His stating of
> XML seemed to be just an example of a structure. I was also able to
> conclude he would not want to use XML because of its weaknesses.
> 
> A solution might be to create a POV_ray lib that could be included into

> the SDL. Perhaps POV_RAY is not even the system to use for this.
> 
Well, another possible alternative might be what the telnet client 
Mushclient does, at least for the windows editor, which was to integrate 
support for multiple script languages. Though some of them have 
completely flaky interfaced, like activePHP, which doesn't work at all, 
or ActiveLua, which breaks conventions for return codes and uses 0 as the 
index for the first function, instead of 1, like 99% of the others... Not 
sure how such integration works in Linux, but having a way to bind an 
existing script system to the SDL, without directly changing the SDL is 
at least a possibility. Though it might be more complex than just 
improving the SDL's language features.

In any case, if this happens it will be an unofficial version, where 
*someone else* does it, or appear in 4.0, which they are not even going 
to discuss yet.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

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