 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4710ec81$1@news.povray.org>, dne### [at] san rrcom says...
> Patrick Elliott wrote:
> > Gah!! This is exactly what I am talking about. And everyone else is
> > instead saying, "Gosh, this is silly, why not just store every single
> > transform some place else, so it takes up even more memory, then apply
> > them all over again anyway, not from the history, but from a bunch of
> > arrays?" Feel like I am talking to a wall here.
>
> Honestly, you're not being very clear about why you think your method is
> superior. You might have something, but without transferring the ideas
> from your head to the keyboard, it's difficult to see why your mechanism
> is better.
>
Point taken. I hope the other posts I have made today clear some of it
up. I don't think, strictly speaking, a history makes much sense myself,
but its similar to what I have been saying. As Warp points out, what I
am talking about is semantically no different than what he has said, in
most cases, but as I said in those posts, the issue isn't semantic, its
associative. Objects don't "usually", when they track some internal set
of data, rely on purely external sources for storing it, simply because
that disassociates the data from the object that uses it. Not a horrible
problem, but its also not semantically different to have some method to
"copy" the transforms from one object to another, if you wanted to. It
probably won't make a lick of sense to do so, unless they are themselves
just copies of the same object, but its hardly a huge difference between
doing:
ginger.copytransforms(fred)
vs.
ginger.applytrandforms(arbitrary_table)
The first one though is "associatively" clearer, even if its
semantically the same. And, even if you wanted to do that, there hasn't
exactly been a discussion on how you a) structure such a table, or b)
get one out of, or into, an POVRay object that has subobjects. Mostly,
its fairly irrelevant, until you figure out what the heck the internals
are going to look like, or even if there are going to be any, other than
just a static matrices (its kind of hard to have a non-static one, since
doing so puts you right back at recording no just "what" the result is,
but how you got it, so you can backtrack to a prior state). The only
point you can "revert" to, without knowing that, is the one that existed
when you first did some_object(<location>,size(s)) Hardly helpful, if
you are trying to avoid having to redundantly store "every" change
needed to get from there to the final result.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> 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
So which is better:
A) Letting the users simply render two sets of images, with one being
used as a texture in another; this is very easy, requiring only two
scenes that are almost identical (the camera is positioned differently
in the camera view), or
B) Writing the renderer so that a texture can be based on the camera
view (with rays being traced, anti-aliased, usw...) of another place in
the scene.
We already have A up and running just fine. I use it all the time.
Leaving out the trouble of render-wrangling a second set of images
(i.e., putting them in a different directory after rendering), A is no
more work than B for the user; the camera still has to be positioned and
test-rendered for either method.
B will require work from programmers who are already busy with stuff
that can't be pushed off onto the user, or if they can be, only at the
expense of significantly reducing the user's productivity. It also
increases the size of the renderer, in order to provide the extra feature.
Now if the memory situation is very tight, then method B does have the
advantage that the texture does not need to be stored in memory; but in
almost every case of this kind the video image occupies less than a
quarter of the final view, which means that the texture requires only
one-quarter of the memory of the rendered image. If your memory
situation is that tight, maybe you need to get some more RAM.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> Using an array of transforms would be wastefull. It would uselessly use
> extra memory. It would make rendering slow as the whole array will need
> to be computed for every ray that encounter the object, as well as any
> CSG operation that use that object. That array will need to be dynamic
> as you can never tell beforehand how many transforms will be applyed to
> any particular object, adding some useless overhead, and requiring still
> more memory.
One reason you would need more then one forward or reverse transform
during rendering is if the renderer were to support motion blur. One
transform stipulates the start-of-frame positioning of the object, and
the other stipulates the end-of-fram positioning (you could even have a
spline of transforms if you didn't want to linearly interpolate between
the start and end, but that may be too hairy to be worth the trouble).
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraznet> wrote:
> See, I don't disagree with you about that at all. But it brings up a
> problem how how you "tell" the parser that the object you are defining
> is "supposed" to be changed later. It also doesn't address other issues.
How are you going to tell it that regardless of the transformation array?
The only "problem" your transformation array "solves" is that it makes
it possible to change individual transformations stored in that array.
However, that doesn't solve the issue of *how* you are going to change
those transformations in later frames. What kind of code will you write
in order to do that?
And that's exactly why the transformation array is not needed: The exact
same code that can be used to change the array can also be used to apply
all the transformations (optionally modified from previous frames) to the
object.
Besides, your array solution presents other problems which are not
problems in a "apply transformations with SDL code". For example, what
if you want to insert a new transformation somewhere in the series of
transformations? Or what if you want to remove some transformation?
What if you want an alternative series of transformations at different
frames?
You would need to offer all kinds of functions to modify the array,
and the user needs to write some SDL code to call those modifications.
However, with the same effort the user could simply call the functions
which apply transformations to the object directly. Adding or removing
transformations is simply a question of putting them in conditional
statements. Applying alternative series of transformations is simply a
question of if-else or switch blocks.
There's no need for a transformation array.
> Sigh.. Your just getting it at all. The ***existing*** SDL assumes that
> each "frame" is "static", as so is the object. Its not possible in the
> current design to change the matrix for and object in "any" sense other
> than in the final object.
That's not a technical limitation. That's just a syntax limitation.
It would be perfectly possible in the current POV-Ray to change the
transformation matrix of an existing object if someone simply added the
proper syntax for it. (And that's exactly one of the reasons why the
whole new SDL is being discussed. To add easy support for such things.)
> In an SDL that supports its own animation/render functions, you can't
> have "static" objects.
POV-Ray doesn't assume that objects are "static". It's just that there's
no syntax to change the transformation matrix of an existing object. Plain
and simple.
> 1. Track the transforms for the object, then simply
> replace the one you need to change. 2. Generate a static object
> "anyway", then apply your own transform to its parts, to produce the
> result you want. Either way you are going to be using memory to do it.
Why do you have this obsession that individual transformations *must*
be stored somewhere?
You *apply* transformations in the SDL code. You don't *store* them
(not as individual transformations anyways). That's because the individual
transformations are already "stored" in the SDL code itself. Why do you
need to store them in two places?
At each frame you simply execute that SDL which applies the transformations
to the objects.
You are going to have to execute some SDL at each frame anyways (to
change transformations). It's not any more difficult to simply execute
the SDL code which applies all the transformations.
> Look, if you still think I am full of it, then why not agree on some
> example concept, with a specific number of parts, etc. Then each of us
> can give a psuedocode example of what the hell we are talking about,
> because I am not entirely sure I am not missing something you are trying
> to get across too.
Let me see your suggestion about the new SDL code which modifies the
"transformation array" at each frame.
My answer is that it's the exact same thing, but without the transformation
array. Simply apply all the transformations to the object at each frame.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraznet> wrote:
> b) you
> have to reset it back to the very first state it had **prior** to any
> transforms, then reapply **all** of them.
> the later is just
> absolutely stupid, since you might as well not even bother applying any
> transforms to the original object(s), until you need, just before you
> render it.
Then the vast majority of renderers and rendering languages (eg. OpenGL)
are "absolutely stupid" because that's exactly what they do. That's exactly
what POV-Ray does currently as well.
At each frame they reset the transformation matrix to the unit matrix
and then apply all the (possibly modified) transformations to it. That's
standard procedure, and it's by far the simplest and easiest way of
doing it. You don't necessarily need any data container to store all
the individual transformations because the individual transformations
are in the code you write (this is often the case eg. with OpenGL).
(Sure, you can do it in other ways too in OpenGL, but resetting the
transformation matrix and applying all the transformations to it at
each frame is a common standard way of doing things. It's simple, easy
and fast, and it doesn't require any more memory than the code itself.)
I simply can't understand why you think this is such a "stupid" idea.
It's a very simple and working idea. It keeps things simple, it doesn't
require any memory and it's easy to implement.
> Neither of them help your case, since they both require
> somehow "tracking" what you did to the original, or storing all your
> transforms, including the first state, in some other array.
No, it doesn't. Writing an OpenGL application doesn't require you to
"track" all the transformations you have applied to every single object.
When you want to render a new frame in OpenGL, you simply reset the
transformation matrix and apply the same transformations to it (with
possibly modified values). That's it.
The new SDL doesn't need to be any different from this.
You don't seem to grasp the idea that all the transformations are
already "stored" in the very code that applies those transformations.
You don't need to store them anywhere else. Simply re-apply the same
transformations at each frame, and there you are.
> That just leaves the absurd claim that you can somehow
> reset a matrix to a usable state without keeping a big array with "all"
> of the transforms in it
The current POV-Ray manages to do it. Most OpenGL applications manage
to do it. Most other renderers manage to do it.
Just because you can't understand how they manage to do it doesn't mean
it's not possible and easy.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> No semantic difference, just associative.
In other words, you don't like the syntax.
> And when you are dealing with
> objects that is often more important than semantics.
I'm not sure what's more important about a programming language than
knowing what the constructs mean.
But given that, now we're just arguing over syntax. That makes things a
lot more clear.
> Semantically they are **identical**, associatively they are
> **completely** different.
On the other hand, if you could do the latter and not the former, you'd
have a much more limited language.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> the issue isn't semantic, its associative.
I'm not sure what your level of experience with programming is, but such
things stop being problematic after a while.
> Objects don't "usually", when they track some internal set
> of data, rely on purely external sources for storing it, simply because
> that disassociates the data from the object that uses it.
Not if it's indexed by the object.
> ginger.copytransforms(fred)
> vs.
> ginger.applytrandforms(arbitrary_table)
Of course when you name one of them "fred" and the other
"arbitrary_table", it's confusing. Don't do that.
I'm suggesting
walking_transforms[ginger] = walking_transforms[fred].
Or even
walking_transforms[ginger] = feminize(walking_transforms[fred])
or
running_transforms[ginger] = walking_transforms[fred]
Then, eventually, you say
ginger.apply(running_transforms[ginger])
fred.apply(walking_transforms[fred])
If you have a set of global transforms (that always apply), you can
extern function
feminize(array of transforms) returns array of transforms;
global_transforms[fred] = (....)
global_transforms[ginger] = (....)
frame_transforms[fred] = (clock*....)
frame_transforms[ginger] = feminize(frame_transforms[fred])
frame_transforms[freds_arm] = (rotate clock*y)
ginger = object(...)
fred = object(...)
freds_arm = object(....)
foreach object {ginger fred ...) {
object.apply_transform(global_transforms[object])
object.apply_transform(frame_transforms[object])
object.render
}
freds_arm.apply_transform(global_transforms[fred])
freds_arm.apply_transform(frame_transforms[fred])
freds_arm.apply_transform(frame_transforms[freds_arm])
Maybe you should supply a similar bit of pseudo code showing a similar
scene and show why your mechanism is more clear.
> The first one though is "associatively" clearer, even if its
> semantically the same.
Except it only associates to the object. It doesn't "associate" what the
*transform* is, only what object it applies to. Perhaps it's only clear
to you.
Plus, if in your code, you have
ginger.apply(walking_transforms[robot])
fred.apply(walking_transforms[robot])
I think that's more clear than saying
ginger.transforms = fred.transforms
because now you know they're both using the same
transforms and you know those transforms are
treating them both as robots.
> And, even if you wanted to do that, there hasn't
> exactly been a discussion on how you a) structure such a table,
It's structured the same way you'd structure yours, except it's a
user-created object instead of a unique property defined by the
renderer. This also has the advantage that you can (for example) pass it
to user-defined functions without having to create an object just to
carry it around.
> or b) get one out of, or into, an POVRay object that has subobjects.
The same way you would.
> when you first did some_object(<location>,size(s)) Hardly helpful, if
> you are trying to avoid having to redundantly store "every" change
> needed to get from there to the final result.
I think if you want to argue that your syntax is superior to my syntax,
while my syntax is more orthogonal and more flexible yet has similar
semantics,
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> B) Writing the renderer so that a texture can be based on the camera
> view (with rays being traced, anti-aliased, usw...) of another place in
> the scene.
There have been a POV-Ray patch which allowed to do that, you could have
a "portal" object (which, when, who, and what is out of my memory).
So I guess it's not so hard to do.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> In article <47109fba@news.povray.org>, war### [at] tagpovrayorg says...
>> Patrick Elliott <sel### [at] rraznet> wrote:
>>> You keep claiming that you can just somehow "untransform"
>>> the matrix
>> Do you understand the concept of resetting a transformation matrix?
>> Or is that concept way too difficult for you to comprehend?
>>
> Think I have already addressed most of this in the other post I made
[snip]
>
> Or do you want to beat the straw man some more?
>
I am not familiar with that expression, but anyway here are my 2 cents.
What you deem necessary for animation is in my (and Warp's if I may
speak for him) overkill. It may be handy for some situations but I think
in the majority of cases I wouldn't use it. POV4, however, should make
it possible and easy to use. So what this discussion should have been
about is to what extend it has to be hardcoded in either the internal
datastructures or in the syntax of the language. My (and presumably
Warp's) opinion on this is that what you propose will be extremely easy
to implement yourself within the new language for those cases where you
need it. So it has no implication for the current POV4 discussion
whatsoever. You are free to continue this discussion with warp of
course, but it will be like talking to a wall, without being able to
study the delicate texture of the stones.
The opinion that it is not needed is based on knowledge on how the
current implementation works and some safe assumptions on what POV4 will
allow at the minimum. However, you should watch the development closely
that indeed these minimum requirements will be met. Or even better:
create a list with those minimum requirements on the new wiki.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
