make FUNCTIONs like so
    function {FORMULA (<parameters>) }
  map{[<1Dval>, <XDmapentry>][<2Dval>, <XDmapentry>][<XDval>,
<XDmapentry>]...}// this maps a function from a 1D var to a colour,
normal etc & others.
  FORMULA = ( ["dll-name"] func-name) | macro-name | formula
   if dll-name is not used pov functions are used
and revamp textures, normals, etc to be able to use these
eg I could use this to have a different pattern for each rgbft channel
by adding the values ...

allow the type of a variable to be obtainable eg gettype(myvar)

Drop "#declare" for non-new variables

"extendable objects, finishes, media, etc"
    #declare myobjtype = new object{ intersections FUNCTION,
surfacehandler FUNCTION, interiorhandler FUNCTION...}
so that you can make custom shaped objects, do freaky stuff to the ray
when it leaves a surface, do freaky stuff to the ray as it goes through
an interior

make POV an object oriented program so the above is possible
    #declare myobj = struct {...}

get the PolyRay author to add a tesselate object modifier

line lights - interpolate between the ends somehow??
with spline stuff
and go from there to triangle lights and then to object lights (maybe
using photons)

displacement  mapping, mapping of any and all texture parameters using
images

have the struct that determines syntax highlighting in the POV-Ray src
(instead of the CodeMax support code) so that
patches can use proper syntax highlighting for their new keywords etc.

Post a reply to this message

Attachments:
Download 'us-ascii' (2 KB)

Pabs <pab### [at] hotmailcom> wrote:
:   FORMULA = ( ["dll-name"] func-name) | macro-name | formula
:    if dll-name is not used pov functions are used

: have the struct that determines syntax highlighting in the POV-Ray src
: (instead of the CodeMax support code) so that
: patches can use proper syntax highlighting for their new keywords etc.

  Povray is NOT a windows program.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
> Pabs <pab### [at] hotmailcom> wrote:
> :   FORMULA = ( ["dll-name"] func-name) | macro-name | formula
> :    if dll-name is not used pov functions are used
> 
> : have the struct that determines syntax highlighting in the POV-Ray src
> : (instead of the CodeMax support code) so that
> : patches can use proper syntax highlighting for their new keywords etc.
> 
>   Povray is NOT a windows program.

So what's wrong with windows platform specific suggestions where the
codemax editor is concerned ? I mean like the Mac version has built
in Quicktime support for compiling animation the other platforms
don't have and you don't hear me bitching about that do you ? Well
not much anyway :)

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: So what's wrong with windows platform specific suggestions where the
: codemax editor is concerned ? I mean like the Mac version has built
: in Quicktime support for compiling animation the other platforms
: don't have and you don't hear me bitching about that do you ? Well
: not much anyway :)

  If I understood correctly, he suggested that it would be possible to
specify a "dll-name" in the pov-script. This makes no sense since the
povray script is not platform-dependant.
  It was also unclear how the struct for syntax highlighting would work and
where would it be located.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> >   Povray is NOT a windows program.

	It isn't?  I wonder what I installed on my Windows NT box
	then...  A forgery?  A fake?

	Lets get serious.  When POV came out, the command line
	was the standard thing, DOS, UNIX, lowest common 
	denominator.  Now we have a Windows GUI, a Mac GUI,
	but we're still running around talking about portability.
	
	That's silly.  The core should be kept portable,
	but people should be able to use current technology
	to get what they want out of POVray.

	It's possible to write platform independent code in 
	C++ - but it's not enforced.  The same philosophy should
	apply to POV.

	Things like POV-CSDL - grafting an interpreted C'ish
	kind of thing onto POV - goes to show the extreme
	measures we'd need to enforce the portablity of
	pov scenes, while still not giving people what they 
	really want - a true programmatic interface, in the
	language of their choice.
	
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

On Thu, 16 Mar 2000 15:16:50 +0800, Pabs wrote:

>have the struct that determines syntax highlighting in the POV-Ray src
>(instead of the CodeMax support code) so that
>patches can use proper syntax highlighting for their new keywords etc.

