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 
possible :-)

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.
> 
> Regards,
> 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.


Charles

Post a reply to this message