Thomas de Groot <tho### [at] degrootorg> wrote:

> I need to ponder this. I fully agree with you by the way, but I think it
> is not a really easy matter to accomplish correctly. I have in my
> ancient times written little demo files for new users of some programs
> at work. It was a hellish job to get it so that even the most "stupid"
> (not supposed to be negative) user could navigate through without
> errors. One gets illuminating insights into the functioning of the human
> mind ;-)

Yes, and the code as well.
There are simple things that ought to be easy to check in a variety of instances
that would make debugging much, much easier.

The easy and bleeding-obvious cases ought to be done first, and then when the
general manner of implementation is established and debugged, the more
complicated and less generally useful cases can be experimented with.

I know that there is a logical and preferred order of statements in a camera
directive, with some overriding others.  It's not obvious without reading the
docs and groups and working it out - but the parser would "know" that it's
overriding something - so just SAY SO.  Then the user could go "Whoops!" and
change the order - or not.

There are obviously a LOT of things that could be done to make writing and
debugging a scene faster, easier, and more reliable.
"Rendering" a scene by some super-fast non-raytracing method would be a huge
benefit to just check the position of objects, especially with animations
consisting of hundreds or thousands of frames.

Some as-of yet unspecified method of quickly checking certain scene objects or
variable values (without having to run the WHOLE scene through the parser) would
be super-useful (with obvious impossibilities).
Perhaps just writing some simple, clean, well-commented code snippets in a fully
working scene for the insert menu would be best for that.

I'm just trying to smooth out the learning curve a bit, and help make it a bit
less arduous.

Removing the need to rewrite some of the labor-intensive "common
computer-science" algorithms and calculations ought to make POV-Ray more
accessible, easier to make better scenes, and more fun to code a scene -
rather than running into "oh crap- how do I do THAT???"

"That's _supposed to work_!  What did I do wrong (this time)!!!"

Post a reply to this message