This, at least, should be available before 4.0, assuming all goes according
to plan and so on.  But note the disclaimer; this is not an official 
proclamation.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 16 Mar 2000 04:53:15 -0500, Nieminen Juha wrote:

>  If I understood correctly, he suggested that it would be possible to
>specify a "dll-name" in the pov-script. This makes no sense since the
>povray script is not platform-dependant.

Well... it's possible in SuperPatch, which runs on platforms where DLLs
don't make sense.  But it won't be in 3.5, or in 4.0.

>  It was also unclear how the struct for syntax highlighting would work and
>where would it be located.

If we just used the patch I sent to Chris back just before I joined the 
POV-Team, it'd be built on the fly by the Windows support code and sent to 
the Codemax handler.  It's currently hard-coded in the Codemax support DLL.  
But we won't be using that patch, so that's not how it will work.

Don't worry, it's not intended to be cross-platform; this is a Windows-only 
thing, for a Windows-only editor. You may continue to use pov-mode.el syntax 
highlighting.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Nigel Stewart <nig### [at] nigelscom> wrote:
:> >   Povray is NOT a windows program.

: 	It isn't?  I wonder what I installed on my Windows NT box
: 	then...  A forgery?  A fake?

  Nope, povray is an ANSI-C program. It has been ported to several platforms,
like Windows, but that doesn't make it a Windows program. The binary you
installed is a windows compile of the program, but povray itself is not a
windows program.

: 	Lets get serious.  When POV came out, the command line
: 	was the standard thing, DOS, UNIX, lowest common 
: 	denominator.  Now we have a Windows GUI, a Mac GUI,
: 	but we're still running around talking about portability.
: 	
: 	That's silly.

  Nope, it's not silly. Many people are using povray in a wide variety of
