 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaap Frank <jjf### [at] casema nl> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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:
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ok, I take that back, otherwise "rotate <0,45,0>" wouldn't work anymore
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
