 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> It was originally based on 3.02, as were most of the patches included
> in it when I first released it. The first released version was "based
> on" 3.1, meaning I had at that point merged 3.1 in and it could be used
> as a basis for further patching.
>
> >Then - if the superpatch is really based on 3.02 -
> >wouldn't it really be easier for POV-Team (or whoever)
> >to merge yet another 3.02 patch into the superpatch?
...and if you want to be technically accurate everything in POV-Ray is based
on DKBTrace :)
--
Ken Tyler
See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Wed, 22 Sep 1999 19:39:19 +0200, Tomas Plachetka wrote:
> >Your last remark confused me. What do you mean by
> >merging 3.1 sources into the superpatch? As far as I
> >know, the superpatch is based on 3.1, not on 3.02. Or
> >am I wrong?
>
> It was originally based on 3.02, as were most of the patches included
> in it when I first released it. The first released version was "based
> on" 3.1, meaning I had at that point merged 3.1 in and it could be used
> as a basis for further patching.
Thanks for an explanation. I'm not confused anymore.
(At least in concern with this.)
> >Then - if the superpatch is really based on 3.02 -
> >wouldn't it really be easier for POV-Team (or whoever)
> >to merge yet another 3.02 patch into the superpatch?
>
> I maintain the superpatch; it's an unofficial version that has nothing
> to do with the POV-Team, other than that they're rumored to be looking
> at it as an aid to making the official version 3.5. The version they
> have is based on 3.1, as are all publicly released versions.
I see and am trying to reconstruct the recent
history... I think I got it:
The idea of a superpatch comes from people outside
of the POV-Team (maybe not, it's not so important).
A group of volunteers (SPatch-Team) decided to do
it. You and maybe a few other people of SPatch-Team
did the integration. This all happened in the times
of 3.02. Meanwhile POV-Team released an official
version 3.1. To avoid a divergence of POV-Ray 3.1
and SPatch 1.0, the official 3.1 sources must have
been merged with the actual SPatch sources as soon
as possible.
Now I also understand why the merging took you a
long time and do not envy you the work.
OK, back to the business: When my patch is ready,
whom should I send it to ? To you? Or to
news://news.povray.org/povray.patches?
In the later case, is there an official procedure
about how to post patches to the povray.patches?
And if so, where could I read it?
(Forgive my stupid questions, I'm a newbie here.)
y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
> You still have to parse the entire code to see where is the matching
> semicolon.
> There's no way to avoid parsing other than copying the whole source code
> to memory without the static parts of it and then parse this copy.
How about considering #static as an alternative to #include?
There would be two acceptable forms the parser would expect...
#static /filename/
or
#static (/filename/,/start/,/end/)
If the former was encountered, POV would parse the include file
indicated by "filename" once on the first frame rendered, then just
retain it until all frames were completed.
For the latter syntax, it would behave exactly like #include until
frame # "start" was reached, then parse one more time and hold until
either frame # "end" was reached, or all the specified frames were
completed (whichever comes first, depending on the INI file options
selected). If more frames than "end" are rendered, just go back to
considering it identical to saying #include after the last rendered
frame.
This way, if the static section does not need reparsing, POV need
only read a single line to discover this and move on. And of course,
it leaves responsibility for deciding what should be static firmly
on the shoulders of the user, where it belongs.
Charles
--
http://www.enter.net/~cfusner
"...Then darkness took me, and I strayed out of thought and time,
and I wandered far on roads that I will not tell..."
-The Two Towers, JRR Tolkien
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Sep 1999 23:19:52 +0200, Tomas Plachetka wrote:
>OK, back to the business: When my patch is ready,
>whom should I send it to ? To you? Or to
>news://news.povray.org/povray.patches?
>In the later case, is there an official procedure
>about how to post patches to the povray.patches?
>And if so, where could I read it?
>(Forgive my stupid questions, I'm a newbie here.)
You can post it to povray.binaries.programming and post a note
about it in povray.unofficial.patches so we know to look for it
there. That way everyone can enjoy it, even it if takes me the
usual months to get it into the superpatch. :) As for how to
get patches into the official version, I'm not sure there is an
official documented method, but at least one team member will
see it in the unofficial.patches group.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Sep 1999 17:27:23 -0400, Charles wrote:
>Nieminen Juha wrote:
>> You still have to parse the entire code to see where is the matching
>> semicolon.
>> There's no way to avoid parsing other than copying the whole source code
>> to memory without the static parts of it and then parse this copy.
>
>How about considering #static as an alternative to #include?
>There would be two acceptable forms the parser would expect...
>
>#static /filename/
>
>or
>
>#static (/filename/,/start/,/end/)
Or, using the syntax I proposed,
#static (start, end)
#include "filename"
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
> >This is something I didn't know about (that the
> >clock function is always monotone). I thought
> >of it as of a variable which is automatically
> >declared and has a special meaning...
> >Are you sure that the user cannot assign an
> >arbitrary value to clock in the .pov code?!
>
> POV treats it as a scalar function with no arguments. I get an
> error when I try to assign to it.
>
But you can change the clock value and clock delta in an arbitrary manner during
an animation. Just #write the appropriate initial_clock, final_clock,
initial_frame and final_frame options to an ini file.
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 23 Sep 1999 01:03:51 +0300, Margus Ramst wrote:
>Ron Parker wrote:
>>
>> On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
>> >This is something I didn't know about (that the
>> >clock function is always monotone). I thought
>> >of it as of a variable which is automatically
>> >declared and has a special meaning...
>> >Are you sure that the user cannot assign an
>> >arbitrary value to clock in the .pov code?!
>>
>> POV treats it as a scalar function with no arguments. I get an
>> error when I try to assign to it.
>>
>
>But you can change the clock value and clock delta in an arbitrary manner during
>an animation. Just #write the appropriate initial_clock, final_clock,
>initial_frame and final_frame options to an ini file.
But wouldn't you then have to restart the renderer for those options to take
effect? If not, I'd say that's a bug. Even if you can, you shouldn't use
#static if you're gonna play around with the poor thing's mind like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> But wouldn't you then have to restart the renderer for those options to take
> effect?
Come to think of it, I haven't tried. And I agree, it's too twisted to worry
about :)
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> PoD <pod### [at] merlin netau> wrote:
> : I'm beginning to think that #static as a type of #declare would be more
> : feasible, after all it is only usefull for things which take a long time
> : to parse such as complex unions and meshes.
>
> You forget that you can make #while-loops which take hours to parse although
> it creates only some simple objects.
You could make a #while loop which takes days to parse and creates no
objects at all
>
> : When parsing a #static declaration, check if the name is already in the
> : symbol table. If it is then skip to the end of the declaration.
>
> : How do you know what's the end of the declaration?
> : Firstly all declarations should end with a semi colon. Then each
> : [#declare|#local|#static] would match up with a semi colon.
>
> You still have to parse the entire code to see where is the matching
> semicolon.
If a #while loop is inside a #static declaration, you'd only have to
look for the matching #end which would not take long at all.
#include would be totally ignored.
> There's no way to avoid parsing other than copying the whole source code
> to memory without the static parts of it and then parse this copy.
What difference does reading it into memory make?
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>
> Or, using the syntax I proposed,
>
> #static (start, end)
> #include "filename"
> #end
True. Three lines instead of one isn't going to make a significant
difference to parsing, although it's slightly more trouble to type,
so the above would give almost identical results -- *if* the end
user applies it correctly.
I only mentioned it as a supplement to #include (analogous to the
way #local is a specialized supplement to #declare) because problems
with making it a #static block were brought up. As an alternative
to #include, there'd be no block, and users would have to
externalize the static info to a separate file because... that's
just the way it works.
Whereas, if you require the user to set up a #static block with an
embedded #include in it, sure as there's rain you'll have people
who skip the #include and just stuff hundreds of lines of code
between #static and its corresponding #end and complain that it
isn't making the kind of difference they think it ought to (and
Warp will have to add something new to the VFAQ). As much as I
hate "protect them from their own stupidity" style programming...
Well, I'm a scene coder, not a programmer. I only mention it
in passing, FWIW.
Charles
--
http://www.enter.net/~cfusner
"...Then darkness took me, and I strayed out of thought and time,
and I wandered far on roads that I will not tell..."
-The Two Towers, JRR Tolkien
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
