POV-Ray : Newsgroups : povray.advanced-users : Questions about fixing SHAPES.INC re: recent bug reports : Re: Questions about fixing SHAPES.INC re: recent bug reports Server Time
3 Jul 2024 06:01:35 EDT (-0400)
  Re: Questions about fixing SHAPES.INC re: recent bug reports  
From: Kenneth
Date: 12 Oct 2008 09:45:01
Message: <web.48f1fd9d80f4bccd78dcad930@news.povray.org>
Just tying up some loose ends:

Kenneth wrote:
> I'm also wondering whether my little int addition *might* eliminate the
> necessity for the F1+A, F2+A,  code fix. Just crazy intuition.

Nope, the fix is still needed. Oh well, can't win 'em all!

Kenneth wrote:
> In order to #write a data file, the macro (in your SDL) needs a file name in
> double quotes. That's covered in the docs, of course.  But there's a problem
> if you happen to #declare the HF object (either with or without an object
> wrapper): Putting in any name for the file causes the macro, or *something*,
> to fail...
> ....This problem doesn't occur when running the HF macro 'raw' (i.e., with no
> #declare.) [and no object wrappers.]...

I gave this situation some thought, and realized my own wrong assumption about
how the shapes.inc macros work. The mesh2 macros there function in two
different, mutually exclusive ways--depending on if they are #WRITEing data or
not.  Either the macro creates an 'object' in the scene (when NOT #writing), or
becomes just 'a set of instructions for #writing a file.' It's an either/or
situation, not both. What I had *expected* was for the macro to #write data AND
produce an object which POV renders, all at the same time.  That's not the way
the code is written--and probably for good reason. In order to do BOTH things
at once, the code would have to first #write the data to a file, then #read(?)
back that data in order to generate the object. (Which would slow things down.)
Or else, a great deal of the code would need to be duplicated--one set
exclusively for #writing, the other for feeding directly into POV-Ray for a
'simultaneous' object render. (In which case, both code sets would have to be
parsed, again taking extra time.)

By adding a #declare (and/or object wrappers) to the HF_Cylinder macro during
the #write pass, I had inadvertently given shapes.inc some 'extra' code
snippets that it wasn't designed to handle; thus the fatal error. So the
reality is: When #writing data, use the 'raw' macro in your SDL.

Ken W.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.