POV-Ray : Newsgroups : povray.general : Status of Moray? Server Time
23 Jul 2025 17:15:53 EDT (-0400)
  Status of Moray? (Message 361 to 370 of 466)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Bruno Cabasson
Subject: Re: New SDL for POVRay
Date: 8 Oct 2007 19:50:00
Message: <web.470ac157e7dc742876e65db0@news.povray.org>
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

From: Bruno Cabasson
Subject: Re: New SDL for POVRay
Date: 8 Oct 2007 20:40:01
Message: <web.470acd7be7dc742876e65db0@news.povray.org>
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

From: andrel
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 03:40:55
Message: <470B3189.3040000@hotmail.com>
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

From: Bruno Cabasson
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 04:40:00
Message: <web.470b3d59e7dc7428e8ba46670@news.povray.org>
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

From: Warp
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 05:38:20
Message: <470b4c0c@news.povray.org>
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

From: Warp
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 05:43:41
Message: <470b4d4d@news.povray.org>
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

From: Warp
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 05:55:34
Message: <470b5016@news.povray.org>
Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> 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.

  There's no more skill involved than in the current POV-Ray when you apply
a series of transformations to an object.
  There's no need for a stack. There's no need to revert transformations.
You simply apply a series of transformations to the object at each frame
(basically what you do with the current SDL, but without having to reparse
the object).

  I really can't understand what is the problem people are seeing here.
Could someone please explain to me this?

  Is it that some people seem to think that once you have applied a
texture to the object you can't transform the object without transforming
the texture too? Says who? Just because you can't do it in the current SDL
that doesn't mean it wouldn't be possible in the new one. Even in the
current SDL it's just a *syntactical* limitation. There's absolutely no
technical reason why there couldn't be a command like "apply this
transformation to the object but not its texture". It would simply be
a question of adding the proper syntax for it.

  Seemingly some people also think that if a transformation has been
applied, it's engraved in stone and cannot be removed anymore. Removing
all the transformations is just a question of resetting the transformation
matrix. Then you can re-apply all the transformations you want to the
object, making the modifications you want.

  (Granted, in the current POV-Ray implementation this would require a
bit more of work because certain transformations to certain objects are
"optimized away", for example by applying the transformation to some
object coordinate instead of applying it to the transformation matrix.
Thus such a transformation would indeed by "engraved in stone" and not
possible to revert.
  However, it's perfectly possible to change this system without removing
these optimizations. It's possible to apply all the transformations to
the transformation matrix of the object and then, after all the
transformations have been applied, just before starting the rendering,
it's possible to examine the transformation matrix for certain properties
and if these properties exist, they can be "optimized away" in the same
way as currently. For example, if the object is a sphere there exists a
translation component, the translation can be applied to the center
coordinate of the sphere and removed from the transformation matrix.)

> 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

  Why impose such an artificial limitation? It doesn't make any sense.

-- 
                                                          - Warp


Post a reply to this message

From: Warp
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 06:06:03
Message: <470b528a@news.povray.org>
Patrick Elliott <sel### [at] rraznet> wrote:
> I know damn well how they work.

  In that case you are doing a pretty good job at hiding it.

> And you don't solve the problem by 
> reverting things.

  By "reverting" I mean resetting the transformation matrix and applying
the transformations again (with possible changes). Exactly as the current
POV-Ray does, but without the need to reparse the object.
  I really can't see the problem you are having with this.

> How do you revert **only** to the Nth transform so 
> that you change only that one?

  By changing only the Nth transformation you apply to the object? What is
the problem you are seeing here?

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

  You mean that it's possible to apply certain transformations to a
transformation matrix in a way that the transformation matrix cannot
be reset anymore? Now that would be a rather interesting thing to see.

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

  I didn't say that. What I said is that if you *want* to keep the
transformations in an array, you *can*. However, you don't *have to*.
It makes no sense to force such an array to exist when there is no
need for one.

> What they frack do you think I have been saying? 

  What you have been saying is that every object should have an inner
array of transformations.
  This proposition makes no sense. It makes things needlessly complicated
