POV-Ray : Newsgroups : povray.pov4.discussion.general : A dream about POV4 Server Time: 18 Jun 2019 04:36:57 GMT
  A dream about POV4 (Message 1 to 10 of 15)  
Goto Latest 10 Messages Next 5 Messages >>>
From: Jaap Frank
Subject: A dream about POV4
Date: 13 Apr 2009 17:03:14
Message: <49e37052@news.povray.org>
Hello to all,

I've read the news posts about a new pov-language, but I'm afraid that we 
forget that there are people who DON'T know how to program and who DON't 
like complicated math. Every time I show povray to someone interested, they 
flee away for this complicated stuff to get a picture. There are times that 
I dream about something easy and fast to script.

So, lets dream:

I want to put a new scripting layer above the existing one. Maybe above an 
upgraded SDL3.7, so we can keep backwards compatibility.

The scene I want to make is a long street with moving cars with a crossroad 
with traffic lights. If everything is there I want to animate this with the 
moving cars.

First we need a camera, so at a new menu with objects I choose a good one 
for my purpose: $$NormalCamera.
What I get is this:

$$NormalCamera

No scripting language but only the reference to it. In a special map there 
are small .inc-files with the SDL for all entries of that new menu.
If pov parses the file it gets its SDL from there. In fact this is calling 
an include-file that describes the object NormalCamera. This camera is made 
with the scripting language and is inserted into the scene before parsing 
it. There is a system to insert or delete items on this menu (Right clicking 
on the choice?) Lets dream on ...
Because the camera position and look_at are not correct for this scene I 
change it into (dimensions are in meters):

$$NormalCamera{
    look_at  $$DodgeCar
    position  $$DodgeCar + <0, 4, -20>
}

