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

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-29C626.08493025032004@news.povray.org...
> In article <4060aa7f@news.povray.org>,
>  "Chambers" <bdc### [at] yahoocom> wrote:
> > 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.


So you're saying that objects themselves would be declared as structures,
and then the rendering engine would read information from these structures?
That *would* simplify access to per-object info, but I'm not sure about the
effect it would have on SDL.  Wouldn't the SDL need reworking?

-- 
...Chambers
http://www.geocities.com/bdchambers79

Post a reply to this message