"Batronyx" <bat### [at] alliancecablenet> wrote in message
news:3be8ba1f@news.povray.org...
>
> "Redbeard" <red### [at] wvadelphianet> wrote in message
> news:3be8b2d5@news.povray.org...
> >
> [snip]
> >
> >
> > A good way is to parse an included file and keep the parsed file in memory
for
> > the entire execution.  When a macro is read it would be parsed into bytecode
> and
> > stored in memory.  An index to it would be stored and anytime the macro is
> > encountered in the following code the bytecode is looked up and executed.
No
> > need to open the included file again.
> >
> [snip]
>
> I think an exception should be made for mesh includes though eh? They are
> already referenced similar to your description (if I understand correctly) as
> objects and I wouldn't really want the include text hanging around in memory
any
> longer than necessary, considering the size they can achieve. ( And of course
> I'm not referring to includes that generate meshes algorithmically)
>
> Batronyx ^"^
>
Things that are currently objects should remain objects.  Thus, a mesh, unless
it is redefined in a macro, is a mesh.  Right now, I believe, if you set up a
mesh in a macro and then call the macro again, an entirely new object is made.
All references to the first mesh are completely separate from the references to
the second.  Thus:

    #macro Mesh()
        mesh { ... }
    #end
    #declare M1 = Mesh()
    #declare M2 = M1
    #declare M3 = Mesh()

results in, and would result in, two meshes in memory.  M1 and M2 refer to one
mesh and M3 refers to the other.  The reason for this is that POV-Ray has no way
of knowing that executing the mesh statement a second won't result in a
completely different shape.  It could be defined with variables that can change
from call to call.

Now, if you want to *really* optimize the interpreter, you can have it figure
out if it's going to change.  If it isn't, some sort of global instance of the
mesh can be made and all other instances refer to the original.

I'd better stop now before I get into too big a discourse of optimizing objects
in POV-Ray... I need to look at the way objects are stored now before I go too
far :-)

Michael

--
#macro M(D,J)text{ttf"cyrvetic.ttf"D 1,0translate-J}#end#macro N(E,K)#local A=
M(E,K)light_source{-z*30rgb 1projected_through{A}}#end N("Michael"<1.6,-.2,5>)
N("Johnson"<1.9.8,5>)sphere{z*9,4pigment{gradient x+y scale 10color_map{[0 rgb
x][1rgb x+y]}sine_wave}} // (c)2001 Michael D Johnson red### [at] wvadelphianet

Post a reply to this message