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.

>> POV-Ray's biggest problem is weak animation support. It is useful mainly
>> for still pictures.

>   And POV-Ray supporting a hamster AI helps this how?

If you like to model grass do you set every 100000 blade to scene or do you
make macro for that? If you want to animate hamsters you don't want to tell
every hamster movement on every frame on every scene where you like to use
hamster object now and later.

With collision detection and physics you can also throw hamster with bowling
ball and kill it. Or stupid hamster can walk over table and die if the drop
is enough high.

Of course this kind of stuff is also useful when modelling water particle
behavior and so on.

Matti

Post a reply to this message

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();
}

Post a reply to this message

Thanks Peter, ABX, Matti et all.. I'm actually using Python to do the AI
work and output a pov scene file respectively. I'll probably make the
Python script available for download when I finish.

http://www.frams.alife.pl/ <-- very cool!

Peter Duthie <pd_### [at] warlordsofbeercom> wrote:
> POV-Ray SDL isn't really a good scripting language for this sort of
> task.  It's quite a good Scene Description Language, but I've found it
> more effective to perform behavioral/physics simulations in Python using
> modules such as the Open Dynamics Engine, and have the Python script
> print out POV-Ray SDL to a file for rendering.
>
> Ideally there would be some sort of standard API into POV-Ray (C,
> Python, anything) so that it could be accessed natively in other
> languages but I imagine that this isn't a trivial task in it's present
> state, or it would have already been done.
>
> Peter
>
> Matti Karnaattu wrote:
> > If you like to animate a hamster, you can put your hamster object to scene
> > and start shooting it with virtual camera without telling hamster object
> > what to do on every frame.
> >
> > Or how about putting some AI people to walking in city object?
> >
> > I really hope that some day POV-Ray have object oriented SDL and collision
> > detection with physics... This kind of stuff is very useful to make
> > animations.
> >
> > Matti
> >
> >

Post a reply to this message

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