This is a third follow-up to the thread "povray standard include files" to 
discuss development standards for a proposed area on povray.org for storage 
and distribution of a collection of objects and other files, contributed by 
the POV-Ray community. 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.

As Sabrina has mentioned, there are certain standard ways of doing things 
that can help us to construct #include files that will work together and 
also minimise compatibility issues with future versions of POV-Ray. For 
example, using #local in include files wherever you don't need to expose 
them externally. Also starting variable names, macro names etc. that are 
exposed with an upper case letter to avoid potential conflicts with future 
POV-Ray keywords.

I think Sabrina's idea of using a unique prefix for names is a good one and 
I've used this in the past, for example, all POV-Stairs variables exposed 
externally start with SC (for StairCase). Interestingly I started using PS 
but found that someone elses include file used PS. 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. The lesson here is that using a standard 
makes life easier than not using a standard, even if the detail needs to 
change.

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. I suspect that 
going back and retrospectively adjusting some of my own #include files would 
be cumbersome. For example, there are lots of macros in the various 
POV-Person #include files and they're mentioned all over the place in the 
documentation. Anything that needed doing to the names that couldn't be done 
with a global change would absorb lots of time (although Hungarian notation 
might work).

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.

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. For example, using #ifdef() before #declare inside the 
#include file helps someone to override default settings within their scene 
file. Rather than writing that sort of thing into our standards, I would 
propose that we assemble (or reference if some already exist) a few 
tutorials that illustrate how to build include files that enable a diverse 
range of objects to be generated.

Regards,
Chris B.

Post a reply to this message