In article <47052101$1@news.povray.org>, Sha### [at] cccc says...
> Fa3ien wrote:
> > 
> > Imagine you have a mesh which requires subdivision, and are
> > making an animation.  If POV-Ray performs the subdivision,
> > various instances of the mesh could be subdivised at different
> > levels, according the distance from the camera
> 
> Best example I've seen yet, and a very compelling, but I'm not sold. 
> This simplification would require more than just distance to the camera,
 
> angle of incidence would also have to be considered. The system would 
> need to be fairly complex to produce a decent result, and characters, 
> landscape, and teapots would all require different rules. One person 
> might someday do this if the SDL were extended enough.
> 
> But how many people are we excluding by obfuscating the SDL?
> 
> When much of the code in p.text.s-f looks like this:
> MacroName (*Param1, %Param2%$, ....)
> new users will not be willing to commit to learning POV's (among free 
> renderers) "Killer App" (scripting interface).
> 
> "Scripting" may mean something different to programmers. but it means 
> something particular to me - something distinct from "Programming." I 
> think POV is best served by a "Scripting Interface."
> 
> I've said several times that if it's necessary for shaders, it needs to
 
> be included. Modeling *will* be done 99% with outside apps, no matter 
> what is included in the SDL. A lot lost for very little gained IMO. If a
 
> non-user read this thread, he might conclude that there are scores of 
> people hand-coding complex scenes in POV or MEL[1], just champing at the
 
> bit waiting for the ability to make even more complex scenes this way -
 
> this is NOT the case.
> 
>   -Shay
> 
Lets be clear about two things. 1) I don't one bit like the idea of 
using external apps to do anything, if I can avoid it, simply because 
instead of improving Moray to the point where it does most of those, 
(and that is *part* of the issue here), you get 50 different ones, each 
of which does one things well, then 100 others that do all those things 
poorly, and frankly... unless you are being paid by fracking ILM, you 
are *not* going to be able to afford all that crap. That is why I would 
rather see a lot of it *in* POVRay, and what isn't, in Moray. So the 
number of ones you *have to have* that are not going to work 100% with 
it anyway, is 1-2, not 20-30.

2) The point of using a decent script language, instead of just cramming 
more stuff into the existing one, is that you can make real libraries, 
that can have clear descriptions for what they do, and how to use them, 
*not* so that everything is MacroName(blah, blah...), which breaks half 
the time because one loop some place is flaky, or something, and it 
didn't generate a valid object. SDL as it stands *will* generate that 
kind of insane mess. I would think fixing it, so you could code real 
functions into it, or even going as far as, I don't know, providing some 
way to include help file info into an include, so that if you want to 
know how something works, the guy that made the functions can have their 
own help on that item auto-linked into the existing help (at least as a 
search term). Something like a few special tags, which the parser 
otherwise ignores, except that, once included, it adds to the help file. 
Or, better yet, if someone loads a new include for the first time, that 
info gets stored in a DB of the added features, along with specifics, 
like what include it belongs to, etc. Sort of, (forgive me, I know some 
people hate XML):

<include_meta>
  Library_name="mylib"
  <help>
    additem="myfunction"
    description="..."
    additem="blah"
    ...
  </help>
</include_meta>

If its already there, its ignored, if it needs to be updated, it is, if 
it isn't in the help, it gets added to the search list, then loaded when 
requested through that. (Though I have no idea if Windows would support 
doing that.)

Point is, the problem with such stuff isn't that a) its not possible to 
design explainable functions (though the existing Media feature could be 
a good example of something that new people are not going to get 
*despite* being described, based on the existing help. lol), or b) using 
a more flexible language would make it worse. The real problem is that 
we have techies writing stuff for other techies, just like lots of other 
stuff in the OSS community (and SDL more or less qualifies as OSS, of a 
sort), instead of thinking about what its going to look like when 
someone that has *no* clue which end it even up in the the program tries 
to use it for something.

Your complaint is mute. There are already things in it *right now* that 
fall into the category of, "How the hell does this actually work?", for 
a new user. Arguing that this is going to happen "after" you change the 
SDL is rather odd. lol

-- 
void main () {

    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