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:
> Shay a écrit :
> 
>> 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 () {
  If Schrödingers_cat is alive  
    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

Shay a écrit :

> 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:
> Shay a écrit :
> 
>> 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

andrel a écrit :

> 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:
> andrel a écrit :
>
> > 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

Bruno Cabasson a écrit :
> 
> 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:
> Bruno Cabasson a écrit :
> >
> > 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

Bruno Cabasson a écrit :

> 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:
> Bruno Cabasson a écrit :
>
> > 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:
> Shay a écrit :
> 
>> 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

William Tracy wrote:
> 
> 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,

There is some value.

The current SDL way:

#local A = sphere { 0, 1 }

// an instance of A
object { A
   translate y*1
   rotate z*10
   rotate x*20
   scale <23,44,33>
}

// another instance of A
object { A
   translate y*2
   rotate z*10
   rotate x*20
   scale <23,44,33>
}

Possible 4.0 way:

#local A = sphere {
   translate y*1
   rotate z*10
   rotate x*20
   scale <23,44,33>
}

// an instance of a
A.transform[0] = <0,1,0>
object { A }

// another instance of a
A.transform[0] = <0,2,0>
object { A }

Just a shortcut, though this might help with instancing of CSG objects 
(makes sense to me that it would. Ask a programmer.). The point isn't 
that it's terribly useful for changing the transformation of an object. 
The point is that it *is* terribly useful for playing around with huge 
lists of mesh vertices AND that the perhaps marginal usefulness of using 
it with spheres would cause others to use it in even simple scenes, 
making the SDL harder to learn.

To address something Patrick Elliot said: Don't understand media and you 
won't understand media scenes. Don't understand a major language concept 
and you won't understand many scenes at all.

  -Shay

Post a reply to this message

Shay a écrit :

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

If a small minority creates obfuscated code, it won't end up everywhere,
because it's a... mhhh... minority.  Besides, community spirit will
lead many people to take care of writing simple and clear code.  Also,
currently, there are already some complicated macros out there,
which few are able to fully understand, you can't always avoid
complexity.  Finally, in many situations, re-using someone's code
doesn't imply fully understanding it (I'm not able to understand a
fractal tree macro everyday, but I can use it everytime).

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

Doing things without 3rd party apps is not a matter of looking smart.
It's a matter of convenience when it can be done.

Let's stay with the example of subdivision surfaces (or any other
automated process for meshes).

I model something in Wings3D.  Then I export it to POV-Ray.  Suddenly,
I think, oh, I would need one more subdivision level for my object
to look smooth !  If it's done within POV-Ray, there's just a parameter
to change.  If not (as currently), I have to go back to Wings, do the
subdivision, and re-export !

Still skeptic ?

Let's talk about displacement mapping.  The thing that can transform
a cylinder into a screw in no time.  If it's external, I have to freeze
the model to a certain scale and depth of displacement, and the 
resulting mesh will be huge and will take time to read into POV.
If I can do it internally, changing displacement parameters would
be a snap, and much less time will be needed to process (everything
would happen in fast memory).

Many examples of such added flexibility could be found...

Fabien.

Post a reply to this message

Warp 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, 
> 
I think that the way to do that is to let him know that he is being 
heard.  Shay is carrying the torch for a number of us, probably, who 
fear that the simplicity of the current SDL may be lost, and fear also 
that overambitious goals may lead to naught.  Though a bit sarcastic at 
times, he has presented some coding cartoons that very accurately 
portray our fears.  Shay, who personally would be perfectly comfortable 
with arcane and cryptic coding patterns, is worried about those who 
would not be.

On your side, it seems, you fear you are also shouting into the wind. 
That no one more than you loves POV for what it is and only seek to 
improve on the thing, and modernize it by some basic organizational 
changes. In a very startling way, the one thing that you and Shay seem 
to agree on is the need for shaders.  I think what you are offering here 
  is further ways that the shader model could be used to improve the POV 
interface.  I acknowledge and trust your advanced knowledge of lowlevel 
programming and how computers work on the more basic levels. Your 
suggestions make common sense to me.  You want support for better data 
stuctures.  That makes common sense to me.  If you ideas would allow the 
more technically talented to add speed and fuctionality for the less 
technical of us to take advantage of,...great.  That has always been one 
of the backbones of this community.

But I also know that people are subject to the fashion of ideas.  As one 
person once said to me, 'the great thing about standards is that there 
are so many to choose from.'  In other words we all fear that the 
organization advantage of a comman standard is the need for some 
personalities to want to control the behavior of others.  And everyone, 
naturally, would prefer a set of gestalts that they are the most 
comfortable with.

This was crystalized for me in another place by Bruno Cabasson's 
illustration of an inheritance scheme.  And I have valued Bruno's 
contributions to his discussion for their clarity, and also his effort 
to illustrate what he means with a syntax example. Because as soon as I 
saw it, I understood its appeal,...but not to me.

So I wonder, Warp, if there might be a way that you could more clearly 
diagram you ideas such that we could see the advantages and fear less 
the idea that we all need to turn into C programmers?

Post a reply to this message

William Tracy wrote:
> -----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.)
Yes. I think if you have a complicated scene where the position of 
objects is either random or is changing during an animation, it is 
better to have all the instantiations of objects in one place and 
everything that positions it close together.

For an animation it could even mean that you can 'precompile' all 
objects and don't have to reparse everything, but only reposition the 
moving parts. But that might require saving an internal state to disk.

> 
> 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.
> 
I can't either.

Post a reply to this message

William Tracy a écrit :

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

Yes, especially on objects collections.  Say you have a set of 100
spheres. Initially, they are small and red.  You want 60 of them
to become big, and 60 of them to become blue, but only 10 will
be blue AND big.  Either you make a complicated loops system,
either you just apply, successively, new parameters to 2 different
subsets of spheres.

 > (I would like to hope that we could come up with a cleaner
 > syntax than that.)

(the syntax above is very pessimistic)

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

