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