In article <4060aa7f@news.povray.org>,
 "Chambers" <bdc### [at] yahoocom> wrote:

> True.  Multiple textures / medias aren't something I tend to go for,
> though - I prefer a nice ordered hierarchy.  Of course, that doesn't mean it
> isn't possible, and any solution would need to account for that.

What about pigment_map or texture_map?
You can arrange everything in a heirarchy, but it won't be quite that 
simple.


> > It would require writing a lot of special code for each object type, and
> > as already mentioned, the specified object parameters may no longer
> > exist in the same form, and some things can exist in multiple forms. You
> 
> But don't all objects share certain parameters, such as texture, location,
> etc?

Texture, interior, etc. These things could be handled by the same code. 
However, that still leaves a lot of object-specific code to write and 
maintain.


> Structures would be useful in and of themselves, but that's another topic.

Not entirely. I mentioned it because it would put all the parse code in 
one place, doing one thing: accessing members of structures, rather than 
scattered throughout all the object parsing code. Objects would parse to 
these structures, and later be converted to the internal form for actual 
rendering. It still adds complexity, but gets rid of several problems at 
once.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message