Bruno Cabasson's example code looks like a good start to me.

Fabien.

Post a reply to this message

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

Jim Charter wrote:
> But I also know that people are subject to the fashion of ideas.  As one
> person once said to me, 'the great thing about standards is that there
> are so many to choose from.'

I always thought that quote was supposed to be sarcastic. 8-|

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

You know you've been raytracing too long when you can no longer tell the
difference between the top raytracing book and the "Raytracing for
Dummies" book. To you, they're both hopelessly uninformed.
    -- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBoZAcCmTzQ++ZncRAny0AJ9EQ77OcHkpbpjHE0rNf92UNm/9bACgsrES
DWLnviFI/4bLQeCohVBLgkI=
=R9wr
-----END PGP SIGNATURE-----

Post a reply to this message

Shay escribió:
> Possible 4.0 way:
> 
> #local A = sphere {
>   translate y*1
>   rotate z*10
>   rotate x*20
>   scale <23,44,33>
> }
> 
> // an instance of a
> A.transform[0] = <0,1,0>
> object { A }
> 
> // another instance of a
> A.transform[0] = <0,2,0>
> object { A }
> 

The real OOP way would be:

Sphere A = sphere {
   translate y*1
   rotate z*10
   rotate x*20
   scale <23,44,33>
}

// an instance of a
A.transform[0] = <0,1,0>;
scene.addObject(A);

// another instance of a
A.transform[0] = <0,2,0>
scene.addObject(A);

addObject could also apply to CSG objects :) I think it's nicer to do this:

Union all = union{};
/* shinyThings is an array */
foreach(obj in shinyThings) {
     all.addObject(obj);
}

Than using POV-Ray's current "power" to put loops anywhere:
union {
     #foreach(obj in shinyThings)
         object { obj }
     #end
}

This is just like allowing macros anywhere: it blocks from doing many 
performance improvements. Evil stuff like this is currently possible:
#declare I=0;
#while (I<10)
union {
#declare I=I+1;
#end

whatever

#declare I=0;
#while (I<10)
}
#declare I=I+1;
#end

Just as bad as #macro abuse.

Post a reply to this message

Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> I am digging a solution with Java as an intermediate langage.

  Using the Java bytecode as the bytecode used in POV-Ray could be an
idea, but I'm not sure it's the only or the best possible existing
bytecode format and engine.

-- 
                                                          - Warp

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> 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.)

  Being able to *read* object data would at least be very useful, for
example to export the scene to some file format.

  Modifying the object could be useful at least with meshes. If support
for modifying meshes is added, why limit it there?

-- 
                                                          - Warp

Post a reply to this message

In article <4705eeb7$1@news.povray.org>, 
fab### [at] yourshoesskynetbe says...
> andrel a écrit :
> 
> > 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 definitio
n
> so complicated.  There should be some kind of shortcuts, looking like
> current SDL.
> 
> Fabien.
> 
What we need is something "between" the extremes. Something that allows 
you to look at the sub-levels of an object in the parts of the SDL that 
handle execution and looping, etc., which still keeping the "creation" 
of the object reasonably distinct.

Lets put it another way. In stuff like VB and others you can do 
something like:

typedef fred
  jim as integer
  nosh as string * 2
endtype

dim gg as fred

Then when you *used* that, you gain the ability to do:

gg.jim = 5

Same thing here, in theory. The initial creation of an object doesn't 
need to fundamentally change at all, just how the "code" level of the 
SDL "sees" the object once it exists. The only possible issue I can see 
is with a few things like rotate/scale, etc., where you might need to 
use an enumeration to keep track of which one you are working with. But 
that's not a huge problem. Lets say you have:

#declare body = object {... arm{rotate blah 'some other stuff' rotate 
blah2} ...}}

And you want to adjust the "first" rotation.

body.arm.rotate(0)="<5,0,0>"

Wow! So hard... And the *initial* creation of the object didn't change 
on tiny bit, its still standard SDL, you just now have more control over 
each individual aspect of *that* object. And its not likely to be that 
complicated to tell the difference between 'body.arm.rotate(0)
="<5,0,0>"' and say 'body.arm.texture(0).rotate(0)="<5,0,0>"', right?

Please, some one explain to me why this is supposed to be a horrible 
idea, or requires some silly, "new object s;", BS to do anything. At 
worst it wouldn't make sense to use it to do anything but make copies of 
existing objects, at best, its redundant for even that, since its much 
easier to use another declare to produce a new name for it. Point being, 
some thought may been to go into how to handle multiple objects in 
enumerations/arrays, such as when generating them through a trace, so 
that you have the same level of access to specific objects. Such as 
liking the position of 49 of 50 trees that get "planted" by it, but 
needing to make some minor change to the 50th. You could do that "in" 
the trace loop, or you could do it "after", by just referencing that 
specific tree in an array. Both would work, but in some cases the later 
"might" be more useful, if for no other reason than clearly setting the 
statement that makes the change some place other than in your loop, you 
could make it more "visible" to someone looking for such adjustments. 
Puting the code to make minor adjustments in the middle of the same mess 
that generates what you are adjusting could obfuscate "both" the changes 
and the code doing the generation, if you have to make a number of such 
changes.

And yeah, I know, there are bound to be lots of examples of how you 
could do it some other way. Ok, here is something, for this example. You 
have something that you want, in an animation, to zip back and forth 
between "random" trees in your trace. You do a) keep a list of the 
locations for every tree, so you can pick random ones from "that", or 
keep an array of the trees, so all you need to do is look at the 
location of tree 14, 3, 7, then 12, etc., from the trees themselves? 
Again, you could do it either way, but one of those is going to a) slow 
the parse a bit more, and b) take more memory to store redundant 
information.

Anyway...

