> Are you aware that:
>
>   #macro C()camera#end
>   #declare c=C(){}
>   C(){c}
>
> is valid for parser ? The same applies to:
>
>   #include "strings.inc"
>   Parse_String("camera{}")
>
> Are you sure it isn't simpler to you to write completly new application ?


I have considered that. I was about to write
or modify a RIB renderer, for example.
But I wasn't aware of the camera statement
flexibility per se; thanks. If the POV-Team
didn't mind me copying their parser code,
the argument for doing a new app would
certainly be better advanced. POV also
has all the other infrastructure, such
as texture file loading, in one nice spot.

I believe POV's future lies in being
a more powerful platform for creating
3D graphics in general, not just as
a raytracer. For all I know, this experiment
may one day lead to POV-Ray becoming the dominant
film production tool for CG effects, and enable
a whole new population of movie producers.

VOP already went the "new application" route.
The problem is, its .pov parser is now out of date
and cannot handle many scene files.

For now, I'll probably just require that a
camera be defined up front. It's not a
huge requirement at this stage, and many
people tend to declare cameras early.
If a cam is missing, I could also have
the preview window make its own, which
the person could relocate with the mouse.
Hmm... if it copied the cam data to the
clipboard in .pov format, that would be
an interesting take on NavCam. It would
certainly make defining cameras as easy
as point and click. :)


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"

Post a reply to this message