> 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

Warp wrote:
>   What makes you think that JIT-compiled code is relevantly slower than
> regularly-compiled code?

It's hard to do global optimizations. It's easier to do processor- and 
data-specific optimizations. Depending on the HLL you're compiling 
*from*, it could go either way.

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

In article <4721bb6d@news.povray.org>, war### [at] tagpovrayorg says...
> 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.
> 
Except that in many cases the parsing, and thus script execution, is 
already taking far longer than the actual render, so it *does* matter 
how its done. And as Darren points out, JIT optimization its hardly the 
same as processor optimization.

Having thought about it, there needs to be something close to the core 
to do this anyway. As I see it there are two ways to handle it, before 
rendering, do a call to some sort of "transforms" event, which would 
call a function like:

function on_transforms (object){
  if exists object.autotransforms {
    for each trans in object.autotransforms {
      call transform(trans)}}}

This would happen for "every" subobject in a union or other layered 
object. But, this bit of code it so simple there is no reason at all 
that you can't have it built in some place, since you already **need** a 
way to intercept the render, so you can auto-add the transforms. The 
difficulty is that you either have to have an array for every object, or 
if you use a table of some sort, the object.autotransforms needs to be 
smart enough to check for a table, and if the object being tested is 
"in" that table as something which needs to be transformed. I.e., it 
needs to walk the table somehow, and return an array for "that" object 
from in it. another way is to not step through the table, but rather to 
mark each object, so it knows to look in the table for it. This would be 
like a flag. Such a flag does away with the need to add code on the 
lower levels to "automatically" feed every object through the above code 
fragment, which would be faster, but it also means you would have to 
"mark" every section of a compound object that need to be read from the 
table(s) instead. I.e., the could would still be present, but triggered 
by the presence of the keyword, which could then be handled in a plugin, 
instead of in the engine.

The former version "must" be in the engine, or at least the latch needed 
to intercept with. The reason is simple. Since the later is triggered by 
a key word, you can add the keyword as a plugin, along with the code 
needed to handle its presence. If you do it the other way, you **must** 
already have the means to stop the engine *before* it renders anything, 
so as to test for and process the changes you want, before allowing it 
to continue.

If however, it was decided that such an intercept prior to the render 
step was useful for other things, then it becomes less relevant, *but* 
then the question is still, "Does stepping through a lot of these calls 
cost more time in 'script' or compiled with proper optimizations?" Its 
not much code, but it "is" a bottleneck, and one that might be faster as 
part of something that also supports multiple core processing, where as 
the script itself... might not do that so well. How many copies of the 
script is likely to be "allowed" to run? Or for that matter, is it even 
possible to split parts of a script to a separate thread, on a different 
processor. This is one case where doing that could vastly speed up 
application of the transforms, since you could calculate the matrices 
for as many objects as you have threads/processors. In fact, that is 
faster, in theory, than you could do the same transforms directly. 
Right?

-- 
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:
> Except that in many cases the parsing, and thus script execution, is 
> already taking far longer than the actual render, so it *does* matter 
> how its done.

  Applying transformations is not the heaviest operation during parsing.
You will not gain any parsing speed using your suggestion.

> And as Darren points out, JIT optimization its hardly the 
> same as processor optimization.

  We are talking about some percents. You wrote as if JIT-compiled code
was several orders of magnitude slower than compiled code.

-- 
                                                          - Warp

Post a reply to this message

In article <4722dd91@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Except that in many cases the parsing, and thus script execution, is 
> > already taking far longer than the actual render, so it *does* matter
 
> > how its done.
> 
>   Applying transformations is not the heaviest operation during parsing.
> You will not gain any parsing speed using your suggestion.
> 
> > And as Darren points out, JIT optimization its hardly the 
> > same as processor optimization.
> 
>   We are talking about some percents. You wrote as if JIT-compiled code
> was several orders of magnitude slower than compiled code.
> 
It probably isn't, but we are not talking about just handling 
transformations, but the overhead of handling data needed to do that. 
Your still using the same commands to do the transforms, but you are not 
doing them directly, you are reading them from a table, then passing 
each to the part of the system that handles transforms. That means its 
going to take slightly longer. Mind you, its possible you could make a 
table layout that short cut things, like tokenizing the commands, which 
would make lookup slightly faster, maybe. But again, its still 
"percentages" as you say.