-- 
void main () {
  If Schrödingers_cat is alive  
    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

Patrick Elliott escribió:
> The only possible issue I can see 
> is with a few things like rotate/scale, etc., where you might need to 
> use an enumeration to keep track of which one you are working with. But 
> that's not a huge problem. Lets say you have:
> 
> #declare body = object {... arm{rotate blah 'some other stuff' rotate 
> blah2} ...}}
> 
> And you want to adjust the "first" rotation.
> 
> body.arm.rotate(0)="<5,0,0>"
> 
> Wow! So hard... And the *initial* creation of the object didn't change 
> on tiny bit, its still standard SDL, you just now have more control over 
> each individual aspect of *that* object. And its not likely to be that 
> complicated to tell the difference between 'body.arm.rotate(0)
> ="<5,0,0>"' and say 'body.arm.texture(0).rotate(0)="<5,0,0>"', right?
> 

I don't know why somebody would need to change individual 
transformations. In addition, it could be cumbersome to refer to 
transformations by their numerical index Just to let you know: POV-Ray 
(currently) doesn't keep individual transformation statements. Every 
transformation you do changes the transform matrix of the object, so you 
can only do further transformations on the existing matrix. Only way to 
edit a previous transform would be to "undo" all that followed, re-do 
the changed transform with new parameters, and re-do all that followed.

Also, how would you handle this?
sphere {
    <1,2,3>, 0.5
    translate <12,35,61>
    texture { some_complex_texture }
    translate y*2
}
The first translate doesn't affect the texture, the second does.

I think we would be fine with body.arm.rotate(5,0,0) which affects the 
current transformation matrix just like current POV does, without having 
to keep every individual change that has been done.

Post a reply to this message

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

> Doing things without 3rd party apps is not a matter of looking smart.
> It's a matter of convenience when it can be done.
>
> Let's stay with the example of subdivision surfaces (or any other
> automated process for meshes).
>
> I model something in Wings3D.  Then I export it to POV-Ray.  Suddenly,
> I think, oh, I would need one more subdivision level for my object
> to look smooth !  If it's done within POV-Ray, there's just a parameter
> to change.  If not (as currently), I have to go back to Wings, do the
> subdivision, and re-export !

I think your vertex displacement example makes more sense. It's pretty
obvious in Wings (or any other tool where you have interactive realtime
preview capabilities) how smooth a mesh is (or isn't) after a subdivision.
The main advantage of render-time subdivision is reduced use of disk space
and less parsing.

To provide a counter-example, how about mesh decimation? It's easy to
imagine a mesh where the decimation works well on one part of the mesh but
doesn't do so well in a section of it. It could take many re-renders in POV
(involving a complete adjust-parse-render cycle, nothing like realtime)
before I find parameters for which the decimated mesh looks good. This is
already enough of a pain with renderer-specific features it can't really be
avoided for, like radiosity. When I have access to tools with realtime
preview capability for meshes, it makes much less sense to involve POV for
many mesh operations, in my view.

Making waves on the surface of a mesh ocean during an animation? Thumbs up
to this idea. For *all* mesh manipulation, given the external tool's much
faster preview, POV's attachment to triangles rather than quads, and the
fact that once it goes in to SDL (even future SDL) it's never coming out
again? I don't see the advantage.

Tom

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> > I am digging a solution with Java as an intermediate langage.
>
>   Using the Java bytecode as the bytecode used in POV-Ray could be an
> idea, but I'm not sure it's the only or the best possible existing
> bytecode format and engine.
>
> --
>                                                           - Warp

For sure. But it is the one that came to my mind. It is just a vague scheme
and general principle. Whatever solution we choose, there will be a quite
long way from the idea to the first 'official' benchmark scene in POV4
syntax. For now,I must cook it a little more and make a more elaborate
example.

BTW, I am quite a good chef, and concerning (french) cuisine, I have good
intuitions and I like to improvise. I never use recipes, I reinvent all the
time, but often use good ol' principles that match the human taste. I also
often search for new ways ...

I'll try to add more POV ingredients into the pans. I remind you that a
dinner has success also because of the quality of the guests. And there are
quality people around here!

Bon appétit, mes amis!

    Bruno

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> Also, how would you handle this?
> sphere {
>     <1,2,3>, 0.5
>     translate <12,35,61>
>     texture { some_complex_texture }
>     translate y*2
> }
> The first translate doesn't affect the texture, the second does.
>

Just like POV does (correct me if I am wrong): when translate is encountered
it translates the whole object. At the time of first translate, no texture
is specified yet (=null, I suppose). At the time of the second the sphere's
'texture' field is non-null, thus transformed with the object. The final
state is that de texture has been translated twice.

In new SDL, it would be the same: the translate() method (or whatever it
will be) of an object (or its derived) will apply on whatever there is
inside the current object. You could have also written

 sphere {
     <1,2,3>, 0.5
     translate <12,35,61>
     texture { some_complex_texture translate 100*x}
     translate y*2
 }

with 3 translations for the texture.

Bruno

Post a reply to this message

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
> In my scheme, this code would rather be the Java generated intermediate
> code.

In my Scheme, this code would be sweet. ;)

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Personally, I am not against something entirely new. I seldom reuse POV code,
> anyway, and more flexibility is so attracting.

People with huge custom libraries would certainly disagree.

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> 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.)

This is something I'd always like to do:

// a 3-legged 1-unit sized stool at origin.
#local stool = Stool { 0, 3 texture { textures.oak rotate 30 } }
stool.scale( .3, 1.4, .3 );
stool.place_on( floor );
stool.away( 3, nw_wall );

#local sph = sphere { 0, 1 pigment { rgb x } }
sph.place_on( stool );

Relative positioning of objects in the scene should benefit imensely from
not having to explicitely keep track of their positions by means of local
variables or half-assed positioning macros.  I've placed a sphere upon a
stool on the floor, without ever having to pass their sizes or positions.

Yes, there's trace and some positioning macros that allow us to do something
like that today in the "half-assed" routines we have in our personal
toolsets, but that's nothing compared to having current position and
transform state inside the objects themselves as properties, rather than
needing to declare variables for that purpose.

For instance, the stool is inittially at the origin  and then I place it on
the floor, which might be anywhere in the y scale.  If I had a macro to
determine the actual position of an object, given the identifier stool, all
it would get would be 0, the original location.

