Re: [K3d-development] CVS release notes - K-3D 0.3.0.82
Brought to you by:
barche
From: Timothy M. S. <ts...@k-...> - 2004-01-07 22:57:42
|
Paul Gregory wrote: >>-----Original Message----- >>From: k3d...@li... >>Giuseppe Zompatori >> >>I won't be surely whining that they've been removed especially since they >>were causing problems with this or that renderer but it is >>certanly a little >>disarming to see one's work go to >/dev/null when those 2 options could >>probably almost trivially be implemented in Aqsis. > Actually it's not quite that simple, the reason they are causing a problem, > is not that they are not supported by Aqsis, but that the inclusion of a > 'space' character in a declaration name is not supported. It breaks the > inline declaration parser. I have not been able to confirm that this is > valid or invalid in the Renderman spec. but if it turns out to be valid, I > will happily revisit the parser. Giuseppe: I've been looking into this issue for awhile, and I've also yet to find anything definitive in the standard on whether whitespace in a token is valid. I'm pretty-well convinced that it *shouldn't* be legal because tokens and shading language symbols are interchangable, and shading language, with its "C"-like syntax, certainly doesn't support whitespace in symbol names. The only way around this that I could see would be to introduce some pretty ugly contextualized rules into RenderMan, e.g. "tokens can contain whitespace but only if they aren't used in a shader call", or "tokens can't contain whitespace unless they're used in an option call", etc. So the nature of the error in this case was the determining factor in pulling the options - the rest of your changes are safe. It's occurred to me that over the long haul, trying to hard-code our RenderManEngine to contain every option for every RenderMan implementation is neither practical nor desirable, and we should work towards a more flexible way to set nonstandard options, but that's a project for another day ;) Cheers, Tim |