POV-Ray : Newsgroups : povray.general : PovRay features suggestions : PovRay features suggestions Server Time
6 May 2024 23:33:40 EDT (-0400)
  PovRay features suggestions  
From: Bald Eagle
Date: 24 Sep 2019 20:50:00
Message: <web.5d8ab8c7d17392cf4eec112d0@news.povray.org>
Just throwing these out there as I do periodically.

After working on some scenes and fielding user questions, I had "the thinks"
while trying to get some much-needed sleep, and much of it goes back to what a
newbie is presented with when first starting to use POV-Ray, and the
"command-line"/programming nature of POV-Ray vs a currently
functioning/supported GUI modeler.

I think that the learning curve for POV-Ray is a bit steep, and there are a lot
of moving and detached parts.

If some of the things that are currently in #include files could be implemented
in source, that would be great.   The first thing one learns about detachable
parts (like include files) is that they get lost.
[observe how often people are looking for a lost Colefax or other include file]

Following up on that, I've been mulling the idea of building a large include
file that will hold most everything I use, without having to remember the
filenames and use multiple include files.
This would require parsing the whole file, and I'd need a way to only store in
memory the parts that I wanted (#if ought to git 'er done)
With regard to the parsing, could something like #exit be implemented to abort
parsing an #include file early?   Sort of like #break?
(Also, is there a file type or structure that would allow
skipping/jumping/indexing a larger file?)


As a new user, working with trying to construct a scene in 3D, I think it is
natural to conceive of "drawing in 3D space" and defining and manipulating
_points_ seems intuitive and expected.

Just having a point{} object would be limited, but having a pointcloud{} object
would work very nicely, I think.
This would probably be/work exactly like an array, and just be a list of one or
more points that can take advantage of the brief and simple syntax of rotate,
translate, scale, etc.

This would allow a very accessible means to keep track of where certain
reference points are in the scene without requiring the need to learn the
keywords and syntax of all of the code to transform 3D vectors, as well as
making it possible to append "points" to an object in a union {}.  Those points
would them "follow" the shape around, and then be referenced to trivially
discover the new transformed position.
Super useful for cylinder (line segment) endpoints, box corners, centers, face
centers, edge centers or subdivisions, points on sphere surfaces (globes), etc.

It would also allow "glueing" and "rubber banding" which is popular and nearly
essential in most drawing / charting / CAD programs.

With regard to facilitating scene construction, in the absence of a GUI modeler,
and reigning back on the "but there's already a [detachable] macro for that" - I
think it would be nice to keep a running list of geometric functions (features)
that would be very nice to implement (in source) so as not to forget about them.
  Much like we have bug reports - but this would be a desired/requested feature
report.  Maybe even put a placeholder function in source with a warning message
- "feature not yet implemented" in case anyone tries to invoke it.

There are likely many questions that a [new] user needs the answer to, and
doesn't have the geometric / mathematical / programming knowledge to implement -
unlike a GUI where it's all point-and-click.
"What's the normal vector at <x,y,z>?"
"Where do these two "lines" intersect? (if anywhere)"
"What's the closest point on plane P to my point P?"
"What is the center and radius of the bounding sphere of these points?"

And likely a bunch of others.

And lastly, default values for some of the the primitives.
We have a default scene space, and default camera parameters, and a default
pigment - I think it would be useful for new users to be able to get a lot done
in terms of placing visible objects on the screen if things like
plane {default]
sphere {default}
axes {default}
box {default}

were fully valid directives.

Throw in a message to the #debug stream "try using sphere {<0, 0, 0>, 0.5
pigment {rgb 1}} when invoking "default" parameters, and it would avoid a lot of
new user frustration, act as a help/man command, and facilitate that first
"hello world" scene.


Just emptying my brain onto the forum for the record.


Post a reply to this message

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