platforms (which support or don't graphical user interfaces).

: 	It's possible to write platform independent code in 
: 	C++ - but it's not enforced.  The same philosophy should
: 	apply to POV.

  No it shouldn't. Povray has to be able to compile in any platform which
has the proper compiler. Portability is a very serious issue.
  I understand why most windows users just can't understand how someone likes
to use something else than windows and graphical programs.

: 	Things like POV-CSDL - grafting an interpreted C'ish
: 	kind of thing onto POV - goes to show the extreme
: 	measures we'd need to enforce the portablity of
: 	pov scenes

  Pov scenes and the povray source code are two completely different things.
Don't mix them.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> :       It's possible to write platform independent code in
> :       C++ - but it's not enforced.  The same philosophy should
> :       apply to POV.
> 
>   No it shouldn't. Povray has to be able to compile in any platform which
> has the proper compiler. Portability is a very serious issue.

	Yes it should.  Enforced portability is very limiting.
	I'm talking about the portability of POV scenes,
	not the C implementation - which I agree should be
	kept portable.

>   Pov scenes and the povray source code are two completely different things.
> Don't mix them.

	I'm not, you are.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

On Fri, 17 Mar 2000 01:53:12 +1100, Nigel Stewart wrote:
>	Yes it should.  Enforced portability is very limiting.
>	I'm talking about the portability of POV scenes,
>	not the C implementation - which I agree should be
>	kept portable.

*boggle*  You're saying it would be good to be able to make POV scenes that 
don't render on every platform for a given version of POV?  Can we just send
all the support questions to you?  What color is the sky in your world?

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Nigel Stewart wrote:
> 
>         Yes it should.  Enforced portability is very limiting.
>         I'm talking about the portability of POV scenes,

HUH ?!?!?!?!?!?! WTF????
You want to be able to make non portable scene files???
What are you smoking?

PoD.

Post a reply to this message

In article <38D0F558.B878634F@nigels.com>, nig### [at] eisanetau wrote:

> 	Yes it should.  Enforced portability is very limiting.
> 	I'm talking about the portability of POV scenes,
> 	not the C implementation - which I agree should be
> 	kept portable.

You are kidding, right? If anything, the POV scenes should be more 
portable. If it runs on one platform, it should run *exactly* the same 
on another, regardless of the hardware or operating system. Otherwise, 
it is an indication of a problem with the port.(and would lead to lots 
of support problems)


> >   Pov scenes and the povray source code are two completely different 
> >   things.
> > Don't mix them.
> 
> 	I'm not, you are.

This started out as a discussion about the source code, you started 
talking about scene files without clearly stating the switch(apparently 
*nobody* knew you weren't talking about the source). So you were the one 
mixing the two.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Pabs wrote:

> have the struct that determines syntax highlighting in the POV-Ray src
> (instead of the CodeMax support code) so that
> patches can use proper syntax highlighting for their new keywords etc.

How 'bout having a dialog box in the editor that allows for user-defined
syntax highlighting and different highlighting for different file types?

I know this has nothing to do with POV, but the editor is so great I
like to use it for HTML and stuff.

--
___     _______________________________________________
 | \     |_          <dav### [at] faricynet> <ICQ 55354965>
 |_/avid |ontaine        http://www.faricy.net/~davidf/

"The only difference between me and a madman is that I'm not mad." -Dali

Post a reply to this message

David Fontaine wrote:

> How 'bout having a dialog box in the editor that allows for user-defined
> syntax highlighting and different highlighting for different file types?

 Speaking unofficialy...

 I have suggested the idea of creating custom file associations and
definable syntax highlighting to Mr. Cason already and he indicated
a positive interest in the idea. Where it will go from there though
is anyones guess.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

>   Povray is NOT a windows program.

Sorry, I don't know much about other platforms
but I get how the src is made platform independent

But it doesn't mean that I shouldn't address issues I see in POV for specific
platforms
You may notice that functions could also be specified by macros &
pov-functions (platform independent) but I forgot to mention formulas, like
MegaPov has

Can anyone tell me what they think instead of just arguing over platform
independence
We all have a platform we like, use, are comfortable with, are fiercely loyal
to, hate, get pissed off by, avoid on the grounds of its domination, blah
blah blah, but lets not go to war over something so stupid, we are all
supporters of POV-Ray.

The main reason for my post was that to me the current texture stuff seems
inconsistent across pigments, normals, finishes etc. and that I would like to
have more control over the ray leaving a surface or going through an interior
(So I can make a mirage)

Thanks All
Pabs

Post a reply to this message

On Thu, 16 Mar 2000 16:16:27 -0600, David Fontaine <dav### [at] faricynet>
wrote:

>I know this has nothing to do with POV, but the editor is so great I
>like to use it for HTML and stuff.

I already use it for HTML :) This is from a site I am working on:

  <META NAME="Generator" CONTENT="POV-Ray(tm) for Windows(tm)">
  <META NAME="Author" CONTENT="Peter Popov">


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

Pabs wrote in message <38D19836.6EAFBF9C@hotmail.com>...
>The main reason for my post was that to me the current texture stuff seems
>inconsistent across pigments, normals, finishes etc. and that I would like
to
>have more control over the ray leaving a surface or going through an
interior
>(So I can make a mirage)


Making a true mirage would require POV-Ray to be able to find the
intersection points between an object and a differential equation.  If you
look at the source code for POV-Ray, you will see that for some objects,
such as the isosurface, finding where a straight line intersects the object
is quite complicated.  It may not even be possible to find the intersection
points of a differential equation and the object with sufficient accuracy
without spending several hours per pixel.

Mark

Post a reply to this message

> *boggle*  You're saying it would be good to be able to make POV scenes that
> don't render on every platform for a given version of POV?  Can we just send
> all the support questions to you?  What color is the sky in your world?

	Ron, there is no difference between supporting an
	extension mechanism explicitly, and having scenes
	that are specific to SuperPatch, MegaPatch, or
	ImpPov.  The difference with an official mechanism
	is that POV can handle it more gracefully than
	a general parse error message.

	One way to do this is to add a platform identifier
	tag in the scene, so that a different pov can detect
	scenes that arn't going to work.

	I'm well aware of this "sacred cow" of portability,
	but I do think that there are enough people asking
	for a plug-in architecture that it is worth finding
	a compromise.  Why bother with things like custom
	languages when you can use the language of your
	choice?

	The sky here is blue and clear - it is a beutiful
	summer day, eventhough it's officially autumn.
	Hopefully, I get to go to the beach tomorrow.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

On Fri, 17 Mar 2000 11:10:16 +1100, Nigel Stewart wrote:
>
>> *boggle*  You're saying it would be good to be able to make POV scenes that
>> don't render on every platform for a given version of POV?  Can we just send
>> all the support questions to you?  What color is the sky in your world?
>
>	Ron, there is no difference between supporting an
>	extension mechanism explicitly, and having scenes
>	that are specific to SuperPatch, MegaPatch, or
>	ImpPov.  The difference with an official mechanism
>	is that POV can handle it more gracefully than
>	a general parse error message.

We've already handled the unofficial patch problem gracefully, as everyone's
seen in MegaPOV.  Starting with 3.5, there will likely be more guidelines for
unofficial versions; one is to prevent the kinds of problems we've seen with
people trying to user superpatch or MegaPOV scenes with the official version.

But multiple incompatible official versions would still be a support nightmare.

>	I'm well aware of this "sacred cow" of portability,
>	but I do think that there are enough people asking
>	for a plug-in architecture that it is worth finding
>	a compromise.  

We're aware of the number of people asking for a plugin architecture.  As
for adding an API a'la Renderman, it's unlikely that we'll do such a thing 
in the forseeable future due to the reasons that are stated in POVLEGAL.
Other plugin-type things are still being actively discussed.

Besides, I don't think you've thought through the consequences of what you're
asking for here.  Essentially, you're saying you want to take this nice little
sharing, giving community we have here and balkanize it into language-based
camps.

As usual, please note the note in my signature.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 17 Mar 2000 08:55:14 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>Besides, I don't think you've thought through the consequences of what you're
>asking for here.  Essentially, you're saying you want to take this nice little
>sharing, giving community we have here and balkanize it into language-based
>camps.

Ahem!

:)


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On Fri, 17 Mar 2000 23:46:50 +0200, Peter Popov wrote:
>On 17 Mar 2000 08:55:14 -0500, ron### [at] povrayorg (Ron Parker)
>wrote:
>
>>Besides, I don't think you've thought through the consequences of what you're
>>asking for here.  Essentially, you're saying you want to take this nice little
>>sharing, giving community we have here and balkanize it into language-based
>>camps.
>
>Ahem!