Post a reply to this message

andrel  wrote in message <470### [at] hotmailcom>:
> 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.

This code is a little bit verbose, but not much. Consider the current SDL
equivalent:

#declare s = sphere {
  <1,1,10>, .7
  texture { pigment { rgb <0,1,0> } }
  scale <1,2,1>
  rotate <30,0,0>
}

Roughly the same number of lines and characters, and the same
self-documented readability.

I think that "most of the group here" wants the second only because they
already have the habit of knowing it, not because it has inherent qualities.

Which is a point to take into consideration, of course.

Post a reply to this message

Fa3ien  wrote in message <47068487$1@news.povray.org>:
> Yes, especially on objects collections.  Say you have a set of 100
> spheres. Initially, they are small and red.  You want 60 of them
> to become big, and 60 of them to become blue, but only 10 will
> be blue AND big.

Then you have to link POV-Ray 4 with libmath-2, because with the current
version, you get 110 objects :-Þ

Post a reply to this message

>... POV's attachment to triangles rather than quads, and the
> fact that once it goes in to SDL (even future SDL) it's never coming out
> again? I don't see the advantage.

No doubt NURBs will end up in 4.0 in some fashion since
they are requested quite often.

I would think that the syntax of 4.0 must retain most of
the look and feel of current SDL.  This is part of why I
think that breaking up the scenes into sections like
environment{} pre_process{} ... scene ... post_process{}
would make sense.  That way certain advanced features
would be easily located.

Imagine being able to overload object definitions...

environment {
   overload {
      box{A,B}
      //wireframe objects
      cylinder {A,<A.x,A.y,B.z>,0.05} ... etc
   }
}

in order to change all the regular boxes in your scene into
wireframe.  This is aspect oriented, which is a good fit
for Pov, IMO.

Object oriented would mean the attachment of methods...
for non-programmers that means functions, which in the
case of Pov probably would end up being to manipulate
graphic objects. That might end up with something like...

box {A,B
   modify {wireframe(diameter)}
}

Where wireframe is a method for box. The problem with
this is that wireframe is probably going to be defined
somewhere in C++ instead of in SDL.  The functions would
be handy, but limited by your ability to program and
compile, most artists will avoid that I think.

Post a reply to this message

Bruno Cabasson escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> 
>> Also, how would you handle this?
>> sphere {
>>     <1,2,3>, 0.5
>>     translate <12,35,61>
>>     texture { some_complex_texture }
>>     translate y*2
>> }
>> The first translate doesn't affect the texture, the second does.
>>
> 
> Just like POV does (correct me if I am wrong): when translate is encountered
> it translates the whole object. At the time of first translate, no texture
> is specified yet (=null, I suppose). At the time of the second the sphere's
> 'texture' field is non-null, thus transformed with the object. The final
> state is that de texture has been translated twice.
> 
> In new SDL, it would be the same: the translate() method (or whatever it
> will be) of an object (or its derived) will apply on whatever there is
> inside the current object. You could have also written
> 
>  sphere {
>      <1,2,3>, 0.5
>      translate <12,35,61>
>      texture { some_complex_texture translate 100*x}
>      translate y*2
>  }
> 
> with 3 translations for the texture.
> 
> Bruno
> 
> 
You missed my point (because I didn't make it so clear :P). How would 
you handle that *and* allow syntax like this?

sphere.translate[0]="<5,0,0>"

I think it's a bad idea to allow changing individual transformation 
statements after the object has been created.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> sphere.translate[0]="<5,0,0>"

> I think it's a bad idea to allow changing individual transformation 
> statements after the object has been created.

  There's no such a thing as a "translate" element in a sphere (or in
any other object for that matter). Thus it would make no sense to have
such an element in the sphere object of the new SDL either.

  What should exist is a *function* (member or not) which applies the
translation to the sphere (which is a different thing). Calling this
function will, naturally apply the subsequent translations properly
(as well as other transformations).

  (In general all transformations are internally collected into a
4x4 transformation matrix, except when the transformation can be
optimized away by eg. transforming the center point of the sphere
only. However, there exists no "translate" member variable in the
sphere object or any other object.)

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez wrote:

