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

> In article <471fc224@news.povray.org>, 
> nic### [at] gmailisthebestcom says...

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

I have once replied to year-old threads without checking the date first...

Post a reply to this message

Nicolas Alvarez nous apporta ses lumieres en ce 2007/10/25 14:08:
> Patrick Elliott escribió:
>> In article <471fc224@news.povray.org>, 
>> nic### [at] gmailisthebestcom says...
>>> Patrick Elliott escribió:
>>>> 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.
>>>
>> 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...
>>
> 
> I have once replied to year-old threads without checking the date first...
Done the same, several times. Now, I double-check to try to not reply to threads 
older than a month.

-- 
Alain
-------------------------------------------------
Please hassle me, I thrive on stress.

Post a reply to this message

In article <472079f9@news.povray.org>, war### [at] tagpovrayorg says...
> 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 transforma
tions
> 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 solution
s
> 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 ver
y
> inefficient or cumbersome.
>   Certainly solutions on how to individually store series of transformati
ons
> 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 reflecte
d
> ray from the direction of the incoming ray and the normal vector, and the
n
> 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 efficie
nt
> 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 reflect
ion
> is calculated by writing your own reflection shaders.
> 
> 
Ok.. But then the question is, why would pulling some things out of the 
core be "more efficient". But yeah, presuming you can add plugins that 
are compiled somehow, so as to speed up operation, instead of doing 
***all of it*** in SDL, then you could tokenize the feature as a core 
attribute of "POV_Object", which would then be directly inherited by all 
other object types:

sphere{ <...>, ...
  autotransforms{[table]}
}

Much nicer, since you can then use it "in" the existing SDL format, 
while ignoring it if not needed. The alternative is to extend every 
object you personally need to have do it, like:

mysphere extends sphere{
  Add data_type autotransforms as pointer
  event self.transform("mytransforms")}
mysphere {<...>, ...
  autotranforms ...

function mytransforms(object) {
  if exist object.autotransforms then {
    ... do the stuff to apply them.
  else
    post_error "Object does not contain this data type."
    stop
  }
}

Obviously the *major* disadvantage to doing it that way is that you are 
either running it uncompiled, or JIT compiled, both of which might slow 
things down too much, compared to putting the same functionality into a 
compiled addon, then linking it to the "main" POV_Object as a direct 
extension of it, and all inheriting objects.

Again, its, "At what level do you add a feature, to make it fast 
enough?"

-- 
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:
> Obviously the *major* disadvantage to doing it that way is that you are 
> either running it uncompiled, or JIT compiled, both of which might slow 
> things down too much

  What makes you think that JIT-compiled code is relevantly slower than
regularly-compiled code?

  Besides, transforming objects is not one of the most speed-critical
things in rendering. It's a pre-rendering step done once (per frame)
and that's it. Hardly anything that needs extreme speed.

-- 
                                                          - Warp

Post a reply to this message