I knew I'd get you to bite on that one. :)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 17 Mar 2000 17:01:26 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>>>Besides, I don't think you've thought through the consequences of what you're
>>>asking for here.  Essentially, you're saying you want to take this nice little
>>>sharing, giving community we have here and balkanize it into language-based
>>>camps.
>>
>>Ahem!
>
>I knew I'd get you to bite on that one. :)

It's just that you spelt balkanise wrong. :)


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

> Essentially, you're saying you want to take this nice little
> sharing, giving community we have here and balkanize it into language-based
> camps.

You talk about the "support nightmare", but I can see the
complexity of POV-script increasing with each release,
which in turn will result in similar problems. I'd rather
see a focus on rendering technology than parsing technology.

<wish>
Set POV free, and let us use it as an API
</wish>

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

PoD wrote:
> 
> Nigel Stewart wrote:
> >
> >         Yes it should.  Enforced portability is very limiting.
> >         I'm talking about the portability of POV scenes,
> 
> HUH ?!?!?!?!?!?! WTF????
> You want to be able to make non portable scene files???
> What are you smoking?

Probably some kind of 
 union {
 cone {...}
 cylinder {... interior {media...}}
 finish {recognizable_smell...}
}

Fabien.

Post a reply to this message

In article <38D2BBBE.107BB51B@nigels.com>, nig### [at] eisanetau wrote:

> You talk about the "support nightmare", but I can see the
> complexity of POV-script increasing with each release,
> which in turn will result in similar problems.