>>
> You missed my point (because I didn't make it so clear :P). How would 
> you handle that *and* allow syntax like this?
> 
> sphere.translate[0]="<5,0,0>"
> 
> I think it's a bad idea to allow changing individual transformation 
> statements after the object has been created.

why? In the current SDL objects can still be moved after creation. They 
can not after rendering begins, but you have a point, if a shader has 
access to all underlying data structures, it could move any object while 
rendering. That would break any attempt to subdivide the task over 
processors. We need to make sure that all properties are locked during 
rendering. Or are there properties that could be changed?

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Bruno Cabasson escribió:
> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >
> >> Also, how would you handle this?
> >> sphere {
> >>     <1,2,3>, 0.5
> >>     translate <12,35,61>
> >>     texture { some_complex_texture }
> >>     translate y*2
> >> }
> >> The first translate doesn't affect the texture, the second does.
> >>
> >
> > Just like POV does (correct me if I am wrong): when translate is encountered
> > it translates the whole object. At the time of first translate, no texture
> > is specified yet (=null, I suppose). At the time of the second the sphere's
> > 'texture' field is non-null, thus transformed with the object. The final
> > state is that de texture has been translated twice.
> >
> > In new SDL, it would be the same: the translate() method (or whatever it
> > will be) of an object (or its derived) will apply on whatever there is
> > inside the current object. You could have also written
> >
> >  sphere {
> >      <1,2,3>, 0.5
> >      translate <12,35,61>
> >      texture { some_complex_texture translate 100*x}
> >      translate y*2
> >  }
> >
> > with 3 translations for the texture.
> >
> > Bruno
> >
> >
> You missed my point (because I didn't make it so clear :P). How would
> you handle that *and* allow syntax like this?
>
> sphere.translate[0]="<5,0,0>"
>
> I think it's a bad idea to allow changing individual transformation
> statements after the object has been created.

Maybe it's me who did not understand well ;o)

However, my vision of things is that the MyObjectType { } block could be a
notational/convenience shortcut, as close to current syntax as possible (at
least obeing the same notational principles), for a 'constructor' in the
sense of 'creating a new object of a specific king with specific
characteristics you valuate'.

What we could decided right now by people here, is: would it be possible to
change charateristics of an object AFTER its creation, displacing it,
changing its texture, or performing specific operations (some basic
mesh-editng ...?)?

We caould have something like:

YES --> Form 1:
my_stool = Stool
{
    <stool class properties, that were not defaulted in class definition>
    < or overridden properties>
}
..../...
my_stool.to_mesh();
my_stool.some_mesh_editing_feature();
my_stool.smooth(); // It's a mesh now

NO --> Form 2:
my_stool = Stool
{
    <stool class properties, that were not defaulted in class definition>
    < or overridden properties>
    to_mesh();

    // It's a mesh now, so, it inhertits mesh methods
    some_mesh_editing_feature();
    smooth();
}

The second form would allow method calls within the creation block, and the
syntax would be more likely not to allow any further modification outside
this block(= after creation). Thinking of that while typing these lines, I
prefer Form 2.

Remark: a new syntax (or whatsoever) cannot be mature at first try. We will
have to make several rounds before the new syntax is considered as
'usable'. My experience is that nothing is really OK before version 3.
Version 1 is a first attempt to have 'all together', version 2 often
implies changes in the approach and many modifications corrections making
the system 'work', version 3 is the one that makes 'all together' AND
'working' AND 'quite fine'.

Bruno

Post a reply to this message

Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> What we could decided right now by people here, is: would it be possible to
> change charateristics of an object AFTER its creation, displacing it,
> changing its texture, or performing specific operations (some basic
> mesh-editng ...?)?

  I don't see why not.

  This is *especially* true with transformations, given that transforming
an object is an operation done to the object (which is collected into a
single transformation matrix), not a property of the object.

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> sphere.translate[0]="<5,0,0>"
> 
>> I think it's a bad idea to allow changing individual transformation 
>> statements after the object has been created.
> 
>   There's no such a thing as a "translate" element in a sphere (or in
> any other object for that matter). Thus it would make no sense to have
> such an element in the sphere object of the new SDL either.
> 
>   What should exist is a *function* (member or not) which applies the
> translation to the sphere (which is a different thing). Calling this
> function will, naturally apply the subsequent translations properly
> (as well as other transformations).
> 
>   (In general all transformations are internally collected into a
> 4x4 transformation matrix, except when the transformation can be
> optimized away by eg. transforming the center point of the sphere
> only. However, there exists no "translate" member variable in the
> sphere object or any other object.)
> 

Yep, that was my point. Transforming the object further should *of 
course* be allowed (complex CSG would become fairly impossible without 
that!), but having all individual transformation "items" stored in an 
array and being modifiable seems like a bad idea.

That was what Patrick Elliot said, and I was replying to:
 > And you want to adjust the "first" rotation.
 >
 > body.arm.rotate(0)="<5,0,0>"
 >

Post a reply to this message

andrel escribió:
> Nicolas Alvarez wrote:
> 
>>>
>> You missed my point (because I didn't make it so clear :P). How would 
>> you handle that *and* allow syntax like this?
>>
>> sphere.translate[0]="<5,0,0>"
>>
>> I think it's a bad idea to allow changing individual transformation 
>> statements after the object has been created.
> 
> why? In the current SDL objects can still be moved after creation. They 
> can not after rendering begins, but you have a point, if a shader has 
> access to all underlying data structures, it could move any object while 
> rendering. That would break any attempt to subdivide the task over 
> processors. We need to make sure that all properties are locked during 
> rendering. Or are there properties that could be changed?

One thing is moving an object after creation. Another is "changing a 
previously-defined translate" (that's not currently possible in SDL, and 
it's a bad idea anyway). See my reply to Warp.

Post a reply to this message

Nicolas Alvarez wrote:
> Warp escribió:
>> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>>> sphere.translate[0]="<5,0,0>"
>>
>>> I think it's a bad idea to allow changing individual transformation 
>>> statements after the object has been created.
>>
>>   There's no such a thing as a "translate" element in a sphere (or in
>> any other object for that matter). Thus it would make no sense to have
>> such an element in the sphere object of the new SDL either.
>>
>>   What should exist is a *function* (member or not) which applies the
>> translation to the sphere (which is a different thing). Calling this
>> function will, naturally apply the subsequent translations properly
>> (as well as other transformations).
>>
>>   (In general all transformations are internally collected into a
>> 4x4 transformation matrix, except when the transformation can be
>> optimized away by eg. transforming the center point of the sphere
>> only. However, there exists no "translate" member variable in the
>> sphere object or any other object.)
>>
> 
> Yep, that was my point. Transforming the object further should *of 
> course* be allowed (complex CSG would become fairly impossible without 
> that!), but having all individual transformation "items" stored in an 
> array and being modifiable seems like a bad idea.
> 
> That was what Patrick Elliot said, and I was replying to:
>  > And you want to adjust the "first" rotation.
>  >
>  > body.arm.rotate(0)="<5,0,0>"
>  >
As warp said, at the moment the individual transformations are not 
stored and there is absolutely no reason in POV4 to do so.
And even if there would be an array of transformations, the textures 
(which is your main problem, I think) would get there own array and 
would not get influenced by such after the fact changes.

BTW in POV there is indeed an interaction of transformations and 
textures that comes from the fact that our textures are 3-dimensional.
I have not much experience with other 3D software but it may be one of 
the things that set POV apart from others. I think that in the context 
of POV4 we should think about how 3D textures influence our scenes and 
how they influence our programming language.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Another is "changing a 
> previously-defined translate" (that's not currently possible in SDL, and 
> it's a bad idea anyway).

  Somehow I feel you are a bit talking about apples and oranges here.

  Of course there's no way of "changing a previously defined translate"
because there's no such thing as a "previously defined translate". As I
said in the other post, a translation is not a property of the object,
it's an operation applied to the object (in other words, in object-oriented
terms, a translation is not a member variable of the object, it's a member
function). You either apply it (so that it has some effect) or you don't.
You can't go "back in time" and apply it in a different way once you have
applied it already.

  (Technically speaking you can later apply a new set of transformations
which cancel out the earlier translation, so the effect is the same as if
the earlier translation had not been performed at all, but this is a
rather different thing at a basic conceptual level.)

  I can't really see what is the problem people are seeing here. I don't
