I don't mean to sound arrogant, but the only includes I ever use are 
transforms, rad_def, and functions, all of which I feel should be part of 
the language (why's vturbulence part of the SDL but f_granite isn't?!). 
Anyway my point is, even if we had more include files, I'd never use them! 
So I guess that kind of undermines whatever point I'm trying to make with 
the rest of this message... but pressing on anyway:

The reason I don't use them is, for example, materials inc;ude files only 
look right if you have the assumed_gamma used by whoever created the 
includes, and no radiosity (because they have an ambient finish). In fact I 
find even though I often use similar settings in my scenes it's extremely 
hard for me to transfer materials or effects from one scene to another 
without some major editting to fit the different lighting setup. Perhaps 
this is a nuance of povray's way of doing radiosity and finishes, but I 
think more likely it's just symptomatic of having such a flexible render 
engine, it's just a lot easier to make scenes vastly different in pov than 
other renderers.

To make these things work you'd have to make assumptions/standardisations 
for lighting (radiosity or not, brightness), scale (since it's a pain to 
re-scale each thing, plus media effects don't scale well)... Not to mention 
effects that interfere with each other (for example my ocean from p.b.i 
doesn't play nicely with fog, because it's hollow so it can be filled with 
media). I'm just very sceptical that these issues can be resolved in a way 
that is simple for newbies to understand and doesn't interfere with more 
advanced users.

Personally I'd say having some better example scenes, which people could 
tweak to their own ends, would be better. e.g. have a basic interior with 
radiosity (e.g. kitchen scene), photo studio setup, landscape, etc etc. Each 
with a variety of nicely defined objects and materials that newbies could 
rearrange to their hearts content before needing to understand the more 
technical features of pov.

Anyway just my 2 cents.
-- 
Tek
http://evilsuperbrain.com

"nemesis" <nam### [at] gmailcom> wrote in message 
news:web.4558993a8d8f92ab3976a8750@news.povray.org...
> Sometimes, i wonder why there is this feeling in the povray community that
> everything should be built from scratch.  What i mean is:  while povray is
> an excellent and very versatile software it comes with a very limited
> "standard library" of objects and textures and this sure hampers "code
> reuse".  Specially because this is the 2000's, but the small povray stdlib
> still comes with include files from the 1990's!
>
> I've seen such amazing models, textures and techiniques from many povray
> enthusiasts from over the years.  There are at least two nice lens flare
> include files from well-known POV-Team members, but that aren't featured 
> in
> the stdlib!  What about the many tree and grass macro packages?  Why isn't
> there at least one of them in the standard library?
>
> I wish povray was a lot more used, but i'm thinking it suffers a bit from
> not being "integrated":  if i was a newbie and wanted to quickly create
> stunning scenes, i'd have to crawl the web gathering bits here and there.
> Just imagine:  the other way, the guy wants a kitchen scene and he goes
> like:
>
> #include "kitchen/tiles.inc"
> #include "kitchen/dish.inc"
> #include "kitchen/bottles.inc"
> #include "kitchen/food/fruits.inc"
>
> Or stuff like that.
>
> This is just a rant/wish, but if i could in some way of another to make 
> this
> software more acknowledged, i would.  Heck, i would gladly donate my 
> sample
> scenes and code i post here, without hesitation, crappy as they may be! :P
>
> What do you guys think?  Any chances of something like that happenning 
> just
> in time for Pov-ray 3.7?  If you're fearing the trouble of searching for
> and categorizing all the gathered textures, objects etc, i'd gladly
> contribute to it.
>
> What would it need to get foreign work into povray standard include files?
>
>
>

Post a reply to this message