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

Bruno Cabasson wrote:
> 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?
> 
none or all

Post a reply to this message

In article <4709fb43@news.povray.org>, war### [at] tagpovrayorg says...
> 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 th
e 
> > 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 matric
es
> afterwards. It's simply a question of which transformations are applied t
o
> 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 transforma
tion
> is simply a command (a kind of "function call" if you like) which modifie
s
> 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.
> 
> 
Sigh.. You are I think making an assumption that, when you do want to 
change something, you would only want to change "one" transform. But, 
maybe you have a dozen, each with does something specific to positioning 
the object, each of which is "also" effected by all of the prior 
transforms. Tell me, with a real example, not just some assertion that I 
am imagining a problem, how you do that. Yes, you can use some commands 
that can revert the object to a known state, like at the origin, then 
transform it, but that is useless if the transform you need is relative 
to some arbitrary point, which is the result of 3-4 other prior 
transforms. How do you, if you are doing say 7 translates, for some odd 
reason, revert back to the 3rd, change the 4th, then reapply the last 3? 
You can't, without drastically altering how you handled those transforms 
in the first place, and reducing them to a bare minimum number needed to 
do the task. Sure, it might be possible, but it still breaks, as near as 
I can tell, when you try to provide a post-creation transform on the 
object, to modify the prior result. Show me that I am wrong, don't just 
tell me I am.

-- 
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 <4709fc49@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > And I don't think you have *at all* addressed what I was getting at. Ho
w 
> > 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 a
n 
> > 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 transformatio
n
> 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 transformati
on
> is applied to the object only, the texture only, or both.
> 
>   You don't seem to understand how transformations work.
> 
I know damn well how they work. And you don't solve the problem by 
reverting things. How do you revert **only** to the Nth transform so 
that you change only that one? You are assuming, I think wrongly, that 
no combination of transforms can produce a situation where the result 
cannot be reset, then some arbitrary transform reapplied to make the one 
change needed. Worse, your assertion that all you need to do, if it is a 
problem, is keep every transform in some sort of array, then reapply 
them from that, is... What they frack do you think I have been saying? 
The only difference between your array and mine is that I separate 
"types" of transforms so you don't have to remember if the second 
translate is the 6th transform in the array, not the 5th. The point is 
to still track those transforms in an array of some type, so they can be 
reapplied, *if* you have to manage them that way. Your, "just make some 
separate transform array", just obfuscates what is going on, by 
separating the transforms from the object they effect, when they should, 
logically be considered "part" of the final object (especially if its a 
compound object and things like "how" the texture is applied is changed 
dependent on the position of those sub-objects in some way, as a result 
of those transforms).

I think you are badly missing my point, both in terms of what I mean and 
how any such system would end up looking from a user standpoint.

-- 
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 wrote:
> In article <4709fb43@news.povray.org>, war### [at] tagpovrayorg says...
>> 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.
>>
>>
> Sigh.. You are I think making an assumption that, when you do want to 
> change something, you would only want to change "one" transform. But, 
> maybe you have a dozen, each with does something specific to positioning 
> the object, each of which is "also" effected by all of the prior 
> transforms. Tell me, with a real example, not just some assertion that I 
> am imagining a problem, how you do that. Yes, you can use some commands 
> that can revert the object to a known state, like at the origin, then 
> transform it, but that is useless if the transform you need is relative 
> to some arbitrary point, which is the result of 3-4 other prior 
> transforms. How do you, if you are doing say 7 translates, for some odd 
> reason, revert back to the 3rd, change the 4th, then reapply the last 3? 
> You can't, without drastically altering how you handled those transforms 
> in the first place, and reducing them to a bare minimum number needed to 
> do the task. Sure, it might be possible, but it still breaks, as near as 
> I can tell, when you try to provide a post-creation transform on the 
> object, to modify the prior result. Show me that I am wrong, don't just 
> tell me I am.
> 
I don't want interfere in your personal fight, but I think this is what 
is going to happen:
- POV4 transformations will be implemented the same as in current POV, 
one transformation matrix per object, texture.
- The language will be enhanced and the processing of it changed in such 
a way that retransforming one or more specific elements will become an 
issue. e.g. in generating the next frame of a complicated object without 
reparsing the lot.
- it'll be up to the user to implement a stack of transformations if he 
thinks he needs one. Reverting to a marked state and replaying the 
changed set of transformations from that point.
- luckily the language will be enhanced in such a way that such an 
implementation is easy.

Also before fighting on, you should first define what you mean by 
creation/post creation etc. I think you have a different view on when an 
object is actually created. Is that e.g at the end of the union defining 
it (Patrick?) or at the end of parsing (warp?).
If you assume the latter (which happens to be my point of view) post 
creation transforms do not exist, by definition. BTW I think the time of 
definition of the shape also needs a name (birth? though you will be 
able to clone after birth... conception?), because it is a significant 
moment in the life of that object. I predict that it'll come up in 
discussions about POV4 frequently.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Bruno Cabasson wrote:
> > 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?
> >
> none or all