see any problem in objects in the new SDL having transformation functions
which work in the same way as in the current SDL.

-- 
                                                          - Warp

Post a reply to this message

Warp escribió:
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Another is "changing a 
>> previously-defined translate" (that's not currently possible in SDL, and 
>> it's a bad idea anyway).
> 
>   Somehow I feel you are a bit talking about apples and oranges here.
> 
>   Of course there's no way of "changing a previously defined translate"
> because there's no such thing as a "previously defined translate". As I
> said in the other post, a translation is not a property of the object,
> it's an operation applied to the object (in other words, in object-oriented
> terms, a translation is not a member variable of the object, it's a member
> function). You either apply it (so that it has some effect) or you don't.
> You can't go "back in time" and apply it in a different way once you have
> applied it already.
> 
>   (Technically speaking you can later apply a new set of transformations
> which cancel out the earlier translation, so the effect is the same as if
> the earlier translation had not been performed at all, but this is a
> rather different thing at a basic conceptual level.)
> 
>   I can't really see what is the problem people are seeing here. I don't
> see any problem in objects in the new SDL having transformation functions
> which work in the same way as in the current SDL.
> 

I was just commenting on Patrick's examples which showed changing 
individual transformations, stored in some sort of array. So we are 
agreeing. The way transformations should work is the way they currently do.

Post a reply to this message

In article <47083c29$1@news.povray.org>, 
nic### [at] gmailisthebestcom says...
> Warp escribió:
> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> sphere.translate[0]="<5,0,0>"
> > 
> >> I think it's a bad idea to allow changing individual transformation 
> >> statements after the object has been created.
> > 
> >   There's no such a thing as a "translate" element in a sphere (or in
> > any other object for that matter). Thus it would make no sense to have
> > such an element in the sphere object of the new SDL either.
> > 
> >   What should exist is a *function* (member or not) which applies the
> > translation to the sphere (which is a different thing). Calling this
> > function will, naturally apply the subsequent translations properly
> > (as well as other transformations).
> > 
> >   (In general all transformations are internally collected into a
> > 4x4 transformation matrix, except when the transformation can be
> > optimized away by eg. transforming the center point of the sphere
> > only. However, there exists no "translate" member variable in the
> > sphere object or any other object.)
> > 
> 
> Yep, that was my point. Transforming the object further should *of 
> course* be allowed (complex CSG would become fairly impossible without 
> that!), but having all individual transformation "items" stored in an 
> array and being modifiable seems like a bad idea.
> 
> That was what Patrick Elliot said, and I was replying to:
>  > And you want to adjust the "first" rotation.
>  >
>  > body.arm.rotate(0)="<5,0,0>"
>  >
> 
Hmm. Ok. That case I hadn't considered. I was thinking in terms of ease 
of identifying the transformation, not in terms of how they interact. 
Its messier to do something like:

body.arm.transform(0)="<5,0,0>"

since you would **have to** know that the "first" transform was the 
rotate, not something else. Short of including, as part of the internal 
data, some concept as to the "order" of the overall operations, so that 
changing the transform would not effect order. Think of it kind of like 
dynamic parsing. Instead of recreating the object in every single frame 
of an animation, you create it once, then *only* adjust those textures, 
transforms, etc. that are *needed* to change, without having to restate 
it all in SDL. Now, you can't do that right now. If you have something 
like:

#declare yy = clock
sphere {...
  translate <yy,35,61>
  texture { some_complex_texture translate 100*x}
  translate y*2}

Then you **must** reparse the object every single time, because once the 
object exists internally, it can't be changed. However, you *must* be 
able to change it, of you want it to do what its supposed to, because 
its *not* the final transform that is being effected, but the one that 
happens prior to the final change. This is especially true if dealing 
with something that has, for example, a complex IK chain system. The 
transforms you need to be able to change are "not" sitting conveniently 
as the last thing in the object, they are buried deep within the 
structure. If we want to be able to animate, without a reparse, we need 
an internal representation that allows "each" transform, texture, 
object, etc. to exist as accessible elements, not as static 
declarations. In other words, you need to make it "look" like:

yy = yy + 1
mysphere.translate(0)=yy,35,61

Even as the engine keeps track of "how" those things connect:

start->translate(0)->texture(0)->translate(1)->end

How else do you both allow animation, without a reparse, but also 
maintain the capacity to place as many transforms, or other elements, 
into the object as you can now? The only other way to do it is by 
forcing someone to "only" allow certain types of transforms, like 
"rotate", "rotate at object coordinate (such as one of its corners, or 
slightly off of center" and "rotate at origin". In other words, you 
either maintain an internal concept of which elements define the object 
and allow those to be changed "independently" by object references, 
**or** you limit the actual transforms to ones that specify distinct 
behaviors, and force someone to use only the one they need, instead of 
letting them make changes to the individual elements defined in the 
original object.

Mind you, there is "one" alternative. Reparse only the bits you need. 
I.e., what the user sees is:

sphere
  |-translate()
  | |-(0) translate blah
  | |-(1) translate blah
  |-texture()
    |-(0) texture data

What the engine sees is:

sphere
  |-translate blah
  |-texture
  | |-data for that
  |-translate blah

So, the next frame, it "reparses" the "engine" version, in its original 
order and associations, to get the new sphere for that frame.