I make the camera look at the $$DodgeCar (from the menu too) and position 
the camera behind the car so we move along with the car during the 
animation. What we need are new properties for objects: transport and 
centre_of_mass. Centre_of_mass we need for the position of our object. In 
transport you can put the movement of the object. For instance with a 
spline. The spline returns the centre_of_mass for a particular time.
(What I'm thinking about is an autonomous transport system. For instance: 
follow the car before you and keep a save distance or move at a 50 km/h 
speed, but stops before a traffic light if it's red and so on. Very 
complicated, but maybe it's possible.)

The next thing is light. In my famous menu I choose $$HotSun. HotSun is a 
summer sun at midday. So we have:

$$NormalCamera{           //    it's a camera
    look_at  $$DodgeCar
    position  $$DodgeCar + <0, 4, -20>
}

$$HotSun                         //    it's an array light

Next I choose a crossroad and connecting roads and fit it to my needs :
//  a macro composing the crossroad
$$CrossRoad{
    position <4, 1, 75>
    road_width 5
    pavement{ $$Asphalt }
    pedestrians on
}
//  a macro composing the roads
$$Road{
    position <4, 1, 75>
    length 250
    width 5
    pavement{ $$Asphalt }
    sidewalk on
    rotate -180*y
    translate  -253.5*z
}
$$Road{
    position <4, 1, 75>
    length 250
    width 5
    pavement{ $$Asphalt }
    sidewalk on
    rotate -90*y
    translate  253.5*x
}
$$Road{
    position <4, 1, 75>
    length 250
    width 5
    pavement{ $$Asphalt }
    sidewalk on
    rotate 0*y
    translate  253.5*z
}
$$Road{
    position <4, 1, 75>
    length 250
    width 5
    pavement{ $$Asphalt }
    sidewalk on
    rotate 90*y
    translate  -253.5*x
}
Maybe the extra depth to pass $$Asphalt to the macro is too difficult, but I 
hope it's somehow possible.

I follow with choosing cars from my magic menu (the Dodge, a FordCar, etc.), 
traffic signs and lights and so on ..........

I hope that my line of thoughts are getting through. By exchanging the menu 
items with each other, one can build a library to choose from. I know I make 
it look easy and there are, with no doubt, difficulties to implement this, 
but it could be a start for a new approach.

Have a nice Easter,

Jaap Frank


Post a reply to this message

From: Warp
Subject: Re: A dream about POV4
Date: 13 Apr 2009 18:05:48
Message: <49e37efb@news.povray.org>
Jaap Frank <jjf### [at] casemanl> wrote:
> I've read the news posts about a new pov-language, but I'm afraid that we 
> forget that there are people who DON'T know how to program and who DON't 
> like complicated math. Every time I show povray to someone interested, they 
> flee away for this complicated stuff to get a picture.

  No scripting language can help that problem. Those people want a graphical
modeller (regardless of how much more difficult the modeller might be to
use than the scripting language, at least in many cases).

-- 
                                                          - Warp


Post a reply to this message

From: clipka
Subject: Re: A dream about POV4
Date: 13 Apr 2009 19:05:00
Message: <web.49e38c12840aad1a2dae03a10@news.povray.org>
"Jaap Frank" <jjf### [at] casemanl> wrote:

> Next I choose a crossroad and connecting roads and fit it to my needs :
> //  a macro composing the crossroad
> $$CrossRoad{
>     position <4, 1, 75>
>     road_width 5
>     pavement{ $$Asphalt }
>     pedestrians on
> }

Actually I'm busy about a language proposal that *could* support this type of
stuff; the syntax would be slightly different, but it would make it possible to
write "macros" with arbitrary properties to manipulate with just the same syntax
as the basic primitives provided by POV-Ray. I guess I know already how I want
it to look, and it seems to work out regarding the formalisms it is based on.

One thing it would do differently, for instance, would be the pavement thing: It
would either have:

    pavement: $$Asphalt;

or simply:

    $$Asphalt;


> //  a macro composing the roads
> $$Road{
>     position <4, 1, 75>
>     length 250
>     width 5
>     pavement{ $$Asphalt }
>     sidewalk on
>     rotate -180*y
>     translate  -253.5*z
> }

As a side note, I think a "rotate" statement in a new POV SDL should *not*
follow that nasty "rotate about x then about y then about z" approach, but
instead allow for rotations about arbitrary axes. If someone still wants to do
a step-by-step multiple rotation, they can do so by following-up multiple
"rotate" statements (or maybe the rotate statement could get an arbitrarily
long list of parameters).


Post a reply to this message

From: Warp
Subject: Re: A dream about POV4
Date: 13 Apr 2009 19:47:01
Message: <49e396b5@news.povray.org>
clipka <nomail@nomail> wrote:
> As a side note, I think a "rotate" statement in a new POV SDL should *not*
> follow that nasty "rotate about x then about y then about z" approach, but
> instead allow for rotations about arbitrary axes.

  1) Having to always specify the axis of rotation can be tedious.

  2) It's not like you can't do that with the current SDL and a helpful
macro from the official library.

-- 
                                                          - Warp


Post a reply to this message

From: clipka
Subject: Re: A dream about POV4
Date: 13 Apr 2009 20:05:00
Message: <web.49e39add840aad1a2dae03a10@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:
>   1) Having to always specify the axis of rotation can be tedious.

When was the last time you needed rotation about multiple axes and they happened
to be x, y and/or z, in that very order?

If it's just a single axis, I find "rotate y*30" much easier to type than
"rotate <0,30,0>" - that is what *I* find tedious. (And besides, I also find it
easier to read and understand at once).


>   2) It's not like you can't do that with the current SDL and a helpful
> macro from the official library.

I think it's such a basic operation that it should be higher integrated.

(Well, with that language I have in mind it wouldn't make a syntactical
difference whether it's a "macro" or a built-in thing... aside from requiring
the proper files to be included)


Post a reply to this message

From: Zeger Knaepen
Subject: Re: A dream about POV4
Date: 13 Apr 2009 22:29:00
Message: <49e3bcac$1@news.povray.org>
"Warp" <war### [at] tagpovrayorg> wrote in message 
news:49e396b5@news.povray.org...
> clipka <nomail@nomail> wrote:
>> As a side note, I think a "rotate" statement in a new POV SDL should 
>> *not*
>> follow that nasty "rotate about x then about y then about z" approach, 
>> but
>> instead allow for rotations about arbitrary axes.
>
>  1) Having to always specify the axis of rotation can be tedious.

