In article <471### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> Patrick Elliott wrote:
> > In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
> > says...
> >> Patrick Elliott wrote:
> >>> In article <470### [at] hotmailcom>, a_l### [at] hotmailcom
 
> >>> says...
> >>>> What I was saying is that we should distinguish between the 'first
 
> >>>> creation' and the 'final creation'. Calling both simply 'creation' w
ill 
> >>>>   lead to confusion (as shown is this thread. Much of what you and
 
> >>>> Patrck are writing does not make sense to me, because for me 'creati
on' 
> >>>> is 'final creation').
> >>>>
> >>> How about "intermediary" creations then, just to confuse things more.
 
> >>> lol Technically, by your definition, the object is never "created" un
til 
> >>> the frame in rendered, at least in any system like we are talking abo
ut, 
> >>> where each "frame" is defined not by re-running the entire script, bu
t 
> >>> only via the command "in" the script.
> >>>
> >>> In other words, in the current model we do this:
> >>>
> >>> render("myfile")
> >>>
> >>> in a true animation system, we do this:
> >>>
> >>> 'Set up a bunch of objects.
> >>> ...
> >>> render
> >>> 'Change the objects some.
> >>> ...
> >>> render
> >>> 'Change them some more.
> >>> ...
> >>> render
> >>>
> >>> The "render" step is explicit in the script, since it only happens 
> >>> "when" all the changes are made, not an external process that just ru
ns 
> >>> an SDL through it, and recalcs the data for everything as it does it,
 
> >>> based on the existing clock scheme, which is kind of limited. Mind yo
u, 
> >>> making that change, depending on how it was done, could break existin
g 
> >>> SDL. Mind you, a command that "requests" the prior behavior could be
 
> >>> used to solve that. 
> >> You could also assume that a render command is implicit at the end of
 
> >> parsing if none is given.
> >>
> > Yes, I had considered that, but its better to have a compatibility flag
, 
> > both so that someone doesn't try to run an old SDL, then wonder why it
 
> > didn't work right, and so that someone using a *new* SDL could be warne
d 
> > that they forgot to actually render anything. Its kind of a toss up 
> > though.
> > 
> There could be a problem with a compatibility flag if someone is 
> including some old code. Then again the #version 3.6; compatibility flag
 
> never gave problems. Actually, as you might have noticed, I would prefer
 
> a 'camera(Scene)' kind of syntax in stead of a 'render' command for many
 
> reasons (some not even mentioned anywhere yet). Which points more to a 
> compatibility flag than an implicit 'render' command.
> 
Only problem I could see with that is that someone may want to use 
multiple cameras, like say... stereoscopic effects. I mean, its not 
totally absurd to consider someone wanting to either a) render bath eyes 
at the same time, if they have the speed and the language allowed it, or 
even doing something crazier, like having a camera that "looks" at some 
other location, which is used as part of the image some place else. A 
good example would be something like a security booth. You have a 
monitor on the desk, which shows a kind of post process "filtered" 
effect in black and white, of what is "seen" by a camera that is also 
*visible* in the larger scene, but in color, as is most of the rest of 
what is in the camera view.

Yeah, I know, you can do two renders, one from the camera view, then 
post process that, then use the result as an image map on the monitor, 
but is is just an example. Its possible that someone could have a scene 
where this was either seriously impractical, or completely impossible, 
unless the "camera view" was being produced in the same render as the 
final image. Then again, what do I know. lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message