John VanSickle <evi### [at] hotmailcom> wrote:

> 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.
>
> This is probably best addressed with a simple line at the start of the
> macro or scene file:
>
> // -- uses centimeter scaling

Heh, I use different measurement systems depending on what seems appropriete
for the thing I'm making.  I've said it in another post, but I do think that
scaling (& re-orienting) objects to fit your scene is just a fact of life.

BTW, I do also tend to use 1cm = 1 unit.

Post a reply to this message

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

Charles C wrote:
> Ben Chambers <ben### [at] pacificwebguycom> wrote:
> 
>> 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 think it all depends on what we're building here.  Something like a
> professonal product containing the best of the best, or a community effort
> containing some things that might not be as up-to-snuff as others.  If this
> were a for-sale package, it'd be most professional to have everything be as
> uniform as possible.  On the other hand, if it were up to me I'd like to
> think of this thing to be a little more inclusive.  I think we'll be hard
> pressed to find a single standard that won't turn most people away.  So,
> I'd lean more towards guidelines, and tutorials on how to make #includes
> "nice," kinda like what Chris B was talking about.
> 
> Charles

My reasoning for a well worded standard was because I was picturing this
becoming something like a STL for POV-Ray. When picking and choosing
certain includes, overlaps in variable and item names might not show up.
But we can't test every possible combination and they will show up
eventually.

This doesn't mean we can't have 'submitted includes' and 'standard
includes'. If this all falls under an open source license then we can
always fall back on the old 'if you want a non-standard include to work,
change it yourself.' Call them beta includes, even put them in a
separate zip file just to keep them apart. That way, anyone who wants to
put their code into this package can without editing anything if they do
not want to.

Post a reply to this message

Sabrina Kilian <ykg### [at] vtedu> wrote:
> My reasoning for a well worded standard was because I was picturing this
> becoming something like a STL for POV-Ray.

me too!  or boost! :)

> When picking and choosing
> certain includes, overlaps in variable and item names might not show up.
> But we can't test every possible combination and they will show up
> eventually.

some name mangling or aliases for simple namespace separation could be cool
if povray supported it...

Post a reply to this message

Hi all!

I just made an annotated include file which contains a single macro for
rendering a ruler using only '#local's - no '#declares'.  The tick-marks
and the numbers are in terms of its own metric.  The object could be
inserted into any scene.

Excerpt:

// Usage:
//  ruler( len[float], wid[float], dir[float[0, 1, 2, 3]],
font_name[string], font_scale[float], tick_interval[float[integer]],
tick_thickness[float], number_interval[float[integer]] )

Is there an appropriate place for me to upload the file on this site or
someone to whom I could e-mail it?

-Randall

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> Is there an appropriate place for me to upload the file on this site or
> someone to whom I could e-mail it?

right now you can upload it to the scene sources povray newsgroups.  If our
discussions in these threads lead anywhere, in the near future there will
be an area in the povray web site for people to upload include file
contributions...

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote in message 
news:web.456c30f447def5ca8c37caaf0@news.povray.org...
> Hi all!
>
> I just made an annotated include file which contains a single macro for
> rendering a ruler using only '#local's - no '#declares'.  The tick-marks
> and the numbers are in terms of its own metric.  The object could be
> inserted into any scene.
>
> Excerpt:
>
> // Usage:
> //  ruler( len[float], wid[float], dir[float[0, 1, 2, 3]],
> font_name[string], font_scale[float], tick_interval[float[integer]],
> tick_thickness[float], number_interval[float[integer]] )
>
> Is there an appropriate place for me to upload the file on this site or
> someone to whom I could e-mail it?
>
> -Randall
>

Not yet, we're just trying to hammer out how we would the area under 
discussion to work.
I suspect it'll take a couple of weeks to let everyone have a say and arrive 
at a concensus, then we'll need to run it by the webmaster (Chris Cason) to 
see if what we've decided we'd like to do is viable on povray.org. Then, 
setup could take days or weeks, depending upon whether we need to create 
server-side scripts or anything sophisticated for submission, indexing, SDL 
validation etc.

There is the povray.binaries.scene-files newsgroup that you could use to 
publish your include file in the mean time.

Regards,
Chris B.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
>                                                                    If our
> discussions in these threads lead anywhere, in the near future there will
> be an area in the povray web site for people to upload include file
> contributions...

I know.  Don't you love the self-referential irony? "There's a hole in
the bucket..." ;)

Thank you, nemesis.  I'll post it there now.

-Randall

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> 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.

I was responding in the context of what I read Ben Chambers to be saying...
Ben, you tell me if this is right...  If I read it right, by "sticking to
our guns" I think Ben meant non-optional standards.  So, submissions which
do not follow x-standard should not be accepted at all, (Is that what you
meant Ben?) and that those who want to share something non-standard can do
so the old-fashioned way, (i.e. on the newsgroup or on their own web page).

I like standards, don't get me wrong.  I think in terms of making standards
for my own stuff too.  In a community thing where participation isn't
always easy to come by I think some flexibility is important.  Forcing a
few additions like adding flags is a lot easier than say, turning a dozen
related files into hundreds in order to qualify.

Charles

Post a reply to this message

Proposal to address the metrics issue using "Scene Ruler Objects"

I don't know how to cross-post.  I would have if I did know.  So, I'll be
brief instead:

Please read subject "Scene Ruler" in povray.binaries.scene-files, authored
by myself.  If the team decides that "scene rulers" are the way to go, then
I'll volunteer my services.

Also, I need some instruction on cross-posting.

Post a reply to this message