I disagree, I almost always specify the axis (rotate y*45 for instance) and 
intuitively I would expect something like "rotate <1,1,0>*45" to rotate 45 
degrees around the <1,1,0> vector, not 45 degrees around the x-vector 
followed by a 45 degrees rotation around the y-axis

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com


Post a reply to this message

From: clipka
Subject: Re: A dream about POV4
Date: 13 Apr 2009 23:15:01
Message: <web.49e3c66a840aad1a2dae03a10@news.povray.org>
"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> I disagree, I almost always specify the axis (rotate y*45 for instance) and
> intuitively I would expect something like "rotate <1,1,0>*45" to rotate 45
> degrees around the <1,1,0> vector, not 45 degrees around the x-vector
> followed by a 45 degrees rotation around the y-axis

Hm... the notation "rotate <1,1,0>*45" does seem intuitive, but I guess we'd
need four parameters. Otherwise you'd be surprised why the result would be a
rotation by 63 degrees instead ;)

A nice thing though would be some quick syntax for specifying a normalized
vector, which would work with that syntax; maybe something like:

  rotate <<1,1,0>> * 45 deg

BTW, I'd really like that "deg" keyword to specify angles. Or, preferably, even
the "degree" sign, as in:

  rotate <<1,1,0>> * 45°

but unfortunately it's not ASCII, and therefore a portability issue.
Maybe an extension to numerical literals could do the trick to get something
visually similar:

  rotate <<1,1,0>> * 45o

Really cool would be something like:

  rotate <<1,1,0>> * 45o20'10.37".

But that would cause issues with some editors doing some rudimentary syntax
highlighting...

.... oh well...


Post a reply to this message

From: Zeger Knaepen
Subject: Re: A dream about POV4
Date: 13 Apr 2009 23:17:57
Message: <49e3c825$1@news.povray.org>
"clipka" <nomail@nomail> wrote in message 
news:web.49e3c66a840aad1a2dae03a10@news.povray.org...
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> I disagree, I almost always specify the axis (rotate y*45 for instance) 
>> and
>> intuitively I would expect something like "rotate <1,1,0>*45" to rotate 
>> 45
>> degrees around the <1,1,0> vector, not 45 degrees around the x-vector
>> followed by a 45 degrees rotation around the y-axis
>
> Hm... the notation "rotate <1,1,0>*45" does seem intuitive, but I guess 
> we'd
> need four parameters. Otherwise you'd be surprised why the result would be 
> a
> rotation by 63 degrees instead ;)

the vector is just a direction, and, as in trace, the length shouldn't 
matter

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com


Post a reply to this message

From: Zeger Knaepen
Subject: Re: A dream about POV4
Date: 13 Apr 2009 23:18:39
Message: <49e3c84f$1@news.povray.org>
ok, I take that back, otherwise "rotate <0,45,0>" wouldn't work anymore


Post a reply to this message

From: clipka
Subject: Re: A dream about POV4
Date: 14 Apr 2009 00:20:01
Message: <web.49e3d5a4840aad1a2dae03a10@news.povray.org>
"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> > Hm... the notation "rotate <1,1,0>*45" does seem intuitive, but I guess
> > we'd
> > need four parameters. Otherwise you'd be surprised why the result would be
> > a
> > rotation by 63 degrees instead ;)
>
> the vector is just a direction, and, as in trace, the length shouldn't
> matter

But by how many degrees do you want to rotate?

If you go for analogy with y*45, the angle to rotate by would be encoded in the
vector's length.

The expression <1,1,0>*45, however, evaluates to a vector that is ~63 POV units
long...

So yes, size *does* matter :)


Post a reply to this message

Goto Latest 10 Messages Next 5 Messages >>>

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