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

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

Would it be difficult to understand that a sphere is an object,
with properties (position, size, texture...)  and methods (translate,
rotate, copy,...) ?

Concepts like classes might be harder, but we won't really know
until sample code is produced.

> 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.

In the commercial apps, world, it's often a matter of fashion.  Some
years ago, radiosity was most fashionable, now it's faces and skin.
Well, a powerful SDL would also allow easier implementation of advanced
techniques such as hair.  I talked about CSG as an example, but every
aspect of POV-Ray would benefit from

>> 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.

Look at this :
http://www.oyonale.com/variations/variations.php?name=v0207.jpg&lan=fr

Fabien.

Post a reply to this message

Fa3ien wrote:

> 
>> All basic flow-chart type stuff. Understood clearly by even 
>> non-programmers. Objects?
> 
> Would it be difficult to understand that a sphere is an object,
> with properties (position, size, texture...)  and methods (translate,
> rotate, copy,...) ?
> 
No, but it could be to a problem to understand that your internet socket 
isn't an object in the same sense. You can create a unifying mechanism, 
often known as OOP or similar, but you then have to code the sphere 
something like

new Sphere s;
s.Position=[1,1,10];
s.Radius=.7;
s.Texture.Pigment=[0,1,0];
s.Scale(1,2,1);
s.Rotate(30,0,0);

That is all very clear coding, but *not* what most of the group here 
wants. POV4 should be easy to understand in it's most basic declarative 
form. Which in my opinion means that objects as virtual representations 
of things visible in your scene will have a different status and 
different syntax than all other 'objects'. Borrowing standard OOP 
language may be rather confusing in that respect.

Post a reply to this message

> new Sphere s;
> s.Position=[1,1,10];
> s.Radius=.7;
> s.Texture.Pigment=[0,1,0];
> s.Scale(1,2,1);
> s.Rotate(30,0,0);
> 
> That is all very clear coding, but *not* what most of the group here 
> wants. POV4 should be easy to understand in it's most basic declarative 
> form. Which in my opinion means that objects as virtual representations 
> of things visible in your scene will have a different status and 
> different syntax than all other 'objects'. Borrowing standard OOP 
> language may be rather confusing in that respect.

Sure, there's something to find to avoid that kind of cumbersome syntax.

I don't tkink anyone around here would like to make an object's definition
so complicated.  There should be some kind of shortcuts, looking like
current SDL.

Fabien.

Post a reply to this message

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

>
> > new Sphere s;
> > s.Position=[1,1,10];
> > s.Radius=.7;
> > s.Texture.Pigment=[0,1,0];
> > s.Scale(1,2,1);
> > s.Rotate(30,0,0);
> >
> > That is all very clear coding, but *not* what most of the group here
> > wants. POV4 should be easy to understand in it's most basic declarative
> > form. Which in my opinion means that objects as virtual representations
> > of things visible in your scene will have a different status and
> > different syntax than all other 'objects'. Borrowing standard OOP
> > language may be rather confusing in that respect.
>
> Sure, there's something to find to avoid that kind of cumbersome syntax.
>
> I don't tkink anyone around here would like to make an object's definition
> so complicated.  There should be some kind of shortcuts, looking like
> current SDL.
>
> Fabien.

In my scheme, this code would rather be the Java generated intermediate
code.

Bruno

Post a reply to this message

> 
> In my scheme, this code would rather be the Java generated intermediate
> code.

I had missed your post with sample code.  I tend to like what it looks like.

Personally, I am not against something entirely new. I seldom reuse POV code,
anyway, and more flexibility is so attracting.

However, IMO, there's gonna be a huge shields-up from the community, unless
some concerns are properly adressed :

- usability : being able, for example, to define a sphere (position, radius, texture
and
   transforms) in a single line is a must.  Efficient shortcuts should be possible.
- compatibility : being able to use existing code, or continue coding in classic SDL
   style.  Maybe in some kind of wrapper, like :

LegacySDL
{
  union {
   sphere {<0,0,0>,2}
   box {...}
   }
}

Trying to avoid these issues will lead to an endless mess of hot discussions, I think.

Fabien.

Post a reply to this message

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

> >
> > In my scheme, this code would rather be the Java generated intermediate
> > code.
>
> I had missed your post with sample code.  I tend to like what it looks like.
>
> Personally, I am not against something entirely new. I seldom reuse POV code,
> anyway, and more flexibility is so attracting.
>
> However, IMO, there's gonna be a huge shields-up from the community, unless
> some concerns are properly adressed :
>
> - usability : being able, for example, to define a sphere (position, radius, texture
and
>    transforms) in a single line is a must.  Efficient shortcuts should be possible.
> - compatibility : being able to use existing code, or continue coding in classic SDL
>    style.  Maybe in some kind of wrapper, like :
>
> LegacySDL
> {
>   union {
>    sphere {<0,0,0>,2}
>    box {...}
>    }
> }
>
> Trying to avoid these issues will lead to an endless mess of hot discussions, I
think.
>
> Fabien.

Just have a look at the fragment of code I put in the "Attempt to POV4
Syntax basics" thread I just started.

Bruno

Post a reply to this message