 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4713433c@news.povray.org>, war### [at] tag povrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Huh? How? Your missing the point. The initial structure of the object
> > **must** be static. Why? Because if it isn't, then you have to reparse
> > the entire structure.
>
> I didn't understand that.
>
> > Currently you can't tell something that you want
> > to add transforms to the 6th nested object in some complex series of
> > unions
>
> That's a syntax limitation in the current SDL, not a technical one.
>
> > nor can you "change" those.
>
> It would be possible to change them if the proper syntax would be added
.
>
> > The object, once it exists, is static on "all" levels other than the
> > base union.
>
> It just looks like it for the simple reason that the current SDL has no
> syntax for modifying it. AFAIK there isn't any technical limitation to th
is,
> just that the SDL hasn't been enhanced to do this.
>
> > That only gets worse when
> > dealing with a change to the SDL that allows it to run like a program,
>
> You mean the current SDL is not "run like a program"? How so?
>
> > If-else blocks won't work because by the time you get to
> > the next frame all of the "code" that contains them will have already
> > executed, and isn't reparsed
>
> 1) If code is not executed at each frame at all, by which method are
> you suggesting the user could change some transformations at each frame?
>
> 2) Why do you think the new SDL should have byte-compilation and even
> JIT-compilation support? Just for fun? No, for the precise reason that
> it doesn't need to be *parsed* again and again, just parsed once and then
> executed as many times as necessary.
>
> > so those statements are **never** checked
> > to determine what the new result will be.
>
> Why have such a stupid limitation? There's no reason nor need to.
>
> > Instead you have to disconnect
> > the object definition, the if-else statements and the execution, so tha
t
> > you 1) create an object with some static and some non-static transforms
,
> > 2) render the first version, then 3) access those transforms you need t
o
> > change.
>
> How are you supposed to do step 3 without executing any code, like you
> stated above?
>
.... Ok, read this far and you keep repeating the same assertion that I
said the "new" SDL wouldn't execute any code, which is only "partly"
true. Sure, it would have to execute some code to change the data being
used, and a "render" command, but it wouldn't have to execute
instruction for every single sub-object in the main object to do so.
That would happen implicitly. I am sorry I wasn't clear about that
point. And it was in no way meant to imply that more direct methods
wouldn't be available. But, its a mute point, since in this same post I
admit some of the concept was badly considered anyway.
> ...
Ok, lets continue from here, since this is where I admit that I might
have been arguing something that... well, while it would have worked, a
better compromise exists, which does the things I intended, without the
things I am more than willing to admit I hadn't thought out well.
> > So, OK, I admit, what I
> > propose may not be strictly necessary, it might be useful some times,
>
> That's exactly the point: *Sometimes*
>
> The thing is, if *sometimes* you would need such an array, you can
> create one. There could even be some kind of library to aid you doing
> this. But the point is that this specific solution should not be forced
> on the user since it's not necessary.
>
> This kind of specific solution should not be something done in the
> core code. The core code should have a more generic solution.
>
> > > Let me see your suggestion about the new SDL code which modifies th
e
> > > "transformation array" at each frame.
> > > My answer is that it's the exact same thing, but without the transf
ormation
> > > array. Simply apply all the transformations to the object at each fra
me.
> > >
> > Well, I think I am thinking more in terms of the data end, rather than
> > the program end. I am thinking in terms of, "Automatic application of
> > known transforms.", you are thinking more in terms of, "Manual
> > application of any needed transforms."
>
> There's nothing stopping you from automatically applying transforms
> to the object from some data. Your "array" solution makes absolutely
> no difference in this.
>
No it doesn't. And, as I post in a later sub thread, there is a solution
to that, which does what you want, and what I want. Which is to have the
"array" or "table" used be linked to the object only through an
associative pointer. The trick being that you could, as I describe
there, implicitly have the table of transforms applied at the render
step, saving the need to explicitly apply them, while "still" allowing
for direct application in cases where you need to calculate those
changes on the fly. Basically, if you know that object X is already
following a "precise" set of predetermined actions, and you have no need
to change them programically, put them in a table, link the table, then
have the parser/post parser/engine, or what ever apply them via that
mechanism, instead of "requiring" them to be applied implicitly. This
both a) allows such tables of actions to be automated and b) maintains
the "associative" connection I was looking for in such cases, making it
easier to keep track of just "which" object the table belongs to.
Mind you, I fully expect you to argue that this is just as silly and
useless. 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood <tim### [at] comcastnet> wrote:
> Perhaps more flexible, but a language syntax for animation
> that is designed to be human readable would be easier to
> modify the scenes.
> (by definition, since it would be designed that way)
Not necessarily. A script-based solution may be equally easy to
understand, but much more flexible (because the implementation is
easy to change).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>
> Sigh.. Your just getting it at all. The ***existing*** SDL assumes that ...
"You really don't understand why the current one is the way it is, do you?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> andrel <a_l### [at] hotmailcom> wrote:
>> 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.
>
> There could even be a library for that exact purpose, which could
> perhaps more or less transparently add support for the feature he wants
> (on a per-object basis).
#macro applyTransforms(Object, Trans)
#local I=0;
object {
Object
#while (I<dimension_size(Trans,1))
transform { Trans[I] }
#local I=I+1;
#end
}
#end
Modify the Transforms array whenever you want to, then call
applyTransforms at the end of the script.
Usage:
#declare Transforms=array[4];
#declare Transforms[0] = transform { rotate x*20 };
//no reason to have a single transformation
#declare Transforms[1] = transform { translate <1,2,3> rotate y*45 };
#declare Transforms[2] = transform { scale 1.1 };
#declare Transforms[3] = transform { rotate y*20 };
...
//modify existing transformation
#declare Transforms[0] = transform { rotate x*21 };
Then call the macro and be done with it. We don't need any stinking
transformation array built-in (also, if POV did it automatically, it
would keep [1] as two entries).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <471d231d$1@news.povray.org>,
nic### [at] gmailisthebestcom says...
> >>
> > Sigh.. Your just getting it at all. The ***existing*** SDL assumes that
...
>
> "You really don't understand why the current one is the way it is, do you
?"
>
Umm. There hasn't been a single post on this subject for some time. And
yes, I know damn well why its the way it is *now*, its based on DKBTrace
from ages ago, has maintained compatibility clear back that far (more or
less) and **never** was designed to be used to do complex animations,
without external methods to run them. No one ever built in a language
flexible enough to bypass the need for dozens of external applications,
to do all the stuff it can't.
What exactly is the point of harping on a few sentences out of dozens of
things I have posted on this, ***after*** I already admitted, had you
bothered to read anything other than this post, that my idea was flawed,
you could still get what I was looking for in a way that isn't too
dissimilar from what Warp was suggesting instead and that the other
people had a point about storing the stuff the way I suggested being a
bad idea? Other than, that is, to be a bigger ass than I made myself
look with the comment you are quoting?
Besides, we are not discussing why the holy book of POVRay demands that
all things continue to work as they do, we are talking about what
changes *may* be useful to make it easier to do things, and having
better object handling, and a better script system, is a major
improvement over the mess we have now, where the internals are hard to
add to, the script language barely qualifies as a script, the import
features only handle bitmaps and comma deliminated text (which nothing
in **any** other application that produces text data uses), and where
we, more often than not, have to rely on some third parties closed
source application to *partly* convert from A to B, so that we can use a
plugin for that, also closed source, which hasn't changed since POVRay
1.0, to *export* the now binary format back into a text format POVRay
can use, only it can't, since its missing 50% of everything that wasn't
possible to export to POVRay 1.0, along with things it exported wrong,
and things that can't be exported at all, in that way, because they
don't work the same way any more (triangles in a mesh, for example,
which overlap, so the *current* versions delete as deleterious to the
object, even though it leaves huge holes in it without them).
The point is to talk about how to improve this, not what reasons there
are/where for why it works as it does now. Even if I could quote the
entire code base for the engine layer by rote it wouldn't change the
basic fact that we need to adjust how some things in it work, if we want
to be taken seriously, instead of looked at as a bunch of fools that
still sit in their basement, doing the equivalent of making the first
8080 based computer play Jingle Bells, by flipping mechanical switches
to program it.
--
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 <sel### [at] rraznet> wrote:
> I know damn well why its the way it is *now*
Once again you do a pretty good job at hiding it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What exactly is the point of harping on a few sentences out of dozens of
> things I have posted on this, ***after*** I already admitted, had you
> bothered to read anything other than this post, that my idea was flawed,
> you could still get what I was looking for in a way that isn't too
> dissimilar from what Warp was suggesting instead and that the other
> people had a point about storing the stuff the way I suggested being a
> bad idea? Other than, that is, to be a bigger ass than I made myself
> look with the comment you are quoting?
Sorry, I'm still catching up with posts (in chronological order, at
least within threads), and I usually reply them as I read them, not
after reading the whole thread. Bad habit, maybe.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <471f19ab@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > I know damn well why its the way it is *now*
>
> Once again you do a pretty good job at hiding it.
>
Snort. How so. I am just repeating what someone else said, that most of
why it works as it does is a relic of how it evolved, not an intended
design choice, which was either the best option for how to do it, or the
best way to do it in a new design. While I might not know a lot of
specifics, I don't notice you continuing to complain about my idea,
after I acknowledged that you could get the two things I thought would
be useful **without** the concept I originally suggested. I presumed the
complete lack of any response meant that yeah, it would be OK to have
some automated matrix creation, when direct control isn't needed, and
that linking that via an associative pointer on the object (which if
null would assume you plan to make the transforms yourself later),
instead of having to explicitly tell it to use table X for frame 1-10,
table Y for frame 11-50, etc. You just tell it, "Use this table until I
tell you otherwise.", and no more memory gets used that with your idea
(well, except for a few pointers to the date, but geeze...)
--
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 <471fc224@news.povray.org>,
nic### [at] gmailisthebestcom says...
> > What exactly is the point of harping on a few sentences out of dozens o
f
> > things I have posted on this, ***after*** I already admitted, had you
> > bothered to read anything other than this post, that my idea was flawed
,
> > you could still get what I was looking for in a way that isn't too
> > dissimilar from what Warp was suggesting instead and that the other
> > people had a point about storing the stuff the way I suggested being a
> > bad idea? Other than, that is, to be a bigger ass than I made myself
> > look with the comment you are quoting?
>
> Sorry, I'm still catching up with posts (in chronological order, at
> least within threads), and I usually reply them as I read them, not
> after reading the whole thread. Bad habit, maybe.
>
That's OK. I kind of over reacted. It was like 3 days since anyone
bothered to post anything about it, and the first thing someone did was
a rant about my behavior, which I admit wasn't too congenial at that
point in the conversation thread. :p But, I have some times done the
same thing myself, when dropping in to the middle of a long series of
posts, so...
--
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 <sel### [at] rraznet> wrote:
> I presumed the
> complete lack of any response meant that yeah, it would be OK to have
> some automated matrix creation, when direct control isn't needed, and
> that linking that via an associative pointer on the object (which if
> null would assume you plan to make the transforms yourself later),
> instead of having to explicitly tell it to use table X for frame 1-10,
> table Y for frame 11-50, etc. You just tell it, "Use this table until I
> tell you otherwise.", and no more memory gets used that with your idea
What I want to see is a generic solution. Your propositions just sound
like you are suggesting that the core code has to support the notion of
"transformation arrays" specifically. Such a transformation array does
not actually solve any relevant problem, but it only introduces one
possible (and seldom used) way of applying several consecutive transformations
to the object.
It would be much better if the core code would simply have a more
generic "engine" so that you can easily write your own preferred solutions
to whatever problem you are having (not just transformations, but
everything else too), and maybe write a library with these solutions.
Transformation arrays are not something to be put into the core code,
but into a library, if anywhere.
Also, being able to say "use this until X" is a specific solution,
and should not be a property of the core engine. Again, this should be
something you can implement yourself, and perhaps create a library
from it.
Hard-coding specific solutions makes the core code monolithic, rigid
and hard to extend. It only adds a bunch of specific solutions which
are not needed to be there.
IMO the core engine should only contain the fundamental features of the
raytracer which must be there either because they simply cannot be
implemented with scripting or implementing them in scripting would be very
inefficient or cumbersome.
Certainly solutions on how to individually store series of transformations
is not such a thing.
The more that can be removed from the core engine and implemented with
scripting, the better. This makes it easier to enhance the renderer and
implement new algorithms.
For example, one thing I envision and hope could be removed from the
core engine and into a scripting shader is surface reflection. After all,
reflection is nothing more than calculating the direction of the reflected
ray from the direction of the incoming ray and the normal vector, and then
tracing a new ray towards that direction, and mixing the returned color
with the current one. This could be an ideal thing for a shader to do.
My hope is that the shaders in the new scripting language will be efficient
enough so that this will not slow down the rendering measurably, and thus
it will be possible to implement it as shaders instead of being a core
engine feature.
If this is possible, then it becomes possible to change the way reflection
is calculated by writing your own reflection shaders.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
