 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles C wrote:
> 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.
Here's an option:
Have two sections of the library: the 'standard', and the 'ad-hoc' one.
Everything goes into 'ad-hoc' to start with, until an administrator checks
it. If it meets the standard, it goes into the standard area. If it doesn't,
it either (a) stays in ad-hoc, (b) gets wrapped (see below) and moved into
standard, or (c) gets deleted.
Given a license that permits modifications or derivative works, if a macro is
good enough that it really should be in the standard area, but the author
didn't do it for some reason, a volunteer could encapsulate it within a
standards-compliant wrapper. Presuming support for some sort of private
namespace (or the equivalent thereof) is available, this would not always
require going though the entire file line by line.
Also I will mention that it is possible we could have a parser that reads SDL
and re-writes it according to a set of rules. I'm not about to volunteer to
do this but consider it as one possible means of handling issues that might
otherwise require run-time support within the distributed POV-Ray.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
FWIW I'd suggest some of you investigate how the Perl folks have handled
this, since they've gone through some of the same issues. While it is for
example possible to include a file into a perl program just like we do with
#include, they have another concept called 'modules' which covers some of the
issues here, plus some others that we haven't covered yet (e.g. modules can
be self-documenting). See:
http://en.wikipedia.org/wiki/Perl_module.
http://stein.cshl.org/genome_informatics/chervitz/perl-modules/
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote:
> 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.
> ...
> I'd lean more towards guidelines, and tutorials on how to make #includes
> "nice," kinda like what Chris B was talking about.
Chris Cason <del### [at] deletethistoo povrayorg> wrote:
> Have two sections of the library: the 'standard', and the 'ad-hoc' one.
> Everything goes into 'ad-hoc' to start with, until an administrator checks
> it. If it meets the standard, it goes into the standard area.
I like the direction in which this discussion is heading.
My personal preference is for #macro includes with a parameter each for size
or texture-density where appropriate. I just got done rewriting my personal
includes, eliminating all #declares. My headers now have two new lines:
// Manifest: #macro_1, #macro_2, ...
// Dependencies: "file_1.inc", "file_2.inc", ...
BTW: I'm more of a hands-on learner. So, this exercise served to inform me
better in participating in this discussion. It is not my intention to
promote my personal standard. I share it only as an example.
I would still like to promote my "scene ruler" #macro-generated objects for
use by the 'ad-hoccers' who want to make their textures and such available
via #declares (assuming we do end up with an 'ad-hoc' area).
Also, I'd be happy to help with the tutorials.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> FWIW I'd suggest some of you investigate how the Perl folks have handled
> this, since they've gone through some of the same issues. While it is for
> example possible to include a file into a perl program just like we do with
> #include, they have another concept called 'modules' which covers some of the
> issues here
Chris, i guess having proper lexical scoping helps a lot in getting true
module/package/unit/namespace...
The SDL right now just has global variables and per-file local variables.
Macro "local variables" seem like they are really just copied verbatim to
the location where the macro was followed, thus becoming local to the
callee file. Macros are indeed a strange mix of C preprocessing macros and
procedures/functions...
Still, i guess its too costly for a change right now, so i think we'd better
deal with it for a while -- hey, C is still around! -- and see what we can
do with this limitation in mind.
>, plus some others that we haven't covered yet (e.g. modules can
> be self-documenting). See:
talking about it, code is the best document there is! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> [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.
Keeping it simple is a must.
Namespaces are probably the best way. Ideas:
* #namespace LABEL creates the namespace LABEL if it doesn't already
exist. Whether new or not, namespace LABEL becomes the active namespace
(the former namespace is saved on a stack).
* #namespace undef pops the current namespace off of the stack, and the
former namespace becomes active.
* All #declare and #local statements affect the variable in the current
namespace. Other variables of the same name in other namespaces are not
affected.
* #declared variables live from one invocation of the namespace to the
next, but #labeled variables die when the namespace passes out of scope
(end of macro, end of file, popped by #namepsace undef statement).
* The arguments of a macro are, within a macro, always in scope,
regardless of the active namespace.
This way if I write a set of macros for simulating physics (called the
Phony Physics Pholio), I can put
#namespace Phony_Physics_Pholio
at the start of every macro, and thereby minimize conflicts with other
macros sets by other authors.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> Chris B wrote:
>
>> 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.
>
>
> This is something that C/C++ programmers (and others as well) know:
> Don't use globals unless you really, really have to.
>
>> 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 already do this with my Subdivision Surface macros; everything
> starts with SSS or sss.
Just some ideas from my personal coding standards...
I make all #declared items uppercase with a three-letter descriptive
suffix; anything in an #include file gets a two- or three-letter prefix
as well. For example, a weathered oak texture in the hypothetical
Outhouse.inc file would become OH_WEATHERED_OAK_TEX, a corncob would be
called OH_CORNCOB_OBJ, and so on. #local items are similar, but with
upper- and lower-case: BoardShapeObj, CorncobLength, and so on. A
#macro would be named something like macOH_MakeCorncob.
Any macro is preceded by a nice comment box, along the lines of...
////////////////////////////////////////////////////////////////////////
// macOH_MakeCorncob--Creates a corncob to be placed in the corncob box
// in the "Outhouse" project.
//
// Parameters:
// CorncobLength = Float; length of corncob.
// CorncobDiameter = Float; diameter of corncob.
// TrimEnds = Boolean; true = ends of corncob are trimmed
// false = ends are untrimmed
// default = false
////////////////////////////////////////////////////////////////////////
...and gets an "// end macOH_MakeCorncob" comment at the end.
(Yes, I know it's a silly example ;) I also tend to do things like
naming a function to create a pink pigment PinkPigFun. And so on. I
just can't help myself.)
>
>> 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.
>
>
> 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
>
I wonder if some sort of generic unit conversion code might be posted on
the site, to allow coders to use the units they find most appropriate,
while simplifying end-users' ability to mix-and-match #include files...?
>> 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.
>
>
> Well, I use an #ifndef-#local-#end block, and it works fine. My robot
> models have a default texture for different things; in fact, there is
> also a BotGender variable that specifies which of two defaults gets used.
>
> 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 :-)
>
> Regards,
> John
I use a block like...
#ifndef "_MyInclude"
#include "MyInclude.inc"
#declare _MyInclude = 1 ;
#end
...to avoid re-#including files in big projects with lots of #includes,
and things like...
#ifndef "_TestMode"
#declare _TestMode" = false ;
#end
...to set global parameters. I imagine everybody has a collection of
these code snippets to share.
--Sherry Shaw
--
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}// TenMoons
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> Namespaces are probably the best way. Ideas:
>
> * #namespace LABEL creates the namespace LABEL if it doesn't already
> exist. Whether new or not, namespace LABEL becomes the active namespace
> (the former namespace is saved on a stack).
>
> * #namespace undef pops the current namespace off of the stack, and the
> former namespace becomes active.
Rather than that, why not just utilize
#namespace
with no arguments, to return to the global namespace?
> * All #declare and #local statements affect the variable in the current
> namespace. Other variables of the same name in other namespaces are not
> affected.
>
> * #declared variables live from one invocation of the namespace to the
> next, but #labeled variables die when the namespace passes out of scope
> (end of macro, end of file, popped by #namepsace undef statement).
You mean #local items, right?
I think namespaces are the perfect way to go, especially as the
community using POV-Ray matures in their code-writing efforts.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sherry Shaw <tenmoonsPutAtCharacterHereaol-dot-com> wrote:
> John VanSickle 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
> >
>
> I wonder if some sort of generic unit conversion code might be posted on
> the site, to allow coders to use the units they find most appropriate,
> while simplifying end-users' ability to mix-and-match #include files...?
If anybody's interested, Sherry your comment inspired me to make a little
macro which is expandable, but currently can convert any combination of
"mm", "cm", "m", "km", "in", "ft", "mi". I posted it here, and then as
usual found a minor error in a #debug statement & then re-posted. I
wouldn't mind contributing this, realising it may need modification to fit
the standard we come up with. Any comments for improvement?
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.4570c25ad5e52cf5e451c5d90%40news.povray.org%3E/
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Re: CSG fonts
I have an interest in developing and exchanging CSG fonts and CSG
font-formatting tools. I have proposed adopting a standard for such
objects and macros in this thread:
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.456ff0468ffcc40c7cac52a50%40news.povray.org%3E/
{ Please pardon my newbiisms and my footprints on a well-worn path, but
take seriously my proposal to adopt some sort of CSG font standard. }
In a nutshell: I think it would be wise for default CSG font objects to
emulate default 'text{}'-generated objects. And, I think it would be wise
to adopt a standard array structure to contain CSG fonts to allow for
portability among formatting tools.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers wrote:
> John VanSickle wrote:
>
>> Namespaces are probably the best way. Ideas:
>>
>> * #namespace LABEL creates the namespace LABEL if it doesn't already
>> exist. Whether new or not, namespace LABEL becomes the active
>> namespace (the former namespace is saved on a stack).
By this stack thing I mean that the fact of being active is kept saved
on a stack.
>> * #namespace undef pops the current namespace off of the stack, and
>> the former namespace becomes active.
>
> Rather than that, why not just utilize
> #namespace
> with no arguments, to return to the global namespace?
But there file or macro may return to code that had a different
namespace active; returning to the global may mess that up.
To go to the global, there should probably be a keyword for it so that
the scene coder gets a chance to know what he's doing.
>> * All #declare and #local statements affect the variable in the
>> current namespace. Other variables of the same name in other
>> namespaces are not affected.
>>
>> * #declared variables live from one invocation of the namespace to the
>> next, but #labeled variables die when the namespace passes out of
>> scope (end of macro, end of file, popped by #namepsace undef statement).
>
> You mean #local items, right?
Yeah, I meant #localed instead of #labeled.
> I think namespaces are the perfect way to go, especially as the
> community using POV-Ray matures in their code-writing efforts.
I was trying to come up with something that is easy for the SDL user to
understand (which means something far less complex that C++ namespaces),
and which seems to be relatively simple to implement.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sherry Shaw wrote:
> I wonder if some sort of generic unit conversion code might be posted on
> the site, to allow coders to use the units they find most appropriate,
> while simplifying end-users' ability to mix-and-match #include files...?
I tried to whip up a set of macros which allow a model designer to
specify what units they're using, and another set which allows the scene
designer to specify the units for the scene. The two macros would work
together to properly scale the object for the scene.
But making it sufficiently idiot-proof was too cumbersome, so I
abandoned it to make time for playing Diablo.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> Re: CSG fonts
A brief update:
I released an improved (streamlined) version of my CSG Fonts standards
package. To see it, please go to:
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.456ff0468ffcc40c7cac52a50%40news.povray.org%3E/
Posting #6
Thank you,
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Usage Protocol
Chris Cason wrote:
> Recall I mentioned changes to SDL are possible.
John VanSickle wrote:
> Keeping it simple is a must.
>
> Namespaces are probably the best way. Ideas:
>
> * #namespace LABEL creates the namespace LABEL if it doesn't already
> exist.
.......
Would it be helpful to establish a way to view the 'usage text' of a macro
without having to load its entire include file into an editor?
One solution would be to require a
#declare foo_usage = 'string literal'
for each
#macro foo( 'parameters' )
in every standardized include.
One draw-back to this approach though, is the current 256-character limit.
Some sort of 'usage protocol' would be helpful in the development of
specialized POV-Ray editors too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Randall Sawyer wrote:
> Would it be helpful to establish a way to view the 'usage text' of a macro
> without having to load its entire include file into an editor?
>
> One solution would be to require a
>
> #declare foo_usage = 'string literal'
> for each
> #macro foo( 'parameters' )
A better solution (and avoiding the 256 character limit) is a simple
#declare help = true; // uncomment this to print help text
// #declare help = false; // uncomment this to suppress help text
in the main file. Then, in your include files, do a
#if (help=true)
#debug "Macro: make_widgets(PIPES, CHRONOTRONS) by Chris O'Donnell.\n"
#debug "Usage:\n"
#debug " PIPES should be a vector representing the color of the
widgets.\n"
#debug " CHRONOTRONS should be a string literal to be printed in the
uppper left corner of the screen.\n"
#end
Or something along these lines, customized for each macro :)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> #declare help = true; // uncomment this to print help text
> // #declare help = false; // uncomment this to suppress help text
Nice :)
I have something specific in mind though...
I'll post a new thread, since I think I'm about to go a little off-point
from this discussion. I'll call it "POV Editors".
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Randall Sawyer wrote:
> Would it be helpful to establish a way to view the 'usage text' of a macro
> without having to load its entire include file into an editor?
>
> One solution would be to require a
>
> #declare foo_usage = 'string literal'
Have a look at perl .pm files. they use a special form of markup to make the
documentation. e.g.
http://world.std.com/~swmcd/steven/perl/module_pod.html
real-world example:
http://search.cpan.org/src/WADG/GD-Graph3d-0.63/lib/GD/Graph3d.pm
It also handles things such as dependencies etc. In POV there's no reason why
we could not use specially-formatted comments. (This is already regular
practice for C++, with various docgen tools helping to fill it out).
if a similar system was in place with POV, there's no reason why a POV editor
can't pick up the info automatically and show help for a macro (particularly
when typing in the definition to use it).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> * #namespace LABEL creates the namespace LABEL if it doesn't already
> exist. Whether new or not, namespace LABEL becomes the active namespace
> (the former namespace is saved on a stack).
>
> * #namespace undef pops the current namespace off of the stack, and the
> former namespace becomes active.
>
> * All #declare and #local statements affect the variable in the current
> namespace. Other variables of the same name in other namespaces are not
> affected.
my personal opinion is that namespaces should have block scope (so are
delimited by a specific start and end, either with braces or a # declaration
of some sort). preferably with braces.
also namespaces must be properly nested within a source file; if you open a
namespace in a file, it must be closed before EOF in that file. otherwise you
run the risk of loading a include file and finding the current namespace has
changed afterwards.
finally, if we're going to change the way macros work with respect to scope,
we're better off changing them entirely (otherwise we run into compatibility
issues) and coming up with a new name for them (i.e. not #macro).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
my 2 cents:
We should not forget povray is heavily used by non-programmers and adding
more stuff -- like more syntax items or heavy-handed standards -- may put
some of these people down...
The main problem is naming collisions. This problem may not even require
adding more syntax, but just handle the #include more gracefully -- perhaps
as a rewrite rule indeed.
Today, when I #include a file, its declarations may conflict with previous
ones. When such a thing happens, povray should *warn* the user and suggest
using an alias for the included file and access its contents via the alias.
i.e., supposing both includes declare a make_bike:
#include "nem_bike.inc" #as nem // bike by nemesis
#include "jvs_bike.inc" #as jvs // bike by John VanSickle
object { nem_make_bike() translate -x*5*m }
object { jvs_make_bike() translate x*3*m }
If #as isn't used, it behaves just like regular #include... of course,
include files in the include files repository could be preprocessed like
that to make the uniquely prefixed by the author's login initials...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> We should not forget povray is heavily used by non-programmers and adding
> more stuff -- like more syntax items or heavy-handed standards -- may put
> some of these people down...
I think I've got it!
In our ini files, each of us has default settings for variously-leveled
parameters:
image resolution, render quality, antialias tolerance, etc.
Why not have a tiered system whereby each user can establish how strictly or
loosely they want there includes governed?
Then, when the collection is up-and-running, the subgroups in the collection
could reflect the include regulator levels in the ini file.
If someone with strict standards really wanted to use something from a more
casual source, then it's caveat emptor.
Also, I think that the "#include ... #as" idea is more dynamic and flexible
than the #namespace approach.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> Today, when I #include a file, its declarations may conflict with previous
> ones. When such a thing happens, povray should *warn* the user and suggest
> using an alias for the included file and access its contents via the alias.
>
My worry would be about files that are expecting to see a global variable by
one name and get the prefixed version instead. It seems like the scope of
#as would have to cover any files that the #included file depends on.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote:
> My worry would be about files that are expecting to see a global variable by
> one name and get the prefixed version instead.
but the alias is given by the user of the include file in his own file. So,
the prefix is necessary and he is well aware of it, since it was him who
named it in the first place.
> It seems like the scope of
> #as would have to cover any files that the #included file depends on.
perhaps an example could illustrate the situation better?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Re: #include ... #as
Assuming that every include file's name is unique, then the real concern is
the names of the #macros and #declares within. What about some sort of
name registration process along the lines of domain-name registration?
Once an include is accepted, then the names of its #macros and #declares are
nolonger available within later include files.
One approach which might make this process more manageable, would be to
require that each #macro/#declare name contain an abreviation which
identifies the type of object it returns ( light_source => foo_ls, texture
=> foo_tx, CSG => foo_cg, mesh => foo_mh, etc.).
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> "Charles C" <nomail@nomail> wrote:
>> My worry would be about files that are expecting to see a global variable by
>> one name and get the prefixed version instead.
>
> but the alias is given by the user of the include file in his own file. So,
> the prefix is necessary and he is well aware of it, since it was him who
> named it in the first place.
>
>> It seems like the scope of
>> #as would have to cover any files that the #included file depends on.
>
> perhaps an example could illustrate the situation better?
>
>
>
If I understand correctly, the proposed #as would do what, add a prefix
to everything that the include makes available to the outside?
Okay, there would be two ways of handling the following:
#include "nem_bike.inc" #as nem // bike by nemesis
Everything in just bike.inc is prefixed with nem. If bike.inc includes
another file, are those prefixed or not? If not, we run the risk of name
overlap again because those items are probably going to be less likely
to be checked. If they are, how will bike.inc know what variable names
to call?
Will #as tags stack like namespaces, or when a new one is created is the
last one automatically closed?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> One approach which might make this process more manageable, would be to
> require that each #macro/#declare name contain an abreviation which
> identifies the type of object it returns
yes, yes, i believe this kind of "Hungarian Notation" is used by most
povvers. But if we require that each include file #declare gets prefixed
by a unique identifier, we'll endup with limits to the number of include
files and it is indeed too confusing. Why can't i call my make_bike macro
simply make_bike within my own include file? Just because the name will
clash with someone else's make_bike? This is why i like aliases, since
they allow us to decide what to call someone else's #declares...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina Kilian wrote:
> If I understand correctly, the proposed #as would do what, add a prefix
> to everything that the include makes available to the outside?
FWIW, in my experience, by the time the conversation gets to this level,
progress has stalled to the point where nothing will get done because
it's never perfect enough to start. Given that there isn't, at this
time, any sort of problem along these lines, and given that the
repository is a source-code repository with a license that allows such
things to be fixed if it becomes a problem, it's probably better to get
started, rather than to wait for POV-Ray to be improved to the point
where a giant repository could be compiled without assistance.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Perhaps a better solution, to avoid both namespace collisions and
automatic name mangling, would be to add a new object type, the
'container'. It would work something like this:
#declare stuff = container;
#declare stuff.x = 5;
#declare stuff.loc = <3,4,6>;
#declare stuff.ball = sphere {0,1}
Basically, the container acts as a namespace on its own. Each include
file could use a container for its variables and declarations, except
for those it needs exported globally.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
From: Sabrina Kilian
> If I understand correctly, the proposed #as would do what, add a prefix
> to everything that the include makes available to the outside?
Prefixing should be an easy option than to actually mess with povray's
parser to really cope with lexical scoping.
> #include "nem_bike.inc" #as nem // bike by nemesis
> Everything in just bike.inc is prefixed with nem. If bike.inc includes
> another file, are those prefixed or not?
If bike #includes a file and gives it an alias, that alias should actually
be of #local scope. So, the #included items should only be visible inside
bike.inc.
Perhaps you're making confusion between #including bike's contents to your
file and the contents bike.inc #includes from other files? The latter
should not be visible outside bike.inc. I'm guessing povray's parser
could give a help by handling it transparently like:
/* bike.inc */
#include "nuts_and_bolts.inc" #as nuts
This would be handled by povray's parser as follow: create in bike.inc
prefixed #locals for each #declared items in nuts_and_bolts.inc. Will it
work? I don't really know, but it's an idea.
From: Darren New
> FWIW, in my experience, by the time the conversation gets to this level,
> progress has stalled to the point where nothing will get done because
> it's never perfect enough to start.
Yes, i agree. But give it some more time for more people to have some input
into this discussion. Some planning can never hurt, only if remains just
planning...
> it's probably better to get started, rather than to wait for POV-Ray to be
> improved to the point where a giant repository could be compiled without assistance.
I'm also eager to get it going! :)
From: Ben Chambers
> Perhaps a better solution, to avoid both namespace collisions and
> automatic name mangling, would be to add a new object type, the
> 'container'. It would work something like this:
#declare stuff = container;
#declare stuff.x = 5;
#declare stuff.loc = <3,4,6>;
#declare stuff.ball = sphere {0,1}
hmm, whatever happens if i #include a file that #declares a "stuff"? :)
> Basically, the container acts as a namespace on its own. Each include
> file could use a container for its variables and declarations, except
> for those it needs exported globally.
Actually, your container looks remarkably similar to an "class instance"...
but, how is the container any different from a #macro? They look the same,
except you have to prefix each variable with the "macro" name.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hello, here's some more food for thought regarding aliased includes:
/* test.pov */
#include "test1.inc"
light_source { 4-8*z 1 }
object { test1_sphere
//texture { t_sph }
//texture { test2_t_sph }
translate z*5
}
/* test1.inc */
#include "test2.inc"
#local test2_t_sph = t_sph // <- *1* povray parser makes included declare
local to this file...
#declare test1_sphere = sphere { 0, 1
texture { test2_t_sph } // <- ... we use it prefixing with our
chosen alias ...
}
#undef t_sph // <- *2* ... and undef all included #declares at the end
/* test2.inc */
#declare t_sph = texture {
pigment { rgb y }
finish { diffuse .6 phong .9 phong_size 50 }
}
It works well. If you uncomment the given textures in test.pov, it won't
render, since the symbols are hidden as expected.
So, if povray's parser gives us a help in making steps *1* and *2* a
reality, we can get better symbol scoping with very little effort.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
As I've shared before, I am a hands-on learner. So, I have set up an actual
scenario for myself to experiment with. I would also like to share it with
all of you.
I am posting an attachment at povray.binaries.scenes-files (look for
Standards Challenge). It is a folder called "SRS.StandardsChallenge". In
the folder are three files: "povver1.inc", "povver2.inc" and "scene.pov".
In the first file, there are definitions for the #macros "ball", "rod" and
"block" as well as a definition for the macro "p1_donut".
The second file contains definitions for the #macros "ball", "rod", "block"
and "p2_donut".
The scene file calls the #macros "ball", "rod", "block, "p1_donut" and
"p2_donut".
By reversing the order of the two #include lines in "scene.pov", you get a
different result.
The challenge is to use existing POV-Ray SDL to modify the three files,
presenting them as two (rewritten) *.inc files and eight *.pov files - one
for each possible outcome.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Solution to Challenge: Is it generally extensible?
You can download my solution to my own challenge at aforementioned site.
Here is what I came up with:
In "povver1.inc":
On the first line:
// Use #declare whose = "povver1"
On the two lines immediate preceeding any #macros or #declares:
#ifdef ( whose )
#if ( !strcmp(whose, "povver1") )
*** macros and declares go here ***
On the two lines immediately following any #macros or #declares:
#end//(whose = "povver1")
#end//ifdef(whose)
In "povver2.inc":
The same as in "povver1.inc", replacing "povver1" by "povver2"
In any scene file:
#declare whose = "povver1"
#include "povver1.inc"
stuff from "povver1.inc" you want to have in scene - modified or not
#declare whose = "povver2"
#include "povver2.inc"
stuff from "povver2.inc" you want to have in scene - modified or not
[ Nothing unique to "povver1.inc" file is lost, making it possible to
combine items from two-or-more include files. ]
Additional added value to this approach: Author recognition!
By requiring that every include file make use of '#declare whose', a
scene-writer will be making an acknowledgement of the original author from
whom
they are borrowing. It will be written into the text of their scene file.
Will this work? Is there something I'm missing?
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina Kilian <ykg### [at] vtedu> wrote:
> > "Charles C" <nomail@nomail> wrote:
>My worry would be about files that are expecting to see a global variable by >one
name and get the prefixed version in
stead.
>
> nemesis wrote:
> > but the alias is given by the user of the include file in his own file. So,
> > the prefix is necessary and he is well aware of it, since it was him who
> > named it in the first place.
> >
>
> Everything in just bike.inc is prefixed with nem. If bike.inc includes
> another file, are those prefixed or not? If not, we run the risk of name
> overlap again because those items are probably going to be less likely
> to be checked. If they are, how will bike.inc know what variable names
> to call?
>
> Will #as tags stack like namespaces, or when a new one is created is the
> last one automatically closed?
Yes this is what I meant. I was just trying to say includes called from
within includes would need to inherit the prefixes all the way down. That
way, they'll all be expecting to see variables that match. The only issue
I see is for example things like #ifndef(something) #include
"something.inc" #end might tend to duplicate things in memory.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote:
> Yes this is what I meant. I was just trying to say includes called from
> within includes would need to inherit the prefixes all the way down.
In my "#declare whose" model above, I didn't address includes calling other
includes.
I've been thinking about how folks would actually be using includes. Naming
conflicts will occur. But, I don't think we need to make them idiot-proof,
just manageable. This is the possibility I imagine:
Think of each include file as a locked room. On the door of that room is a
sign that tells you what key you need to get in ( whose ). It tells you
what's in the room ( Manifest ). It tells you what rooms it leads to (
Dependencies ).
If you are already in possesion of an item with the same name as something
on the 'Manifest' and you don't want to loose it, then declare it as
something else before you go in. While you're at it, check the 'Manifests'
of the 'Dependencies' as well, renaming anything you have that you might
need to protect.
Then, make the key (#declare whose = "the_key") and enter (#include
"the_room.inc"). Once you're in the room your key might change (an include
file including another). But, that doesn't matter. You're already in the
room and you don't need any key to get out.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay, I'll admit that the "#declare whose" idea was a bit silly. And I'll
admit that some of my ideas are made of cork. But, I've just been getting
them out there so that we can all find the one made of tungsten.
This one might be just in that direction:
As long as we're asking the parser to rename macros and declares at the
front end (e.g. #include ... #as), couldn't we just ask the parser to
rename them for us in the Backend. And to do so in a way that none of us
possibly could with our keyboards? There are ascii values that are
unavailable to us when we name macros; but, couldn't we make them available
to the parser? This is what I have in mind:
Okay, let's say there are a few includes you want to use in your scene.
Let's call these "first-level includes." You're familiar with them already
or you wouldn't be using them. So, you're obviously going to be able to
avoid naming conflicts from items in those particular includes.
Now, assume that one or more of them also call includes. Let's call them
"second level." And, some of those includes might call still more - "third
level" - and so on. That's where you might run into a naming issue. Who
wants to have to read all those other files?
So, what if the parser could keep track of its 'include depth' and its
'include count' and then give it a renaming algorithm so that every macro
or declare 'call' in the first level and every macro or declare
'declaration' in the second level is altered identically - using
parser-only characters. Once in the second level each call is altered
uniformly and identically to each declaration at the third level and so on.
I realize that the #ifndef() at the front of each include may interfere with
this strategy. (User includes "A.inc" and "B.inc" and "A.inc" includes
"B.inc". Parser thinks "already been there" and doesn't give you what
"B.inc" has to offer you.) That needs to be addressed.
Admittedly, the parser is a black-box phenomenon to me. I have not looked
at its source. So, I have a question: Could this method result in strings
of redundant macro code called by different names taking up too much memory?
If so, would a sort of staging area of compilation be appropriate upon
exiting an include whenever it is one that has called includes itself?
Well, that's the best I've got for now.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> But, I've just been getting
> them out there so that we can all find the one made of tungsten.
That's the whole point of this thread. And indeed perhaps none of them is
actually made of tungsten, but if we mix them in an alchemists way, we may
eventually get gold. :)
> some of those includes might call still more - "third
> level" - and so on. That's where you might run into a naming issue. Who
> wants to have to read all those other files?
No one wants naming conflicts: they are bad, very bad. That's why i
proposed having included items being local to the file including them. And
it really doesn't seem much difficult to make the parser handle it that way
and aliases.
> I realize that the #ifndef() at the front of each include may interfere with
> this strategy. (User includes "A.inc" and "B.inc" and "A.inc" includes
> "B.inc".
I believe such metaprogramming #ifdefs and whatnot should be in charge of
the parser, not the user. If includes are local, there should be no need
for them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> "Randall Sawyer" <sra### [at] yahoocom> wrote:
> > But, I've just been getting
> > them out there so that we can all find the one made of tungsten.
>
> That's the whole point of this thread. And indeed perhaps none of them is
> actually made of tungsten, but if we mix them in an alchemists way, we may
> eventually get gold. :)
>
> > some of those includes might call still more - "third
> > level" - and so on. That's where you might run into a naming issue. Who
> > wants to have to read all those other files?
>
> No one wants naming conflicts: they are bad, very bad. That's why i
> proposed having included items being local to the file including them. And
> it really doesn't seem much difficult to make the parser handle it that way
> and aliases.
>
> > I realize that the #ifndef() at the front of each include may interfere with
> > this strategy. (User includes "A.inc" and "B.inc" and "A.inc" includes
> > "B.inc".
>
> I believe such metaprogramming #ifdefs and whatnot should be in charge of
> the parser, not the user. If includes are local, there should be no need
> for them.
If you want the #declare of a sub-include to have local-status of a
current-level include, then that seems like it'd work just as long as the
#declare was meant to be used at a one-up level (one-up from the
sub-include). I've got a lot of stuff which I think this system would
break. It's seems hard to come up with a system that won't break
something.
How about different namespaces plain & simple, but with two additions: The
ability to define a global namespace, and the ability to combine
namespaces. If multiple namespaces are activated at once via a command
#namespace(Jake,Sam) the parser should automatically give an error if there
are conflicts. New #declares that are created when multiple non-global
namespaces are active will remain accessible to the individual namespaces.
#namespace (global) //brings scope up to global namespace only (default)
#include "colors.inc"
#namespace (Jake) //namespace Jake is defined and activated.
//global namespace is still accessible and therefore had better not conflict
with Jake.
#include "jakes_objects.inc"
#namespace (global) //brings scope up to global namespace only
#ifdef(jakes_doorknob)
#debug "huh? jakes_doorknob shouldn't be accessible now."
#end
#namespace (Jake) //switch back to jake's namespace as remembered by parser
#object{ jakes_doorknob pigment{White} }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
From: "nemesis"
> No one wants naming conflicts: they are bad, very bad. That's why i
> proposed having included items being local to the file including them.
That's what I was getting at - "local to the file."
I've been thinking "Who uses POVRay?" and "What is POVRay script?"
At this time, my answers are:
"POVRay users are individuals with active visual imaginations who want
to share their visions with the world - whether it be artistic, scientific
or mathematical."
and:
"POVRay script is a descriptive language, functionally equivalent to
HTML. The ability for users to define functions and macros and pre-defined
objects are meant as a convenience. These features enable a user to produce
variations on a theme. They also enable the graphical analog to the DJ's
craft of recording original mixes of sampled prior works."
Although the added functionality of POVRay makes it seem like a programming
language, let's not treat it as such. I recently downloaded TrollTech's QT
4.2 C++ library. They have a slogan: "Code less. Create more." I like
that ethic. Good software - whether its for publishing, software
development or ray-tracing - is designed to meet the needs of its end-user.
It's along these lines I've been thinking. A lot of ideas in this threads
have been pointing in the direction of giving the user the ability to
manage naming conflicts themselves. But, what if the user doesn't want the
added responsibility. Then s/he might have a disincentive to use the new
extended includes library. Then the library is actually not going to be of
value to them.
So then I thought, what if we turn the direction of namespace management
responsibility around 180 degrees? What if you made it so that the names
of macros and declares written in the past were not allowed to conflict
with those of the future, while putting very little restriction on present
naming provided by the user. What I came up with is described in my last
posting.
Here are a few more details:
1) When a user defines a macro or a declare, s/he is limited to the
characters "0-9", "_", "a-z", "A-Z". That's only 63 out of 255 ascii
values.
2) Let's let the parser make use of the remainning ascii values to
internally rewrite includes, editting each 'declaration' and corresponding
'call' identically. A set of special characters "{(<,.#*>})..." will
most-likely have to be off-limits to the parser as well. I'm thinking
ascii 128-255 is free. (I am unfamiliar with the numbers for users who use
character codes other than ascii. But, I suspect the priciple will still
hold
true.)
3) By giving this unused subset of characters to the parser and an algorithm
with which to use it, the parser is essentially rewriting the past, renaming
macros and declares in a way that no user possibly could in the present.
This renaming occurs only once the includes are in the buffer. No include
files would actually be rewritten.
I hope I've shed some light on my line of thought. BTW: I started reading
the source code last night.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote:
> If you want the #declare of a sub-include to have local-status of a
> current-level include, then that seems like it'd work just as long as the
> #declare was meant to be used at a one-up level (one-up from the
> sub-include). I've got a lot of stuff which I think this system would
> break. It's seems hard to come up with a system that won't break
> something.
Yes, i can think of a clear example: global includes which are just meant
to include other files to files including it, like:
/* scene.pov */
#include "main.pov"
....
/* main.inc */
#include "foo.inc"
#include "bar.inc"
....
No big deal. Just #include them without #as and the original #include
behaviour should be the same. So:
#include "foo.inc"
makes all declared foo items available to whomever includes the current
file, while:
#include "foo.inc" #as foo
makes declared foo items local to this file and prefixed with the foo alias.
I took the as syntax from the python programming language imports, which are
java's one better. :)
I have a little problem with the "namespace" term: what does it mean to
someone who's not a programmer? Anyone can understand "include", not so
with "namespace". is it edible? :)
What to do? what to do? overload #include to handle more meanings? add
yet more specialized syntax? The former is C++ way, while the latter is
the Perl way and seeing how POV-Team members are knowledgeable in both, i
can't see what the future reserves... :)
Anyway, nice to see real efforts to bring the SDL a step further in design.
I hope the POV-Team pick some of our best efforts and give it a thought and
a spin.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> I hope I've shed some light on my line of thought. BTW: I started reading
> the source code last night.
I would like to continue to clarify the naming model I am suggesting with
some vocabulary. This is my own vocabulary. If my idea has already been
implemented in some other application, and there is a pre-existing
vocabulary, then I would like to know that.
I am now thinking of files (include and renderable files both) in terms of
"spaces."
"Declaration Space":
The set of declares and macros defined in an include file.
"Implementation Space":
The set of code snippits which make use of any and all declares and/or
macros from a given include file. (Note: A file which calls more than one
include will have the same number of "implementation spaces".)
I am thinking of the set of named macros and declares - defined in an
include file - and those same macros and declares - implemented in a file
which calls that include file - in terms of a "membrane."
"Namespace Membrane":
A virtual structure implied by a single line in a file beginning with the
directive "#include ". On one side of the 'Namespace Membrane' is the
'Declaration Space' of the called include file. On the other side of the
same membrane is the 'Implementation Space' of the file containing the
'#include directive'.
I am thinking of the set of files (one renderable file, its includes, those
includes' includes, and so on) in terms of a tree - along the lines of a
'directory tree'. At the bottom is the renderable file - the single trunk
of the tree. Includes called by the renderable file are 'lower' and
includes called by other includes are 'upper' (as in branches).
"Upper Namespace Membrane":
Each include file has an 'Implementation Space' for each include file it
calls - thus implying the same number of 'namespace membranes'. (This
number may be zero (0) or positive.) Lets call each of these an "Upper
Namespace Membrane".
"Lower Namespace Membrane":
Every include file has exactly one "Lower Namespace Membrane". It is
implied each time the include file is '#include'd by another file.
[Note: The same include file may be called more than once in the same tree.
However, after being altered by the parser to avoid naming collisions, it
will have been transformed into a number of unique manifestations.]
An important rule to note:
In the model I propose, names are prevented from migrating from an 'upper
namespace membrane' to a 'lower namespace membrane' by virtue of the
parser's treatment of the file tree. Therefore, if your renderable file
'#include's "A.inc" - and - file "A.inc" '#include's "B.inc", then you
would not be able to access the 'declaration space' of "B.inc" unless your
file also includes "B.inc".
I hope this glorious mish-mash of metaphors is somewhat helpful in
communicating my vision. Next, I think I'll tinker with a C++ mock-up.
But, please stop me from just spinning my wheels if it turns out that's all
that I'm doing.
Thanks,
Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've had a look through this thread and there are a lot of ideas there.
There certainly seem to be some consistent themes emerging but before trying
to summarize them I'd like to clarify one point.
One large part of the thread discusses the potential to implement name
spaces in the POV-Ray parser and there are a couple of other ideas to
address naming conflicts and other issues that would require parser changes.
This seems great to me for the future, but it seems that if parser changes
are introduced then people are likely to take a while to get used to them
and start to develop techniques around them. Some time after that we would
be well positioned to discuss how to use them to implement standards.
I don't dispute that it would be good to anticipate such potential future
parser changes and build our current standards in a way that might be
compatible with them, but it seems to me that to get this collection off the
ground in the near future we'd be well advised to implement standards that
we're able to adhere to with existing versions of POV-Ray.
Would everyone be ok to limit the 'standards' discussion to existing, well
established features for now. This would also enable a greater number of
people to use the collection from the outset, without forcing everyone to
upgrade the moment the new version is released.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> Would everyone be ok to limit the 'standards' discussion to existing, well
> established features for now.
yeah, sure. Let's get back down to Earth and get the wheel moving! :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well here's my first attempt at summarising this thread. I've tried to pluck
out the ideas that we can do right now (i.e. that don't depend on parser
changes). I've selected what I think are the simplest of the ideas and built
them into what I'd propose as a cohesive starting point.
Some of the discussion points covered ideas that I think fit better into
'best practice' tutorials and guidance notes. I've set them aside for now,
but I think we should probably host such tutorials/guidance on the web site.
Some of the things that I've considered to be in this category include the
idea to have one object per file, positioning objects at the origin and 'y'
being 'up'.
Naming Conflicts
-----------------
I think the most important thing to address will be to avoid naming
collisions for files and identifiers. The simplest way of doing this will be
for contributions to adhere to naming standards based upon a name chosen by
the contributor. The name should be indicative of the content or purpose of
the contribution. Once a name has been chosen, no other contributions can
bear the same name, although clearly a particular contribution could be
changed almost beyond recognition over time by successive editors. Prefixes
will need to be used for file and identifier names (macros, variables,
functions etc).
The full contribution name could be used as the prefix. I think we should
also permit a shortened code to be used, but this would also need to be
unique.
Imagine someone creates a model of some cricket stumps and elects to name
the contribution 'CricketStumps'. If they wish to make use of a short code
and 'CS' has not already been used then they could register it. For this
example though, lets assume that 'CS' has already been allocated so they end
selecting 'CS2'.
Adherence to Naming Standards
---------------------------------
Use of the naming standards will be mandatory for contributions destined for
inclusion in the 'standard' part of the collection. As part of the
submission process the contributor will be required to indicate whether they
consider they have adhered to the standards. The contribution initially goes
into the 'ad-hoc' area. We could implement a 'feedback' screen where anyone
could comment on a contribution, with an option to dispute that a
contribution adheres to the standards.
If a contribution does adhere to the standards it could be promoted through
into the 'standard' area. Otherwise it will remain in the 'ad-hoc' area.
Such non-standard contributions would still be available for download, but
would be clearly 'marked' by the server to warn people that they don't
adhere to the standards (and to help prompt people to rectify the problem).
File Names
-----------
There's a limit on the number of directories we can declare in the library
path, so downloaded #include files and accompanying files will normally need
to go into just one directory - probably the include directory. Each of the
files from the collection that is going to end up in this directory will
therefore need to be uniquely named. Actually, I think that even if we use
an alternative directory or multiple directories in some way the names would
still need to be unique.
A contribution could contain multiple files, but all files in the
contribution will need to be made unique by using a common designated
prefix.
It probably be easiest to implement if the files all use the contribution
name as a prefix. This would make it easier for automated routines on the
server to manage parts of a contribution. The server could look for files
called:
o CricketStumps.html - as the top-level documentation file for the
contribution
o CricketStumps.keywords - for use with the search facility
o CricketStumps.pov - if present, could contain a simple renderable
example of the object
o CricketStumps.inc - would be the main include file and could also be
renderable
o CricketStumps.jpg - could contain a 800x600 render from which the server
could generate a thumbnail.
Other files could be included in the contribution, so, if the contribution
had its own separate texture file it could be called
CricketStumps_Textures.inc. None of these files would be mandatory, but if
not provided, the 'keywords' file would be created based on keywords entered
into the upload page when the collection is submitted.
If we permit an abbreviated prefix to be used then file names could become
CS2.inc, CS2_Textures.inc etc and the server would need to be able to
recognise that they are part of the same contribution. Maybe we'd have a
server generated file named CS2.CricketStumps to make the relationship
between the name and the prefix clear to a user looking through their
include directory.
If the contribution name needs to be followed by a descriptive name it
should be separated using an underscore e.g. CS2_Textures.inc or
CricketStumps_Textures.inc.
Does anyone know of any operating system of transfer software issues with
mixed case letters that may make it more sensible to use all lowercase file
names?
Identifier Names
----------------
In order that people will be able to use multiple contributions within a
single POV scene, identifiers declared in the include files will need to be
uniquely named so that they don't get mixed up with identifiers declared in
other include files from the collection and with those used in the scene
file.
The declaration of a variable intended to permit someone using the
CricketStumps contribution to set a height for some stumps may therefore
become '#declare CS2_StumpHeight = 0.85;'. Using an underscore here helps
anyone who may need to rename a set of identifiers in the future, for
example, anyone wishing to re-use a macro originally designed for
positioning cricket stumps within a future contribution for creating a
picket fence could readily rename identifiers.
Where an identifier does not need to be exposed to the person using the file
it should be declared using the #local directive.
Macro and Function Names
----------------------------
Similarly Macro names and function names will need to be unique, and would
need to be defined using the same unique prefix. e.g.
#macro CS2_CreateStumps (CS2_BailsOnFlag)
...
#end
Problematic File Types
-----------------------
It would be desirable to be able to permit non-SDL based utilities to be
added to the collection, such as conversion utilities, but if executable
files are permitted we should consider the potential question of viruses.
First step will be to check whether there's a virus scanner available to
povray.org to enable automated scanning of submitted files.
Sizing Standards
----------------
There was a discussion about whether people should be required to use a
standard size such as 1 POV-Ray unit = 1metre, but I think the consensus was
that this would difficult to apply universally because very large scale
(e.g. galaxies) and very small scales (atoms) can't reasonably adhere to
such a standard. Furthermore, someone who is accustomed to working in
Imperial measures could find it difficult to think in Metric.
I think the idea of documenting the units either in comments at the top of
the file or in the accompanying documentation was the best and simplest
idea. The contributor should also be encouraged to document the position and
size of their object and to include a sample scene file that people can look
at to easily work out how to get the object into the camera frame.
There was a proposal to have some generic unit conversion mechanism to allow
contributors to use the units they find most appropriate, while enabling
people to readily mix-and-match #include files.
This could be a macro or just some variable declarations and we could do
both very easily. I see Charles has started off a macro. We could also
create a standard #include file containing simple variable declarations
using a standard naming format:
#declare inches2metres = 0.0254;
#declare inches2feet = 1/12;
#declare miles2kilometres = 1.609344;
#declare feet2metres = 0.3048;
#declare metres2inches = 39.37007874;
#declare feet2inches = 12;
#declare kilometres2miles = 0.621371192;
#declare metres2feet = 3.280839895;
#declare lightyear2parsec = 0.306391546;
#declare parsec2lightyear = 3.263797626 ;
... etc ...
Then, if an object was defined in metres and we wanted it in feet we'd just
'scale metres2feet'.
We could even merge both ideas into a single include file, which could maybe
even find its way into the standard POV-Ray includes directory with V3.7 or
4.
Other Stuff
-----------
I'm sure that, over time, some clever people will develop utilities and
techniques to help improve standardisation of contributions, for example, a
parser to read a non-standard file and write out a standard one, ways of
wrapping non-standard code to make it look standard and changes to the
POV-Ray parser to introduce namespaces were all discussed.
If this all suits eveybody then I'd suggest that we plough ahead using an
approach that's as straight forward as possible to get this off the ground
and to see how it flies.
Anything I've missed, or that you disagree with?
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:4587c656$1@news.povray.org Chris B wrote:
> There was a discussion about whether people should be required to use
> a standard size such as 1 POV-Ray unit = 1metre, but I think the
> consensus was that this would difficult to apply universally because
> very large scale (e.g. galaxies) and very small scales (atoms) can't
> reasonably adhere to such a standard. Furthermore, someone who is
> accustomed to working in Imperial measures could find it difficult to
> think in Metric.
>
Sorry, I wasn't able to follow all the discussions recently, so my
comment may have come up. Instead of standardising units why not require
a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
user can scale the object to fit in a scene. For large scale objects one
could recuire it to fit in a 100x100x100 unit box. Or require that the
container for every object is defined in the #includefile (eventhough it
can be figured out using min/max_extent)
Thanks for the summary Chris.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tagpovrayorg> wrote:
> Instead of standardising units why not require
> a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
> user can scale the object to fit in a scene.
Btw, there's one thing to consider when predeclaring an object which is
later to be scaled:
Media density is not scaled with the object.
There are two possible behaviours of media density, both of which have
their rationale:
1) It is not affected by 'scale' (as it currently isn't). This is logical
when you think about an example case: If you have a glass of colored water,
it will filter light passing through it by some amount. If you take a glass
of the same colored water but which is twice as big, it will filter *more*
the light passing through it (because the light now traverses a larger
distance through the water). This is how POV-Ray currently behaves.
2) Density is affected by scale. This would be useful if you want to
eg. scale the entire scene to a different size, while keeping it looking
exactly the same. In other words, you might want to make everything 10 times
bigger (including the camera location etc), after which everything should
look identical, just all internal values are now ten-fold.
However, if you have an object with media in it, its density will currently
not be scaled, and you will end up with a much stronger media density, and
thus the object in question will look very different (with a 10 times
stronger media).
POV-Ray currently behaves as 1), but if you want the 2) behaviour, you'll
have to manually scale the media density by the inverse of the object scale
(IOW. if you scale the object 10 times bigger you have to divide the media
density by 10).
This consitutes a small problem with a predeclared object in an include
file which has media inside it. If you just instantiate the object and
scale it, and what you want is for the media to look identical regardless
of scale, that won't do it.
But on the other hand, you might *want* the media density to not to be
scaled with the object in order to get a more realistic result in certain
situations (think of the glass with colored water).
One possible solution to this is to make such objects #macros, one of
which parameters is the desired scale of the object. The macro will then
inversely scale the density of the media. This way if the user wants the
density to be scaled, he gives the scale as macro parameter, and if he
doesn't want it to be scaled, he just gives a "1" as scale parameter and
scales the object in his own code.
(Combinations of both are of course possible too, such as when you want
differently sized colored water glasses, but the base scale of the scene
is very different from what the original object was sized to.)
Of course uneven scaling is an interesting question in its own, but
let's not go that deep, shall we?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:45881636@news.povray.org...
>
> Btw, there's one thing to consider when predeclaring an object which is
> later to be scaled:
> Media density is not scaled with the object.
>
> ... snip ...
>
> One possible solution to this is to make such objects #macros, one of
> which parameters is the desired scale of the object. The macro will then
> inversely scale the density of the media.
>
> ... snip ...
>
> - Warp
That's something I wasn't aware of, but I have come across another situation
where scaling, rotating or translating a generated object was problematic
and ended up having to 'tell' the macro about any transformation that was
going to be applied so that it could take account of it during the
generation of the object (using an inverse of the transformation).
I think we should build such examples into part of a tutorial on how to make
objects reusable.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris B <c_b### [at] btconnectcomnospam> wrote:
> That's something I wasn't aware of, but I have come across another situation
> where scaling, rotating or translating a generated object was problematic
> and ended up having to 'tell' the macro about any transformation that was
> going to be applied so that it could take account of it during the
> generation of the object (using an inverse of the transformation).
Another feature which is not affected by transformations is the slope
pattern. However, I believe this to be a bug in POV-Ray which may be fixed
some time.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4588219a@news.povray.org...
> Chris B <c_b### [at] btconnectcomnospam> wrote:
>> That's something I wasn't aware of, but I have come across another
>> situation
>> where scaling, rotating or translating a generated object was problematic
>> and ended up having to 'tell' the macro about any transformation that was
>> going to be applied so that it could take account of it during the
>> generation of the object (using an inverse of the transformation).
>
> Another feature which is not affected by transformations is the slope
> pattern. However, I believe this to be a bug in POV-Ray which may be fixed
> some time.
>
> --
> - Warp
Hmm. So some sort of 'health warning' in a tutorial would probably be in
order for that one :o)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] tagpovrayorg> wrote in message
news:Xns989EACFFCF424seed7@news.povray.org...
> in news:4587c656$1@news.povray.org Chris B wrote:
>
>> There was a discussion about whether people should be required to use
>> a standard size such as 1 POV-Ray unit = 1metre, but I think the
>> consensus was that this would difficult to apply universally because
>> very large scale (e.g. galaxies) and very small scales (atoms) can't
>> reasonably adhere to such a standard. Furthermore, someone who is
>> accustomed to working in Imperial measures could find it difficult to
>> think in Metric.
>>
>
> Sorry, I wasn't able to follow all the discussions recently, so my
> comment may have come up. Instead of standardising units why not require
> a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
> user can scale the object to fit in a scene. For large scale objects one
> could recuire it to fit in a 100x100x100 unit box. Or require that the
> container for every object is defined in the #includefile (eventhough it
> can be figured out using min/max_extent)
>
> Thanks for the summary Chris.
>
> Ingo
Hi Ingo,
I think it was touched on in the thread, but I don't think it was discussed
in detail.
Personally I think this would make life more complicated rather than less.
When I think of my POVPerson macros which generate characters of different
sizes in different poses, if the macro scaled a 6ft tall seated person to
fit in a fixed sized unit cube and then, on a second call to the macro it
scaled a 5ft 4in standing person to fit in the same sized cube, I think it
would make the characters quite difficult to use. The person using them
would have to scale them up again by some quite difficult to calculate
amounts to be able to use them together.
Even with something as simple as a cricket ball, you'd have to know the size
of a cricket ball to scale it back to a realistic size if you just get a
unit sized ball, whereas, if it's in a recognised unit of measure you'd
probably be able to guess which conversion you need without even reading the
accompanying documentation. IMO if you had a ball in metres and a set of
cricket stumps in feet I think this would still be easier to work with than
if you got them both scaled to fit in a unit square.
As soon as you get larger collections of objects I think the problem would
grow. If each was scaled to a unit cube, then scaling them all by different
amounts to get them to work together seems to me like it would be a real
pain.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tagpovrayorg> wrote:
> comment may have come up. Instead of standardising units why not require
> a "small scale object" to fit in a centerd 1x1x1 pov-unit cube. Then any
> user can scale the object to fit in a scene.
Yes, i've come up with that earlier, i think in another thread. It makes a
lot of sense to me and i feel glad that someone else also likes the idea.
:)
I've been busy these days, and since Christmas is close, i don't think i'll
have much time for these lengthy discussions. How about saving it for
January? :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