This is sort of what you would have to do, no matter "how" you stored 
things internally, unless, as I said, you allowed "creation" of an 
object using the original SDL syntax, but then required the "script" 
portion to use the more limited set of "allowed" actions, as with the 
rotate example above.

See what I am getting at? If you want to maintain the "existing" SDL, 
you have to allow for this, or suffer the current consequence of having 
to reparse the "entire" SDL every frame. If you avoid doing that, then 
you are still stuck either somehow selectively re-making, based on key 
changes, the internal representation, by basically reparsing it in some 
fashion anyway, or you have to limit what "is" allowed. You can't do 
what is needed with the SDL as it exists, without basically doing the 
same thing anyway, and if you are going to "store" those representations 
and the order they occur, there is no reason to not provide an means to 
look at or even change *what* is stored in those elements. The engine 
"still" has to figure out what those changes "mean" in the next frame, 
in terms of the final result of how the object is effected.

-- 
void main () {
  If Schrödingers_cat is alive  
    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

In article <4709033b@news.povray.org>, 
nic### [at] gmailisthebestcom says...
> Warp escribió:
> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> Another is "changing a 
> >> previously-defined translate" (that's not currently possible in SDL, a
nd 
> >> it's a bad idea anyway).
> > 
> >   Somehow I feel you are a bit talking about apples and oranges here.
> > 
> >   Of course there's no way of "changing a previously defined translate"
> > because there's no such thing as a "previously defined translate". As I
> > said in the other post, a translation is not a property of the object,
> > it's an operation applied to the object (in other words, in object-orie
nted
> > terms, a translation is not a member variable of the object, it's a mem
ber
> > function). You either apply it (so that it has some effect) or you don'
t.
> > You can't go "back in time" and apply it in a different way once you ha
ve
> > applied it already.
> > 
> >   (Technically speaking you can later apply a new set of transformation
s
> > which cancel out the earlier translation, so the effect is the same as 
if
> > the earlier translation had not been performed at all, but this is a
> > rather different thing at a basic conceptual level.)
> > 
> >   I can't really see what is the problem people are seeing here. I don'
t
> > see any problem in objects in the new SDL having transformation functio
ns
> > which work in the same way as in the current SDL.
> > 
> 
> I was just commenting on Patrick's examples which showed changing 
> individual transformations, stored in some sort of array. So we are 
> agreeing. The way transformations should work is the way they currently d
o.
> 
And I don't think you have *at all* addressed what I was getting at. How 
do you do something like IK, without either a) allowing an object like 
reference system *which keeps track of* which order the transforms took 
place in, such that if you move something, then rotate it, you don't 
want to later just rotate it, and assume its going to produce the same 
result, or b) limiting the types of transforms that *are* possible to an 
already parsed object, or c) reparsing every damn thing in the script, 
so you can recalculate just what the heck the object is described doing 
*in that frame*? I would be 100% fine with an explanation for how to 
keep things as they are, or provide those transforms in a way that still 
allows handling the objects in a way that lets you make adjustments 
between frames, without having the reparse the entire file (which can 
sometimes take up 100 times as much time as producing the final image). 
I just don't see how you do that. The existing system parses the objects 
into a *static* internal layout, which you can't change anything on. Any 
changes have to be done "during" the parsing. Once the object exists, 
the only thing you can do is dump it from memory, and start over, by 
reparsing the entire thing again, with new data. That you can calculate 
what that data is in the SDL, doesn't change the basic nature of what 
you end up with. And that is **not** something useful, or practical, for 
anything but single frames.

So, what is the answer? Just figure that speed for the parser is 
impossible to solve, so who gives a frack, lets just leave it slow and 
reparse 100% of the file every frame? Or do we get our heads out of the 
sand and either realize that there is no solution that works in the 
"existing" framework, which can allow this, or that, if we do find a 
way, we need to provide a sane and flexible way to solve it, not some 
method that basically does nothing but impose the "same" problems on the 
new system as we have already? It just doesn't make sense to me to have 
transforms work the same as now, when the reason they are a problem 
*now* isn't going to change if you plan to speed up parsing, or improve 
the ability to animate through the SDL.

I am even more bloody confused by the fact that I stated a clear 
alternative. Allow the internal representation work **exactly** as it 
does now, at least in terms of how such objects are handled in each 
frame, but parsing it from a *binary* representation, not the original 
text. Create the original using text, sure, but keep it internally as 
binary, so you can change it between frames, without the cost of having 
to reparse the entire damn file. Then **allow** someone that wants to 
access, through a more object oriented system, to change anything they 
like in that "binary" copy. Don't reparse 10,000 lines of code if the 
**only** thing you need to do is change one bloody transform in an 
already parsed object.

And more to the point, please, give me some good idea how the hell you 
allow that, in any way that doesn't require a 10,000 line reparse, 
without resorting to something at least "similar" to what I suggested?

Sorry for being a bit snippy, but bloody hell, why are we even 
discussing how the SDL works and what problems it currently has, (which 
can make it so damn slow in some cases), if all we are going to do is 
go, "Ah, well... I don't like how that might change the syntax, so lets 
just pretend keeping things as is isn't going to be (or perpetuate) any 
kind of problems/limitations."

