> Shay <Sha### [at] cccc> wrote:
>> Best example I've seen yet, and a very compelling, but I'm not sold. 
> 
>   Ok, clearly there's no way to convince you, so we can stop trying.
> You have expressed your opinion at it has become clear. Case closed.

The goal of this discussion, IMO, is not to convince someone that
someone else is right, it's to draw a picture of what can be ahead,
including the pros and the cons of any proposal.

His worries are perfectly licit and likely represent those of many
people.  This should be adressed with enough distanciation.

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:

> > Shay <Sha### [at] cccc> wrote:
> >> Best example I've seen yet, and a very compelling, but I'm not sold.
> >
> >   Ok, clearly there's no way to convince you, so we can stop trying.
> > You have expressed your opinion at it has become clear. Case closed.
>
> The goal of this discussion, IMO, is not to convince someone that
> someone else is right, it's to draw a picture of what can be ahead,
> including the pros and the cons of any proposal.
>
> His worries are perfectly licit and likely represent those of many
> people.  This should be adressed with enough distanciation.
>
> Fabien.

I don't really see that this kind of support is a key point in POV 4, but I
also don't see how it could be a bad thing. I suspect the people spending
time implementing these libraries in SDL' aren't going to be the same
people writing the core code, or rather they don't have to be.

On the mesh issue, render-time subdivision would be interesting, although
for me textures usually seem to outweigh meshes in storage requirements,
and (again for me) minimising render time is more important than memory
use. Render-time subdivision is nice for the first use case, and I would
hope it wouldn't adversely affect the other. I can't see myself making much
use of more general mesh manipulation capabilities in POV, but I can't see
the negative impact, really. From the description it sounds like they would
be a "there-if-you-need-them" feature.

Other things I wanted to mention:

* There seems to be a lot more talk about the future SDL than any future
rendering capabilities.

* Specifically on programmable shaders, how will we maintain backwards
compatibility to the somewhat bitty and odd features like irid? Built-in
shader "library"?

* Probably been mentioned before, but I can't remember; will POV 4.0
incorporate any code at all from 3.7, or will it be a complete rewrite?

* I love media {}. Most of the jobs it fails at are actually jobs for an
improved shading language, in my view. For many things it's excellent, even
compared to some professional applications, unusually.

Tom

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> His worries are perfectly licit and likely represent those of many
> people.  This should be adressed with enough distanciation.

  His worries may be valid, but his proposed solution is not.

  He has got it completely backwards. The new scripting language is going
to make the core code *simpler*, not more complicated (because tons of
features currently in the core code can be removed from there and moved
to libraries). Also there's nothing in a more powerful scripting language
that will automatically make it harder for the average user to use. In
fact, it could well be the opposite: If well designed, the new scripting
language could be *easier* to use than the current SDL (or at least make
many things a lot easier).

  With a powerful scripting language lots of features of the core code
can be removed from there, making the core code smaller and simpler, and
it will then be easier to add features to the core code which really need
to be there (if they can't be implemented in the scripting language or it
would be too inefficient to do so).

  Also a well-designed scripting language will make it much easier to
offer an easy-to-use interface to the core features. In the current SDL
each time a new feature is added, adding the correspondent SDL construct
is usually a pain, makes the parser more complicated and overall has a lot
of overhead.

-- 
                                                          - Warp

Post a reply to this message

Shay wrote:
> Warp wrote:
>> Shay <Sha### [at] cccc> wrote:
>>> C) Invent and code a new programming language and then code the 
>>> algorithm in that language.
>>
>> Right, because all that is necessary for every single algorithm which
>> will be ever made for POV-Ray.
>>
> 
> Not quite. I suppose one set of commands would take care of a handful of 
> converters. The mesh-handling stuff? Well there's decimation for 
> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates 
> mesh models without a mouse (except me)?
> 
I do (sometimes)

Post a reply to this message

nemesis wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> As you might have noticed, not everybody is convinced we should have one (SDL).
> 
> hello?!  Drop povray's SDL and povray is just among many rendering engines.
> I believe to be the crown jewel of povray!
So do I. "one" did not refer to "SDL", as you are apparently assuming, 
but to "new SDL".