and, worse, *hard-codes* one possible solution.

  The easiest solution is to *not* have any such array in the object,
but at each frame you simply apply a set of transformations to the object,
exactly as you do with the current POV-Ray, but without the need to
reparse the object. I gave a small example in a previous post.

  What you *can* do if you *want*, for whatever reason, is to have the
transformations in an array and then apply them in a loop to the object.

> 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

  No, it's *your* solution which is obfuscating things, by forcing the
user to use some kind of array when there isn't a need for one.

  The current POV-Ray SDL doesn't need any transformation arrays, nor does
the new SDL.

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

  I think that it's you who is confused about how transformations can and
should be applied to objects. Your array idea is just bad.

-- 
                                                          - Warp


Post a reply to this message

From: Bruno Cabasson
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 07:15:00
Message: <web.470b6269e7dc7428e8ba46670@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:

> > 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
>
>   Why impose such an artificial limitation? It doesn't make any sense.
>
> --
>                                                           - Warp

I agree there is no technical limitation. But I can see drawbacks. In the
current syntax, we write

#declare my_sphere = sphere
{
   0, 1
   pigment {White}
   translate <1,2,3>
}
..../...
trace (my_sphere, ...)

Once the sphere has been created (= after the ending '}' of the syntactical
block), the sphere stays how it is and we have no mean to apply a new
transform to it afterwards. The only way I see to fake this is to create a
new object and transform it:

#declare my_sphere_2 = object {my_sphere translate <4,5,6>}

But the first sphere remains present (even if it had no_image, no_shadow
....).


The new syntax might allow such code:

my_sphere = sphere
{
   0, 1
   pigment {White}
   translate <1,2,3>
}
..../...

my_sphere.translate y;

trace (my_sphere, ...)

And you get what you want, for animations for example, provided you are
programmatically skilled enough to keep track of your objects and what
happens to them.

My opinion (I'd rather say my 'intuition', but may change, I am not that
proud of myself) is that if you perform transformations in different
locations in the code, perhaps out of the scope of the current source file,
you can never be sure for the current object's situation, and therefore for
the end result.

I agree that, with current syntax, you can store transforms in an array,
access this array through the clock or frame_number variable. But I find
this not very handy. I would prefer a build-in mechanism for animations
with relevant syntax. For example, if we attach timelines to objects, we
could write (I put it as it comes to my mind, I am trying ...):

DURATION = 25;

ejection = timeline (direction:vector)  // could be 'animate' keyword
{
    function
    {
        <parabolic trajectory equation>
        return <computed transform>
    }
}

stone
{
    0, 1
    roundness 0.3
    random 123.456
    pigment
    {
        timeline
        {
            [0 agate turbulence 0.3 color_map{CM_LAVA_HOT}] // t<=0
            [2 granite turbulence 0.3 color_map{CM_LAVA_SEMI_HOT}] // t=2
            [5 agate turbulence 0.3 color_map{CM_VOLCANIC}] // t=5
            cycle 3 // restart at t=3 for t>5*n
            interpolate 2
        }
    }

    transform
    {
        translate {CRATER_POS}
        timeline {ejection (DURATION)}
    }
}

And POV4 does the job. And 3rd party tools could easyly generate code for
anims.

Bruno.


Post a reply to this message

From: Fa3ien
Subject: Re: New SDL for POVRay
Date: 9 Oct 2007 12:22:11
Message: <470baab3$1@news.povray.org>


>   (Granted, in the current POV-Ray implementation this would require a
> bit more of work because certain transformations to certain objects are
> "optimized away", for example by applying the transformation to some
> object coordinate instead of applying it to the transformation matrix.
> Thus such a transformation would indeed by "engraved in stone" and not
> possible to revert.

Just curious : I wasn't aware of that kind of optimizations (I thought
that everything was done by matrix, as the docs states).  Does it really
makes a difference in speed ?  After all, so few objects are concerned
(sphere, cylinder, what else ?), and it's useless as soon as an non-uniform
scale is applied...

Fabien.


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.