-- 
void main () {
  If Schrödingers_cat is alive  
    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

In article <4709033b@news.povray.org>, 
nic### [at] gmailisthebestcom says...
> Warp escribió:
> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> Another is "changing a 
> >> previously-defined translate" (that's not currently possible in SDL, a
nd 
> >> it's a bad idea anyway).
> > 
> >   Somehow I feel you are a bit talking about apples and oranges here.
> > 
> >   Of course there's no way of "changing a previously defined translate"
> > because there's no such thing as a "previously defined translate". As I
> > said in the other post, a translation is not a property of the object,
> > it's an operation applied to the object (in other words, in object-orie
nted
> > terms, a translation is not a member variable of the object, it's a mem
ber
> > function). You either apply it (so that it has some effect) or you don'
t.
> > You can't go "back in time" and apply it in a different way once you ha
ve
> > applied it already.
> > 
> >   (Technically speaking you can later apply a new set of transformation
s
> > which cancel out the earlier translation, so the effect is the same as 
if
> > the earlier translation had not been performed at all, but this is a
> > rather different thing at a basic conceptual level.)
> > 
> >   I can't really see what is the problem people are seeing here. I don'
t
> > see any problem in objects in the new SDL having transformation functio
ns
> > which work in the same way as in the current SDL.
> > 
> 
> I was just commenting on Patrick's examples which showed changing 
> individual transformations, stored in some sort of array. So we are 
> agreeing. The way transformations should work is the way they currently d
o.
> 
Sigh. Ok, you might not have read the post I made later. Seems it got 
caught in the damn outbox of the usenet client I use, which won't bloody 
send until after it "rechecks" all the groups on a server. Sometimes I 
hate this program, but given I have yet to find one that acts close to 
the same and didn't have even more irritating issues...

-- 
void main () {
  If Schrödingers_cat is alive  
    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

Concerning the animation problem, I see things as follows:

Solution 1:
-----------
The nth frame I(n) of an animation is a function of time only. Its
description depends on the sole time parameter. Then you can conceptually
write:

I(n) = F(tn), with F being the function that describes the scene at time tn.

This is POV's point of view, through the 'clock' variable and reparsing the
whole scene (except radiosity and photon maps if so specified).

This solution requires only the description of the F(t) function.

Solution 2:
-----------
The nth frame I(n) is made by delta wrt first frame. Its description relies
on the description of first frame at t0 and a delta function that depends
on the time parameter. Then you can conceptually write:

I(n) = I(0) + D(tn), with D being the function that describes the variation
of the scene between tn and t0.

This solution requires the decription of I(0) and the D(t) function.

Solution 3:
-----------
The nth frame I(n) is made by delta wrt previous frame. Its description
relies on that of the previous frame I(n-1) and a delta function that
depends on the two instants tn and tn-1. Then you can conceptually write:

I(n) = G(I(n-1)) = I(n) + d(tn, tn-1), with d being the function that
describes the variation of the scene between tn and tn-1.

This solution requires the description of I(0) and d(t1, t2) function.


Each of these solution is a different approach with pros and cons and
implies related features and syntax.

Concerning POV4, which of these is preferable?



Bruno

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> If you have something like:

> #declare yy = clock
> sphere {...
>   translate <yy,35,61>
>   texture { some_complex_texture translate 100*x}
>   translate y*2}

> Then you **must** reparse the object every single time, because once the 
> object exists internally, it can't be changed.

  Wrong.

  The object has its own transformation matrix and the texture its own.
All transformations applied to the object go to its transformation matrix,
and all transformations applied to the texture (be it directly in the
texture block or indirectly in the object block) go to the transformation
matrix of the texture.
  It would be perfectly possible to alter these two transformation matrices
afterwards. It's simply a question of which transformations are applied to
the object only, which ones to the texture only and which ones to both.

> The 
> transforms you need to be able to change are "not" sitting conveniently 
> as the last thing in the object, they are buried deep within the 
> structure.

  You seem to have this concept that the transformations are somehow
stored in the definition of the object, and that this order must be
preserved.

  The individual transformations are not stored anywhere. Each transformation
is simply a command (a kind of "function call" if you like) which modifies
the internal transformation matrix of the object.

  It would be perfectly possible, after the object has been created (with
the transformations and all), to reset its transformation matrix and then
apply the same transformations to it, resulting in the exact same end
result. The only distinction you have to make is which transformations
go to the object, which ones to the texture and which ones to both.

> If we want to be able to animate, without a reparse, we need 
> an internal representation that allows "each" transform, texture, 
> object, etc. to exist as accessible elements, not as static 
> declarations.

  No we don't.

> In other words, you need to make it "look" like:

> yy = yy + 1
> mysphere.translate(0)=yy,35,61

> Even as the engine keeps track of "how" those things connect:

> start->translate(0)->texture(0)->translate(1)->end

  The engine doesn't need to keep track of that. You should acquaint
yourself with transformation matrices and how they work.

> How else do you both allow animation, without a reparse, but also 
> maintain the capacity to place as many transforms, or other elements, 
> into the object as you can now?

  You can write a thousands individual transformations into an object,
yet none of them will be (individually) stored anywhere. They are all
applied to one single 4x4 transformation matrix. POV-Ray doesn't need
to keep track of the individual transformations nor store them anywhere.

  The only thing you need to specify is whether a certain transformation
is applied to the object, to the texture, or both.

> See what I am getting at? If you want to maintain the "existing" SDL, 
> you have to allow for this, or suffer the current consequence of having 
> to reparse the "entire" SDL every frame.

  That's just not true. The only thing you have to allow in the new SDL
is to be able to apply transformations to the object only, the texture
only or both at the same time. This is very trivial to do.
  It's perfectly possible to transform the object but not the texture
even after the texture has been specified.

-- 
                                                          - Warp

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> And I don't think you have *at all* addressed what I was getting at. How 
> do you do something like IK, without either a) allowing an object like 
> reference system *which keeps track of* which order the transforms took 
> place in, such that if you move something, then rotate it, you don't 
> want to later just rotate it, and assume its going to produce the same 
> result, or b) limiting the types of transforms that *are* possible to an 
> already parsed object, or c) reparsing every damn thing in the script, 
> so you can recalculate just what the heck the object is described doing 
> *in that frame*?

  You don't need to reparse the entire object if you simply want to apply
some new transformations to it. What you do is to reset its transformation
matrix and apply the new transformations to it. That's it.

  If what you are doing requires remembering and applying a set of
transformations in order, you can simply create an array or whatever
with these transformations, or whatever you like. However, that's
completely irrelevant from the point of view of the object itself.

  The only thing you have to be able to specify is whether a transformation
is applied to the object only, the texture only, or both.

  You don't seem to understand how transformations work.

-- 
                                                          - Warp

Post a reply to this message