You seem to have missed part of what I wrote though. On some level you 
are still dealing with the problem if if you are going to parse one 
command, to add the table, then use an intercept, prior to the final 
render step, to process the table, or you **also** parse a separate 
command for every part of the object that need to gets its transforms 
from the table. The later adds for extra time to detect that command, 
every time it appears, as well as the process or retrieving the data 
itself from the table, so it knows what transforms to apply. Whether or 
not the actual computations for the transforms themselves are trivial 
delays has no meaning to if the added commands, or the method used to 
retrieve the data to be applied to the transforms, is going to cause 
more time to be used. At mimimum, its going to cost a *slight* amount of 
additional time, no matter which method you use, compare to parsing 
**each command** by itself. I am not sure, other than something silly 
like tokenization, which could be meaningless on a modern processor, 
that you could speed up the retrieval of the data from the table(s).

Yes, we are talking about percentages here, but those can matter, 
especially if there are bottlenecks. And, as I said, if you had 4 cores, 
each reading one objects table, each of those tables containing say 3 
transforms per object, with 20 objects, and it took .01 seconds to read 
and apply the transform for "each" of those commands, you would take 0.6 
seconds to do it, while using a non-threaded script driven solution 
would produce 4 separate passes, one for each compound object, with all 
the same parameters, or 2.4 seconds. Please tell me again how this 
**isn't** significant, especially if you where dealing with the real 
numbers and you took into account a scene with, say, 90 compound 
objects, only two cores and even a .01% decrease in speed due to it 
being a script, instead of a compiled module.

And don't tell me my numbers are silly or irrelevant. At least I am 
trying to come up with some sort of means to compare. If I got them 
wrong by some order of magnitude, it still doesn't change the basic fact 
that more than one core, each processing the transforms for a different 
object, takes **less** time than a mono-threaded script. And most script 
systems don't support multiple threads/processors. It can be enough of a 
pain getting the "core" code to do that right, never mind letting some 
end user muck around with 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:
> Yes, we are talking about percentages here, but those can matter, 

  What's so hard to understand in the concept that applying transformations
to objects is in no way the slowest step in the parsing process? Using your
transformation tables will *not* speed up parsing, not in any relevant way.
Using speed as an argument to support your idea is simply flawed.

-- 
                                                          - Warp

Post a reply to this message

In article <4723f102@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sel### [at] rraznet> wrote:
> > Yes, we are talking about percentages here, but those can matter, 
> 
>   What's so hard to understand in the concept that applying transformatio
ns
> to objects is in no way the slowest step in the parsing process? Using yo
ur
> transformation tables will *not* speed up parsing, not in any relevant wa
y.
> Using speed as an argument to support your idea is simply flawed.
> 
And what part of, "Its not the applying of them that is the issue, its 
how you get the data read/parsed to do it.", are you missing?

And I am not using speed as support for my idea. I think the idea is 
still good on its own merits, since otherwise you have to write your own 
way to do it, and most of the people trying to do stuff in POVRay are 
***not*** going to be interested in reinventing this same wheel over and 
over again. Putting it in a plugin is possible, yes, but **only** if the 
framework is available to allow for it in the first place. A framework 
that only allows you to add new tokens, as it where, for new functions, 
but which can't handle something like this **won't** do it. I thought 
about it, and it just won't work, not without having to add a command 
word to every level of a compound object you want to use it on, which is 
imho damn stupid, if there is a better way.

I covered the point of if the idea was useful already, and whether you 
fracking agree or not, I instead opted to talk about the logistics of 
implementation and the likely issues that could pop up as a result of 
it. Your idea, that you explicitly tell it to apply a transform (or even 
a table of them) every damn time is programically complex, unnecessary 
if the framework exists to do it my way, and divorces the data from the 
object in a way I personally don't like much. Its not functionally 
equivalent, since yours is explicit, mine is implicit, even if on the 
deeper level some of the code is necessarily similar.

And again, the point is, how would you implement it. Which method 
**would** be faster, when you want to use predefined transforms, where 
you have no plans to change the number, type or any major features of 
those things. Whether or not you think its a good idea has jack to do 
with how you would implement it, if it was used, which is what nearly 
the entire prior post was about.

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