Matti Karnaattu <nomail@nomail> wrote:
> If you like to model grass do you set every 100000 blade to scene or do you
> make macro for that?

  So what you want is a powerful scripting language in general, not
"AI support" in particular.

  Thus my original statement holds: "AI" is not a task for the raytracer.

-- 
                                                          - Warp

Post a reply to this message

> > If you like to model grass do you set every 100000 blade to scene or
> > do you make macro for that?
> 
>   So what you want is a powerful scripting language in general, not
> "AI support" in particular.
I think the OP made that quite clear.

-- 
I went to the CO guess what he told me guess what he told me | apologies
He said  boy u better learn to like Win  no matter what u do | to Prince
But  he's  a  fool,  'cos  nothing  compares,  nothing  compares  2  GNU
^^ http://surreal.istic.org/songs/?file=Nothing%20Compares%202%20GNU.txt

Post a reply to this message

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. I would
hate to think I would hate to have to drop POV_RAY just because the
POV_TEAM decides I am using it wrong. :)

IMOP: Any good program becomes great by growing with its users. Just think
how far POV_RAY has come.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Matti Karnaattu <nomail@nomail> wrote:
> > If you like to model grass do you set every 100000 blade to scene or do you
> > make macro for that?
>
>   So what you want is a powerful scripting language in general, not
> "AI support" in particular.
>
>   Thus my original statement holds: "AI" is not a task for the raytracer.
>
> --
>                                                           - Warp

Thats what I would like to see! POV_SDL is better than RIB or XML or any
other I have worked with but for where it is headed it is not there yet.
The others just hold the data for a scene. POV_SDL is programming the
scene. I like that.

Post a reply to this message

Mike wrote:
> Does anyone know of a good website or resources/artists/individuals who have
> explored AI in conjunction w/povray? I'm wondering if its possible to
> create an animation using a traditional A* algorithm in povray?
> 
> Any information is GREATLY appreciated :-)
> 
> -mike
> 
> 
I am more concerned with simulations, and trajectory calculations in particular. 
  Testing for impact with a height field defined by an image is very slow in 
POV-Ray, and I don't know how to mimic the trace function in a compiled language 
(yet).

This is useful even for stills, calculating the positions of launched particles. 
  Better yet, you could create splines that map time to position and use them 
for animation purposes.

This just might be the ultimate answer to the AI problem, too.  Write an A* 
program in another language, store the resulting paths in splines for each 
object, then have your animation pluck positions from the splines for the 
animations.

--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

Post a reply to this message

m1j <mik### [at] hotmailcom> wrote:
> Thats what I would like to see! POV_SDL is better than RIB or XML or any
> other I have worked with but for where it is headed it is not there yet.
> The others just hold the data for a scene. POV_SDL is programming the
> scene. I like that.

  As I have always said, "one of the strongest features of POV-Ray is also
one of its weakest features", referring to its SDL.

  The idea of a more powerful SDL (both in expressive power and raw speed)
has been one of the motivations for POV-Ray 4, but that will probably happen
only in the distant future.
  Of course some people will be strongly against a new (albeit similar)
language, but that's only to be expected (some people think that "includes
OO features" means the same thing as "you must learn OOP in order to use
the program").

  And no, please don't start posting suggestions for pov4. They are
completely irrelevant at this point and the team already has their
hands full of work with 3.7. It's just an idea.

-- 
                                                          - Warp

Post a reply to this message

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

"Mike" <inf### [at] mydisorg> wrote:
> Does anyone know of a good website or resources/artists/individuals who have
> explored AI in conjunction w/povray? I'm wondering if its possible to
> create an animation using a traditional A* algorithm in povray?

http://basso.inf.br/phi/

Not quite what you want, but a good starting point.

Cheers,

Daniel

Post a reply to this message

hi David, this is exactly what I'm doing; using Python to generate splines
for each A* path. It would be nice if I could do it all through Povray
using SDL. Still think Python is best though as I'm also generating a
csound score file with each A*.

Thanks for your reply!

-m

David Wallace <dar### [at] earthlinknet> wrote:
> Mike wrote:
> > Does anyone know of a good website or resources/artists/individuals who have
> > explored AI in conjunction w/povray? I'm wondering if its possible to
> > create an animation using a traditional A* algorithm in povray?
> >
> > Any information is GREATLY appreciated :-)
> >
> > -mike
> >
> >
> I am more concerned with simulations, and trajectory calculations in particular.
>   Testing for impact with a height field defined by an image is very slow in
> POV-Ray, and I don't know how to mimic the trace function in a compiled language
> (yet).
>
> This is useful even for stills, calculating the positions of launched particles.
>   Better yet, you could create splines that map time to position and use them
> for animation purposes.
>
> This just might be the ultimate answer to the AI problem, too.  Write an A*
> program in another language, store the resulting paths in splines for each
> object, then have your animation pluck positions from the splines for the
> animations.
>
> --------------
> David Wallace
> TenArbor Consulting
> "Just In Time Cash"
> www.tenarbor.com
> 1-866-572-CASH

Post a reply to this message

If you want to do it completely in the SDL, it's possible to read/write
files; if you use a file to store the state of whatever needs the AI (eg.
the location, orientation, and mental state of a hamster) between frames,
then it should just be necessary to read in the file (or set it up on the
first frame), process whatever you need to to calculate the next state,
save the new data, then use the calculated values for that frame.

Post a reply to this message