Post a reply to this message

St. wrote:
[snip]

>  As it happens, from a non-programmers point of 
> view, I think this thread has been a frenzy of what everyone *wants*, 


What I get from the thread so far is that:
- syntax of the declarative part (objects, textures, transformations, 
...) should stay the same.
- the control structures with # (#if, #macro, ...) should stay (at least 
for now)
- there should be a new set of control structures. Especially to replace 
the #declare and #macro. This should be closer to a conventional 
programming language
- it should be possible to create new objects with the same syntax as 
current ones (box, sphere, etc.)
- More of the internals should be exposed. The representation of e.g. a 
mesh should be known and modifiable at user level to create a 
subdivision, to convert an isosurface of the fly into a mesh, to write 
new import routines, etc.
- At many points it should be possible to call user functions in stead 
of predefined choices. And those functions should be able to call many 
internal functions. This is needed for new shaders and such.
- binary input and output should be supported from within new style 
functions.

 > and in the end, I think nothing will happen directly resulting from
 > this thread imo.

I expect all of these things to be in POV4.


Anyone dare to answer the question on whether POV4 should be a scene 
description language or a scriptable ray tracer?

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> - binary input and output should be supported from within new style 
> functions.

  This also needs new efficient data containers and methods for handling
them (so that it can, for example, be parsed and interpreted easily and
efficiently).

> Anyone dare to answer the question on whether POV4 should be a scene 
> description language or a scriptable ray tracer?

  Both?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
> 
>> Anyone dare to answer the question on whether POV4 should be a scene 
>> description language or a scriptable ray tracer?
> 
>   Both?
> 
Does that mean that a camera will be optional?
Can the sole purpose of a POV4 script be to create a scene and then 
output it in some format like STL (for a 3D printer)?
Will the camera be just one of the functions that gets a scene as input 
to produce some output or will it be handled in a special way?
Will scan-line rendering( or filling a pipeline of a graphics card) of a 
scene be another option in order to get a fast rough idea of the 
composition?

Post a reply to this message

Fa3ien wrote:

> 
>> But how many people are we excluding by obfuscating the SDL?
> 
> its both possible to have a simple SDL, accessible even to
> beginners, and to have new extended  programming possibilities.
> (and 90% backward compatibility,  too).  That should be
> verified by producing theorical SDL  code for simple situations.

Looking forward to that process. I hope what how the SDL *will* be used 
will be taken into account, not just how it *can* be used. One could 
write very clear Perl or c++, but the languages aren't necessarily used 
that way in practice. I'm as guilty as anyone else. I know maybe 10% of 
Python, but a lot of what I know is the ugly stuff. My Python code would 
be no more instructive to a beginner than that of any advanced Python 
guru. Almost anyone could understand my POV code.

> 
> POV-Ray's current SDL is already a programming language.  There
> are
> loops,

Repeat an instruction several times

> conditional,

Do something if a condition is met

> and functional macros.

Repeat an instruction several times

All basic flow-chart type stuff. Understood clearly by even 
non-programmers. Objects?

> there's much more than meshes in a POV-Ray scene.  If CSG could
> be instanciated, and if we had more programming power (and speed)
> within SDL, we could make images of unprecedented complexity,
> images that couldn't be done with any other app, while not
> requiring extreme skills.

Will these images entice savvy 3D users into exploring POV-Ray? I've 
used POV's scripting and instancing to produce "images that 'couldn't' 
be done with any other app." Here, where 90% of images take a couple 
night's work, mine impress. On CG Talk, they'd be torn apart for bad 
lighting.

The road to "higher" is clearly paved. You could render 10 million CSG 
models, and no CSG-Talk member would be sold on POV-Ray. Create a great 
skin or hair texture and you'll have 'em coming.

> 
> If you look at Gilles Tran's images, you will see that, except for
> pre-made people, cars, and such, everything is done in SDL.

Yes, he used it as it has been intended, to script his scene, not to 
model it.

  -Shay

Post a reply to this message

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