|
 |
In article <47d2faa6@news.povray.org>, Charles C <"nospam a nospam.com">
says...
>
>
> John VanSickle wrote:
> > Thomas de Groot wrote:
> >> "Gilles Tran" <gil### [at] agroparistech fr> schreef in
> >> bericht news:47d16636@news.povray.org...
> >>> Note that such a database already exists:
> >>> http://exether.free.fr/irtc/index.php?sub=site&lang=en
> >>>
> >>
> >> What immediately strikes the eye is the gradual decline of
> >> participants over the years...
> >> Is this loss of interest, or does it reflect the increasing complexity
> >> of POV-Ray over the years, I wonder?
> >
> > I think that the growing prominence of GUI-enabled CGI packages,
> > including freeware, caused many POV-Ray users to drift away from POV-Ra
y.
> >
> > Regards,
> > John
>
> I suspect you're right. To me part of what makes POV-Ray fun is
> precisely the idea of modeling with code rather than with a mouse. It's
> hard to explain to people why that's fun though. I normally try to draw
> an analogy by asking something about why are hand-thrown ceramic bowls
> or cups better than much more efficiently made slip-cast or even
> mass-produced bowls/cups? My metaphor doesn't normally get me anywhere.
>
At least part of it has also got to be the fact that even the best GUI
for POVRay is only a pale shadow of what the engine can manage. Basic
stuff, like being able to *see* they changes to textures without a
render, having identical precision levels with respect to locations, the
ability to treat objects "in" the modeler as they would really appear in
code, instead of having to create them all as unit size, with a specific
facing, then translate/rotate them all to place. 90% of the
functionality in the SDL is missing from the GUIs. Those *designed* to
be GUIs in the first place don't have that problem.
The other problem is, even if you do code it, unless you are real good
at it, or know some clever tricks, its not always trivial to get what
you want out of the system, without either a lot of trial and error, or
a math degree. Simple stuff great. But in general, what the GUI does
well, the SDL does badly, due to lack of the one thing the GUI does
have, consistency in how it treats all objects. But, what the SDL can
do, the GUI can't, **precisely** because it can't do absurdly trivial
things, like letting you tell it where the end points are on an object
that *has* end points.
We need a) a gui that supports how the SDL actually works, what is just
easy to do in a gui, and b) macros, or other features, in the SDL, which
can make objects that *don't* work the same, seem to do so. I.e., if I
want to define a box as:
box {<endpoint1>,<endpoint2>,thickness}
provide a way to treat it like a cylinder and do that. It would make
"some" uses of boxes far easier. And, if I want to create a cylinder
like this:
cylinder{<corner1>,<corner2>},direction}
then have some way to do that. The biggest problem I have "personally"
ran into with the SDL has been stuff like the above, where if I could
have been *specific* about the angle, where sides meet, etc., of an
object, it would have taken me 10 seconds to solve a problem, but
instead I spent an hour trying to find math for calculating the needed
length of a side, and one angle of a triangle, so I know how to rotate
and position something, where it *needs* to be. Moray is even worse
imho, since its precision limitations make lining things up impossible
in some cases, and *everything* has to be either calculated to line up
via angles, even when you don't need to in the SDL, and/or, you hope
that everything really "does" line up close enough that you didn't miss
something, or its obvious that the parts don't *actually* fit properly.
Again, this would be easier if you could, for example, tell a box, "Snap
your endpoint to the same location as the center of that circle." You
can't, in *either* SDL or the GUIs we have for it. Well, at least not
unless you are using mesh systems, instead of primitives, but then, your
not using 90% of the SDL anyway, just Mesh.
The problem imho, is simply that its too difficult, as things stand, to
use POVRay, in either method, so only the people that can't afford
systems that make it easier, or who have a thing for precise control,
despite the need for complicated solutions, care to use it. A lot of
people would probably rather scrape the money together, even if they
can't afford something else, than have to spend hours trying to get a
box to line up with a specific angle and length, along with a bunch of
other stuff that, aggravatingly, they can just tell it, "put there!",
etc.
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
