Chris B wrote:
> "Charles C" <"nospam a nospam.com"> wrote in message
>> Anyway, before I submit it, I was hoping to get some feedback, in general
>> and specifically on this: I like using a system where something like
>> Main_Scene_File is a global variable and if it's already defined, a given
>> include file knows not to use a self-contained demo scene. It means an
>> include file can stand alone as exactly one file.
>> ... I know I've asked this before, and I've even wished for a
>> main_scene_file keyword, but I don't remember how it turned out for the
>> object collection. What gobals can be truly global?
> It looks fine to me the way you've done it, with the line commented out and
> a description of how to use it at the top of the file. Those wishing to use
> this system can readily uncomment the line. I think it would cause problems
> if it were distributed without the line being commented out because it would
> break the scene file of anyone who didn't know the system.
OK, I'll submit it as is. I try to check for things that might be
defined already, Red or camera, but that definitely remains a drawback
of doing this in SDL. If main_scene_file were an actual keyword, it
wouldn't break it.
> I too would like some system defined way of interrogating the include file
> chain. My preference would probably be for a read-only array listing the
> chain of files. If the array dimension length is '1' you'd know that the
> file you're in is being rendered directly. Anyone needing additional info
> about the include file sequence could start trolling back through the
> contents of the array.
That sounds like an even more robust version of what I had in mind... :)
Would that be an array of strings? Do you mean a special array which
changes length dynamically? If the starting-file performs some
ifndef()'s and includes whatever it happens to need, then the array
would grow. But unless it shrinks by the time the parsing returns to
the starting-file, you wouldn't be able to use that test. OTOH, a
strcmp() on the fist element should work. Another possibility might be
a float value/keyword like include_layer_number.
> I don't recall ever seeing a concensus or any agreement from the POV-Team to
> include such a feature in a future version of POV-Ray. I seem to remember
> rather that the discussion exploded into one about rewriting the whole
> language. It might be worth re-opening discussions about this on
> povray.general on the off-chance of getting some simple solution into 3.7.
As far as a keyword and POV-Ray itself goes, Chris Cason responded to my
suggestion saying it may have some merit but took it in a slightly
different direction: He implemented the alternate-file-render feature
starting in beta 20b. That addressed the convenience-of-editing include
files, but not the self-demoing of include-file-objects that I was
dreaming about. (I guess I have a thing for standalone files whenever
IIRC, I think he did mention that if there were such a variable, it
might work better letting POV-Ray keep track of whether it's parsing the
first file and have the keyword be a binary variable which toggles
accordingly. Maybe I'm mis-remembering. It's been a while.
> I've explored quite a few alternative ways of achieving similar results with
> the current version of POV-Ray and I've not found any solution that I would
> claim to be 'best' in all situations.
> Chris B.
I'd be interested to know what other ideas you've had. Anything that
does not break people's scenes if they don't use that system and makes t
possible to do what I'm trying to do would satisfy me. I suspect it's
not possible without adding a keyword of some sort.
Post a reply to this message