What do you mean exactly? I don't get your point ...

POV has currently solution 1. Solution 2 appears in modelers by attaching
timelines to objects (is it be what we want for POV4?). What I have
understood in the discussion is that it would be preferable to have
something else than reparsing the scene. I made this quick analysis that
yields to 3 solutions. I think a unique solution must be chosen (among the
above 3 or others, please suggest ...). How could several approaches
co-exist without complicating the langage?

I believe that the new syntax must be close to the current, with somme OO
aspects (modules, inheritance, dot operator etc ...), with some higher
level object types (I put it as it comes):

cloudscape, vegetation, human and non human characters, clothing, particle
system, etc ... to be defined ... Please suggest!

And with new features:

sub-surface scattering, shader language (basic, medium, advanced? what would
it need and look like?), mesh-editing features (basic, medium, advanced?),
IK for characters, user-friendly math/geom programming tools (thanks to
gurus), etc ...

If we can achieve to define a language that keeps POV's SDL spirit, with the
nice new features you all talk about, it could be a high level
programming/scripting language for scene designers, as well as an interface
language for 3rd party tools.

POV's new GUI would be a shipped-with and integrated, with handy features,
for example:

text-editing (of course), basic/medium/advanced pre-visualization of shapes,
objects, textures etc ..., animation handling and previsualization,
spline/path editor, color editor, basic/medium mesh editor, proess control
.... etc ...


Bruno

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Patrick Elliott wrote:
> I don't want interfere in your personal fight, but I think this is what
> is going to happen:
> - POV4 transformations will be implemented the same as in current POV,
> one transformation matrix per object, texture.
> - The language will be enhanced and the processing of it changed in such
> a way that retransforming one or more specific elements will become an
> issue. e.g. in generating the next frame of a complicated object without
> reparsing the lot.

It is the Frame(n) = Frame(0) + Delta(tn) scheme, with Frame(0) representing
most of the parsing (initial conditions of the scene, building of objects
....), and Delta(tn) the variation of the scene since first frame. The
function Delta() can be expressed (and syntaxted) as timelines attached to
objects, handled by a corresponding control process. These time lines would
then embody the memory of the transformations to apply through time (the
'array' of transformations in question in the next paragraph)

> - it'll be up to the user to implement a stack of transformations if he
> thinks he needs one. Reverting to a marked state and replaying the
> changed set of transformations from that point.
> - luckily the language will be enhanced in such a way that such an
> implementation is easy.

I think that leaving the responsability to handle these stacks of
transformations to the programmer is dangerous and requires too much
programming skills wrt the goal we intend to reach in terms of programming
ease and accessibility. In the scheme I described, only the control process
of timelines can do the job and guarantees sensible operations.

> Also before fighting on, you should first define what you mean by
> creation/post creation etc. I think you have a different view on when an
> object is actually created. Is that e.g at the end of the union defining
> it (Patrick?) or at the end of parsing (warp?).
> If you assume the latter (which happens to be my point of view) post
> creation transforms do not exist, by definition.

My point of view is that within a single frame, all transforms should be
defined at creation time, and post creation transforms should be forbidden,
unless controlled by the timelines attached to the objects and their control
process within aniations (and in this sole case).


> ... BTW I think the time of
> definition of the shape also needs a name (birth? though you will be
> able to clone after birth... conception?), because it is a significant
> moment in the life of that object. I predict that it'll come up in
> discussions about POV4 frequently.

As we try to make POV have some OO aspects, I'd rather be inclined to keep
the term of 'creation'.


Bruno

Post a reply to this message

Bruno Cabasson wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Bruno Cabasson wrote:
>>> 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?
>>>
>> none or all
> 
> What do you mean exactly? I don't get your point ...

