From: Charles C
> Since Chris Cason mentioned it would be possible to make minor changes before 3.7
> final, I wonder how hard it would be to give .ini files the option to tell
> POV-Ray to search all sub-directories of a given directory."

I also have a suggestion, now that we're at it:  is it much hard to give
macros proper local scope for #local variables?  If it is, i guess the
practice of using the whole include file as a big macro will carry on...

From: Charles C
> I'd prefer at least some hierarchy.

Keywords are cool for searching, but not for organizing code.  Chris B
suggested having few main areas of interest as high-level branches and i'm
with him.  I'd also suggest each contributor having a short prefix
associated, so if, say, nem or chc both contribute cedar textures, it
should come like this:
textures/wood/nem_cedar.inc
textures/wood/chc_cedar.inc

or something.  The prefix would be automatically generated by a server-side
script taking into account the contributor's login or email or something.

From: Ben Chambers
>That's worse than having no standard, because then you have to check
> whether or not its standardized...
> My opinion is, you make a standard, and stick to your guns.  People are
> still free to make their own files, and distribute them the
> old-fashioned way, so noone's really losing anything.  But for such a
> collection to be useful, standards are the way to go."

I wholeheartdly agree.  People may or may not use the proposed standard and
may or may not benefit from it.  Nobody loses and people wanting a
standard gain a lot from it.

I proposed having a flag variable declared in each include file following
the standard, something like:

#declare USE_STD = yes;

Include files not following it simply don't have such flag and scenes
including the files can check if they follow the standard or not, like:

#include "landscapes/desert/nem_sand.inc"
#ifdef( USE_STD )
......
  #undef USE_STD // <- important!
#else
......
#end

From: Ben Chambers
> 1) Each include file deals with only one object / texture / function /
whatever (see #5 below for an exception).

fine by me

> 2) No hard-coded sizes, everything must be parameterized.

I don't think a default size would be bad, specially if we are able to
standardize the metrics.  Still, this is povray we're talking about, where
potatoes can be 50 meters tall and have chrome texture! :)

On the subject of sizes i believe it'd be good if people took their time to
scale contributed objects to fit either height or width to 1 unit, whatever
it is.  Because then, if i want it to have a 3 meter paper clip, i simply
scale it like "scale x*3" given the 1 unit fitting scheme used the width of
the object.

While we're at it, we live in a gravity centered world and generally objects
are not floating around, but lying into yet other objects.  I'd suggest
placing objects upon the origin, that is, the common bottom of the object
resting in y*0.  Like chairs resting on their feet or an egg lying to its
side.

> 3) All items should be generated by a macro for consistency.  If all
> you're doing is declaring a texture, still generate it by macro to match
> the consistency of everything else in the archive.

exactly!  and it brings composition and some randomness to the forefront.

> 4) The name of said macro should be identical to the file name, but for
> heaven's sake, avoid Hungarian notation like the plague it is!

for macros, the make_foo pattern is cool enough.  But personally, i
generally go for t_tex1, fn_fin1, p_pig1, n_nor1 and the likes for other
name patterns... I'd have to change to more closely match the CamelCase
style used by most povvers. :)

> 5) Where it makes sense, objects that can take advantage of
> randomization should come in two flavors: a basic one, with no
> randomization, and a random one (append the macro with _r if you must)
> which accepts as an additional argument, a random number stream.  This
> allows you to use your own random streams in the object creation process.

very good!

what about a level-of-detail parameter?  like, 1,2,3 for basic, medium,
complex?  or is it too much?  am i thinking too much ahead?

From: John VanSickle
> I already do this with my Subdivision Surface macros; everything starts
> with SSS or sss.

oh noes!  what about macros dealing with SubSurface Scattering?! ;)

> Probably the biggest issue is that while many people around here use 1
> unit = 1 meter, others (such as I) use 1 unit = 1 cm for most scenes.

how about:
#declare UNIT = m;
or
#declare UNIT = cm;

as a way to explicitely declare your intentions for standard-compliant
scenes?

> And we can put code in the #ifndef-#local-#end block to detect if any of
> the defaults are changed, and print out "Use some imagination!" if none
> of them are changed :-)

lovely idea! :)

From: Randall Sawyer
> in a rendered scene, all real-world
> metrics are virtual and exist only in the mind of the author of the scene
> or that of the viewer.

yes, but nothing should prevent the author of putting some default in there
and people from using such default.

> what if the objects in publicly shared include files
> are initially intended to be viewable in a scene with an 'orthographic
> camera' with 'up' and 'right' vectors which correspond to a standardized
> render window - say < 0, 480, 0> and < 640, 0, 0 > respectively?

I think this is out of scope in the discussion, because we're talking about
metrics, size and placement standardization.  hopefully, lighting standards
could also come by...

yes, people viewing an object up close or very far away will have no notion
of metrics involved.  But the metrics standard should not be there for an
object alone, but to correctly relate it to other objects following such
standard.


From: Charles C
> I think we'll be hard
> pressed to find a single standard that won't turn most people away.

How something optional like the metrics standard could possibly turn people
away?  I say, let people wanting a metric standard to discuss metric
standard matters, let people wanting to address other issues address other
issues and let people just wanting to contribute something they created
contribute it without any metrics consideration whatsoever.

Post a reply to this message