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

Charles C wrote:
> 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).


That's exactly what I meant.  For such a collection to be really useful, 
I believe that standards would be a necessity in order to facilitate 
usability.  Of course, if people don't want to conform to the standards, 
then you could still reference their files (or even host them on the 
server), but they should be kept separate from the main archive.

...Chambers

Post a reply to this message

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

Overall I am strongly in favor of some system whereby the only things exposed
from a specialized object or macro include file are those things the author
intends to expose, that is, by explicit declaration. C++ uses namespaces,
perl uses modules, other languages have their own ways; whatever, the point
is intelligent management of exposed symbols.

[nemesis]
> i just wish #local would also be local to macros.  oh well...

Recall I mentioned changes to SDL are possible. Not necessarily the above,
perhaps, but something that gives us the same effect. Basically if enough of
you think it's needed, tell me and we'll give it some thought. Some things
might not be possible with the current parser but we'll at least consider it.

-- Chris Cason

Post a reply to this message