"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> A closely associated issue raised in the original
> thread was how to maintain diversity in our scenes. The concern expressed
> was that, if many people use the same objects, the scenes that our community
> produces could become pretty repetitive.

My proposal would be to have as few actual #declares as possible and instead
rely on macros to assemble components together.  This way, we'd get highly
parametrized objects/pigments/finishes/normals/color_maps etc.  It could
also benefit by encapsulation inside the macro, so that less naming
conflicts would happen.  Macros also allow far more randomness because
objects are created each time, and each time you could feed a different
"randomness" parameter or global variable to the macro...

Textures separate from shapes as well, after all, i could always want a
chrome potato instead of a boring everyday one. :)

> For example, using #local in include files wherever you don't need to expose
> them externally.

i just wish #local would also be local to macros.  oh well...

> Nevertheless, because it
> was standard I could do a case sensitive global change and was able to
> quickly change all my PS's to SC's.

in fact, this could be handled by a script server-side, by attributing
string IDs to contributions and prefixing #declares and macros
automatically.  Of course, caution should be made for not letting 2 letter
prefixes suddenly become 8-letter ones and very java like...

Still, i take it none of you want deeply nested well-organized directory
structures, ain't it true?  I really don't agree with just IDs and prefixes
and think a well-organized hierarchical directory structure for includes
should pay off in the long run.

> I don't think I'd agree with the idea to take naming standards to the level
> of requiring macros to contain the word 'Macro' in the name.

in the case of macros specifically, it seems a tradition in the povray
community to use make_foo patterns.  I like it. :)

> Florian raised the point that having a standard for sizes and names can make
> it less likely that someone put's his objects/textures/whatever in the
> collection, because it's too much hassle. Maybe a solution to this is that
> we document a standard, but don't insist people use it. We could have an
> indicator on the web site to show whether a particular submission adheres to
> the standard. This would also enable older and non-compliant files to still
> be published, but users would be forewarned about maybe having to sort out
> conflicts. From time to time we could drive campaigns to help standardise
> the most popular and well-used materials.

this all seems more of a hassle than to standardize it before submitting in
the first place. :)

Standard metrics-compliant include files could merely declare a known and
standardized flag variable to state they're compliant.

> On the subject of Object Diversity I think we could probably come up with
> some best practices that would help people to write #include files in a
> parametrised way that permits people using the file to readily adjust as
> much as possible.

heh.  I just realized indeed many people in the povray community use include
files as some sort of glorified macro, #declares as parameters and several
#includes of the same file if several "instances" of the same object is
needed.  And it really makes sense, since macros don't really come with
local scope... although kludgy...

Post a reply to this message