> 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

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

I've seen it. Very interesting, I like that.  Waiting for the fire :-)

(be very cautious when speaking of Java, some people will interpret it
  as "he wants to write POV scenes in Java", or "he wants to rewrite
  POV-Ray in Java"...)

Fabien.

Post a reply to this message

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

>
> > Just have a look at the fragment of code I put in the "Attempt to POV4
> > Syntax basics" thread I just started.
>
> I've seen it. Very interesting, I like that.  Waiting for the fire :-)
>
> (be very cautious when speaking of Java, some people will interpret it
>   as "he wants to write POV scenes in Java", or "he wants to rewrite
>   POV-Ray in Java"...)
>
> Fabien.

I know. But I am ABSOLUTELY NOT thinking of a rewrite in Java, nor do I want
to write scenes in java. On the contrary, I am digging a bit about how the
new syntax might look like, while keeping what is nice in the current
notation.

I am digging a solution with Java as an intermediate langage. I try to find
how we can take advantage of the characteristics of Java (linguistic,
syntax, runtime, ...) for POV4. So far, this solution permits high-level
features that pov lacks today. It also permits an easy translation from
POV4 to Java. Then the Java compiler makes the low-level job.

Thats a start point, but now, we have to think effectively of the syntax
itself and find a match between feature and notation.

As I said earlier, the syntax is one thing, how to parse/compile POV4 code
is another, and the last but not least, the rendring engine in another big
concern.

I'll try to suggest some more fragments of code. Help welcome.

But I did not dig enough yet to say it is a dead end. Help welcome also.

Would you participate to this investigation? Who would?


Bruno

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,...) ?

How about:

#local MyOb = difference {
   sphere { 0, 1 translate y*2 rotate z*45 translate <2,3,4> }
   object { Some Other Object }
}

MyOb.subtrahend.transforms[1].addrotate(<0, 0, 15>);
MyOb.subtrahend.transforms[0] *= <1,0,0,0,0,1,0,0,0,0,0,1,0,5,0,1>

which would end up *everywhere*. And the small minority who do 
understand it would be "responsible" for supporting this feature in the 
newsgroups.

> Well, a powerful SDL would also allow easier implementation of
> advanced techniques such as hair.

It would, and I believe the SDL should have sufficient power to do so. 
Enough power for render-time subdivision surfaces? No. "Extra" data 
structures and methods for modeling algorithms and text-processing? No.

"I did it without 3rd party apps!" only impresses within this community 
and isn't going to get POV-Ray by for another 15 years. New users, drawn 
by capabilities they can put to use without a comp-sci degree, are what 
will guarantee POV's future.

-Shay

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shay wrote:
> How about:
> 
> #local MyOb = difference {
>   sphere { 0, 1 translate y*2 rotate z*45 translate <2,3,4> }
>   object { Some Other Object }
> }
> 
> MyOb.subtrahend.transforms[1].addrotate(<0, 0, 15>);
> MyOb.subtrahend.transforms[0] *= <1,0,0,0,0,1,0,0,0,0,0,1,0,5,0,1>

Quick question for the group:

Does anyone see any value in being able to use OO syntax to transform an
object *after* it's declaration, in the general way shown in Shay's
example? (I would like to hope that we could come up with a cleaner
syntax than that.)

In principle, it seems like it could be useful, but I can't actually
come up with any concrete examples of things that couldn't be
accomplished in the current SDL.

Anyone?

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you spend more time
"tweaking" a texture than modelling the rest of the scene.
    -- Twyst
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBmjhcCmTzQ++ZncRAitFAJ9dcfk7dBH57x1ARKlBqTq1EqhPpACgnUwq
ZGs6Do9ExvIWpdGoIFISCkU=
=0LZV
-----END PGP SIGNATURE-----

Post a reply to this message