simply that if at frame n you want to position and transform an object 
you will be allowed to access the state in frame n-1, so you can 
transform incremental (3). You can also reset the transformation 
variables and start from there (1) or first revert to a known situation 
either because POV4 gets a mechanism to make a snapshot or because 
somebody will write a function (formerly a #macro) to do so.

So all will be possible and none will be preferable. It depends on the 
application which one is more natural and if you use a GUI you won't 
even know.

> 
> POV has currently solution 1. 
no, it reparses the scene for every frame.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Bruno Cabasson wrote:
> > andrel <a_l### [at] hotmailcom> wrote:
> >> Bruno Cabasson wrote:
> >>> 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?
> >>>
> >> none or all
> >
> > What do you mean exactly? I don't get your point ...
>
> simply that if at frame n you want to position and transform an object
> you will be allowed to access the state in frame n-1, so you can
> transform incremental (3). You can also reset the transformation
> variables and start from there (1) or first revert to a known situation
> either because POV4 gets a mechanism to make a snapshot or because
> somebody will write a function (formerly a #macro) to do so.
>
> So all will be possible and none will be preferable. It depends on the
> application which one is more natural and if you use a GUI you won't
> even know.

OK, but I'm still not sure I get you. You seem to suggest that POV4 should
implement all 3 approaches for convenience reasons, and that they are
equivalent wrt this. But would not implementing all 3 (or more) solutions
yield too a voluminous syntax and wouldn't it be somewhat confusing to the
user instead of being more convenient? And POV4 would have to implement
all, which means more development effort.

BTW, considering the problem of POV4's development: who will? What is the
manpower and skills available today? We have POV-team and perhaps
volunteers around here. But it is quite a long-term commitment. Would
POV-team members be likeley to? Such a developmement requires a good
implusion at the start AND perennial manpower AND a team developmement
process. To my understanding (and whish), POV4 cannot be a hack. It
requires an 'industrial' process, whether or not it is open-sourced.
Anyway, I don't worry about the testing power ...

>
> >
> > POV has currently solution 1.
> no, it reparses the scene for every frame.

This is precisely what I(n) = F(tn) means: every frame is a function of the
sole time parameter through the clock variable. Solution 1 means therfore
that the scene is reparsed every frame, all stuff of the scene is re-build
from scratch and from the clock variable or its derived variables such as
frame_number. They all represent an 'absolute' time.


Bruno

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> Sigh.. You are I think making an assumption that, when you do want to 
> change something, you would only want to change "one" transform. But, 
> maybe you have a dozen, each with does something specific to positioning 
> the object, each of which is "also" effected by all of the prior 
> transforms. Tell me, with a real example, not just some assertion that I 
> am imagining a problem, how you do that.

  I don't really understand why you are seeing so many problems where
there is none.

  You have a created object. This object has been created at the beginning
of the animation and will stay as it is, in memory, during the entire
animation. It will not be reparsed nor recreated at each frame.

  What you do at each frame, however, is to apply certain transformations
(which depend on the clock, etc) to this object. I just can't see what is
the problem you are seeing there.

  For example, it could be like this, executed at each frame:

theObject.transformation.reset();
theObject.translate(1, 2, 3);
theObject.translate(4, 5, 6);
theObject.translate(.5*clock, .6*clock, .7*clock);
theObject.translate(10, 11, 12);

  Or anything else, for that matter (ie. it doesn't *necessarily* have to
start with a reset of the transformation matrix, but it may in most cases
be the easiest way).

  If you really want to have the transformations in an array, well,
you *can* create such an array if you want to. Just create the array,
and at each frame modify the elements of the array you want, and then
apply the transformations in the array to the object in a loop, and
that's it. That will be exactly what you want, without having to put
an odd transformation array kludge in the object itself.

> Yes, you can use some commands 
> that can revert the object to a known state, like at the origin, then 
> transform it, but that is useless if the transform you need is relative 
> to some arbitrary point, which is the result of 3-4 other prior 
> transforms.

  1) There's no need to revert transformations.

  2) Even if there was, it *is* actually possible to revert transformations
regardless of how they depend on prior transformations and whatnot. Just
acquaint yourself with the subject.

> How do you, if you are doing say 7 translates, for some odd 
> reason, revert back to the 3rd, change the 4th, then reapply the last 3? 
> You can't

  I already showed that you can.

> Sure, it might be possible, but it still breaks, as near as 
> I can tell, when you try to provide a post-creation transform on the 
> object, to modify the prior result. Show me that I am wrong, don't just 
> tell me I am.

  You clearly don't understand how transformations work, and you are having
a big misconception about how transformations should be applied to objects
in this case.

-- 
                                                          - Warp

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> - it'll be up to the user to implement a stack of transformations if he 
> thinks he needs one. Reverting to a marked state and replaying the 
> changed set of transformations from that point.

  There's no need for any stack nor the need for reverting if you simply
apply a group of transformation commands to the object at each frame.

  It's basically not any different from how POV-Ray currently does it,
except that it's not necessary to reparse and recreate the object at
each frame. (In theory this wouldn't be necessary in the current POV-Ray
either, except that the current SDL format makes it quite difficult to
do it otherwise. A simple format enhancement would remove the limitation.)

> If you assume the latter (which happens to be my point of view) post 
> creation transforms do not exist, by definition.

  I don't really understand what you are saying there.

  I don't see any problem in taking an existing object and apply more
transformations to it, or even resetting its transformations and applying
new ones.

-- 
                                                          - Warp

Post a reply to this message