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