Multiple languages for each platform would be very difficult to support. 
Adding to and expanding the language will be much easier to support. I 
don't see why you want this...people will no longer be able to ask "how 
do I do this", they will have to choose a language too, and people using 
other languages wouldn't be able to help them. There would have to be at 
least one expert for each language. And if they are platform dependant, 
that makes the problem much larger.(the same scene file that renders on 
Windows POV-Ray should run the same on POV-Ray Mac or Linux POV. There 
should be no differences, other than version numbers)
I don't see any benefit in platform dependant things like this, and a 
lot of problems...


> I'd rather see a focus on rendering technology than parsing 
> technology.

I don't see the POV Team trying to come up with new kinds of parsers for 
each release...their focus is definitely not on parsing technology.


> <wish>
> Set POV free, and let us use it as an API
> </wish>

Who is this "us" you speak of?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nigel Stewart <nig### [at] nigelscom> wrote in message
news:38D2BBBE.107BB51B@nigels.com...

> <wish>
> Set POV free, and let us use it as an API
> </wish>

Exactly that is what the POV-Team is trying to prevent, IMO, and for the
reasons they give in POVLEGAL. I can understand that.

--
Rudy Velthuis

Post a reply to this message

Chris Huff wrote:

> > I'd rather see a focus on rendering technology than parsing
> > technology.
 
> ...their focus is definitely not on parsing technology.

Well there is to the extent that they try to add enhancements and
optimizations to the current parser whenever they can.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

> Multiple languages for each platform would be very difficult to support.

All you have to support is an API.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

Nigel Stewart wrote in message <38D5606D.FEF25671@nigels.com>...
>
>> Multiple languages for each platform would be very difficult to support.
>
>All you have to support is an API.
>
>--



If want you want is a graceful mechanism for supporting extensions to the
scene language, I wouldn't look much further than XML
and namespace support.

Thus, extensions to the pov scene language can be handled with namespaces.
Those authors who are interested in making scenes run on a platform which
does not support that extension should markup more carefully than those who
don't.  As long as the reference "compile" of POV gracefully handled these
extensions, what reason would someone have to object?

e.g.
<sphere class="SnookerBall">
    <megapov0_9:phat_photon>...
    </megapov0_9:phat_photo>
</sphere>

Help me out here:
Pros:
o) POV sources (like MORAY, my perl scripts, etc. as opposed to sinks, like
the raytracer itself) can markup 3D scenes with minimum fuss
o) New POV editors could exploit XML Schemas
o) The concepts of "style" are equally applicable to pov source files as
they are to XHTML
o) Source format becomes "future proof"
o) Future developers will understand XML processors in the same way that
current developers understand "i++" in C.
o) Existing, proven, technology
o) Easy way to both add new tags and incorporate third-party developer's
experiments and fun stuff
o) ...?

Cons:
o) legacy .pov files.  (see below)
o) Complexity for non-programmer user... (less of an issue for me: I think
POVML would be easier to markup than the current POV scene language, but
that's a pretty emotional statement)
o) All the newsgroup space and arguments that go into choosing what the
actual elements should be (eg. verbose like above, or concise, like SVG,e.g.
<pov:sphere transform="t[ranslate] 125*z r[otate] 0 1 0 60 s[cale] 10"...>)
[again, less of an issue, because,like most people on this list,  I love
constructive discussion)
o) Potential for "tower of babel" diversity among extensions.
o) I haven't thought about what impact this would have on the reference
implementation codebase
o) ...?

Issues:
o) I recommend staying away from DTDs if you want to use namespaces.
o) I suggest that all existing scene graph language files be supported, and
that a future version of POV has a builtin (commandline?) function to
transform from .povml  to .pov and viceversa.
o) Is there an "ANSI C"-ified  interface to XML parsing?  Code reuse would
be a good thing...
o) I'd also probably argue (hmmm, I obviously feel really feel strongly
about this...;¬]) that an internal DOM would be a good thing, although that
might not scale well.  A persistant DOM engine would solve that problem, but
I don't think there is a stable code base for that sort of thing at the
moment.
o) ...?

Let's look ahead to version 5, 6, 7 of POV.  These issues should only have
to be dealt with once.


Nick Drew
hyp### [at] btinternetcom

"I'm not giving in to mob rule, I'm merely jumping on a bandwagon..."

Post a reply to this message