 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Mar 2000 00:45:19 -0500, Glen Berry wrote:
>As for custom-patched versions of POV, every new patch should come
>with multiple examples of each new keyword and concept that are
>introduced. If the patch is available for Windows, then appropriate
>insert-menu addtions should be offered with the patch as well.
Thanks for your input, but if I had to live by those rules I never would
have released the superpatch into the wild and people would still be
complaining about how many different patches there are. Programmers do not
make good writers, and vice versa. Ideally, someone would volunteer to fix
the docs and make insert-menu stuff and create example scene files, but all
y'all do is bitch about how much better *we* could do. Small wonder I
stopped doing the superpatch, eh?
>I'm not a serious programmer, but I've always thought that the main
>obstacle to plugins was the attitude of the POV-Team being against
>such things. I thought some people had already proposed workable ideas
>for implementing plugins, but the POV-Team firmly refused the concept.
I'm one of those who proposed plugins before I was a member of the team.
As I understand it, the idea was seriously discussed and ultimately
rejected because of cross-platform compatibility issues. Perhaps after
the next round of changes (which I can't discuss now) some of those issues
will go away, but I can almost guarantee that someone, somewhere, will be
so upset by those ultimately useful changes that they'll organize a jihad.
--
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 13 Mar 2000 03:56:42 -0500, Nieminen Juha wrote:
>Matt Giwer <jul### [at] ij net> wrote:
>: Everything in computing can be done with the minimalist set of
>: micro-code which actually gets down to four or five instructions
>: depending upon your side in the debate
>
> Actually 2 instructions are enough.
I once read that you could build a computer with just one instruction.
IIRC, the mnemonic was "decrement and jump if not zero" or something
like that. Obviously not the most efficient computer out there, though
(and with only one instruction, you don't need an opcode. The code IS
the data.)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> <POVSCENE>
> <SPHERE>
> <POSITION> 0,0,0 </POSITION>
> <RADIUS> 1.0 </RADIUS>
> <PIGMENT>
> <COLOR> BLUE </COLOR>
> </PIGMENT>
> <TRANSLATE> -0.5*x </TRANSLATE>
> </SPHERE>
> </POVSCENE>
No, please.
I like to be able to use a simple text editor to write pov-script. This
POV-XML is just too long, too heavy, too difficult to read and more prone to
typo. And I find it to be un-aesthetic.
Didn't we discuss this issue already? Do you have new arguments?
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Reluctantly, I will write here some of my thoughts on this polemical
subject. Reluctantly because I have little time, and because I now my
thoughts are far from being mature. Little time also means I did not read
(yet) all the messages in this thread, so I may address points that were
already discussed and "closed". But, please, bear with me, for I feel an
obligation to share my opinion.
Firstly, it seems that this discussion about POV's syntax, present and
future, quickly and repeatedly becomes a discussion about POV features and
wish lists. Many seem to address language/feature additions rather than
syntax changes. While these features additions would result in more keywords
and a few more syntax forms, most of the time they would not produce real
syntactic changes. To the non-programmer user, like I am, an OO style
camera.location is not different from a camera_location variable (but I
understand MyDeclaredObject.min_extent too).
I think POV syntax to be reasonably "good" as it is now. Reasonably because
it exhibits some incoherence. Some come from POV's history (evolution);
others come from different people implementing analogous functions in
different features. Some are, I believe, incoherence only to the
non-programmer, like shadowless and no_shadow. I believe reducing some of
these incoherences can make POV easier to learn and use. I'll throw in some
examples: - shadowless and no_shadow - I'd like all #declare to accept; as
an ending - the use of the comma in different statements could be unified -
texture is where I think POV _should_ have a syntax rewrite. Two examples
(my main concerns, actually): (1) the current implementation use many
different keywords for really similar functions - think of all the *_map;
(2) layering should be explicit, something like texture{layered{texture{T1},
texture{T2. or pigment{layered{.
As you have now surely understood, my only real "dissatisfaction" (quote,
because this word is too strong) in POV's syntax is its lack of unity... I
do not mean that I'd like its _looseness_ to be reduced: it is great to be
able to describe the same thing in different ways and each can choose its
favourite. I mean: I would like if each of these different syntax forms
could be used for every analogous task - and not, as it often is now, have
many features have its own syntax.
As to new features in the syntax, I would accept most gladly.
The for{,,} loop would surely be easier to use than the #while one, but then
I would like to see a while{,} and a #for.#end syntax. Access to object
information would be great, whether it is done with OO-style
MyObect.trace(.) or any other practical way. += style declaration would be
really useful. So would be better variable scoping. Generalisation of the
texture/pattern/function/isoshapes syntax could be really great, but
currently I can see no way of doing this without (1) loosing backward
compatibility (other than the #version switch) and (2) moving up to another
level of abstraction, making things more difficult to the newcomer.
New feature in POV I will always welcome warmly...
Now, I have done my duty, I feel at rest.
Povingly,
Philippe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chrishuff_99-470E46.16512213032000@news.povray.org>, Chris
Huff <chr### [at] yahoocom> wrote:
>Maybe leaves?
True. Leaves would be a special child in the simple form; if the ifs
object has three children, each end would get three leaves with the same
angle changes as any other child. There would have to be a point
(probably <0,0,0>) that is considered the 'base' of the leaf object.
ifs {
....
leaf { predefinedObject }
}
>This looks rather interesting and quite powerful, although I didn't
>understand all of it. Several of the features I wouldn't know how to
>do(well, actually, I don't know how to add any kind of object), any
>volunteers? :-)
I keep meaning to put my fractal macros on a web page. However, they are
slow and memory heavy. And I don't personally understand all of the
mathematics in them :*)
Jerry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry <7no### [at] ezwvcom> wrote:
: There must be something I am overlooking here. Aren't programs that
: deal with ASCII text some of the most easily portable programs? Why
: does a POV scene editor ( not a modeler, mind you ) have to rely on a
: lot of platform specific coding? I'm sure someone will be quick to
: remind me of the reason I seem to have forgotten.
I think that the proposition was to bind a keyboard shortcut for the
task. This is highly system-dependant.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14 Mar 2000 08:36:03 -0500, ron### [at] povrayorg (Ron Parker)
wrote:
>On Tue, 14 Mar 2000 00:45:19 -0500, Glen Berry wrote:
>>As for custom-patched versions of POV, every new patch should come
>>with multiple examples of each new keyword and concept that are
>>introduced. If the patch is available for Windows, then appropriate
>>insert-menu addtions should be offered with the patch as well.
>
>Thanks for your input, but if I had to live by those rules I never would
>have released the superpatch into the wild and people would still be
>complaining about how many different patches there are. Programmers do not
>make good writers, and vice versa. Ideally, someone would volunteer to fix
>the docs and make insert-menu stuff and create example scene files, but all
>y'all do is bitch about how much better *we* could do. Small wonder I
>stopped doing the superpatch, eh?
Now Ron, did I bitch about you or any other patch writer? All I am
saying is that these things should get done. I don't care if the
original author does them, or someone else. One way or another, it
would be good to achieve this. Heck, I'll probably write some insert
menu stuff myself. Whatever I do write, I will share with everyone.
>I'm one of those who proposed plugins before I was a member of the team.
>As I understand it, the idea was seriously discussed and ultimately
>rejected because of cross-platform compatibility issues. Perhaps after
>the next round of changes (which I can't discuss now) some of those issues
>will go away, but I can almost guarantee that someone, somewhere, will be
>so upset by those ultimately useful changes that they'll organize a jihad.
I hope not. Holy wars are the most senseless of wars.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<Nigel Stewart>
<AMUSED>
See, we're all getting the idea of tags now, arn't we?
</AMUSED>
</Nigel Stewart>
<KEN>
I felt really dirty while doing it.
</KEN>
<GLEN>
<HUMOR>
Come on, we know you really liked it.
</HUMOR>
</GLEN>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> Mark Wagner <mar### [at] gtenet> wrote:
> : #do
> : /* Do something */
> : #if(1 = 2)
> : #until(a = 3)
> : #end
>
> : or
>
> : #do
> : /* Do something */
> : #if(1 = 1)
> : #until(a = 3)
> : #end
>
> Both of those should issue an error.
>
True, both are non nested blocks.
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry wrote:
>
> In article <38CC002C.6DBE9012@merlin.net.au>, PoD <pod### [at] merlinnetau>
> wrote:
> >Show me a simple syntax that lets you create a tree with different
> >textures for trunk, branches, twigs, leaves, fruit, flowers.
> >And has declarations of objects to use for the above.
>
> Well, I'd separate out a simple IFS from full-blown LSystem, since it
> ought to be easier (and happens to be what I'm interested in :*)
Ok, I did say trees rather than L-Systems.
>
> #declare deadSeed = seed(99);
> #declare tree = ifs {
> children 3 //number of children that bloom from each 'branch'
> angles {
> <30,0,0>, <0,60,60>, <0,30,0>
> } //angle change for each child
> sizes {
> <.8,.75,.75>, <.6,1,1>, <.5,.5,.5>
> } //size change for each child
Distances?
Here, all children go at the end of the parent, I assume.
Hm. yeah you can do it that way if a continuation of the branch is a
special child.
> deadends {
> deadSeed
> .1,.05,.05
> } //chance of a dead end for each iteration, as well as the
> //seed to use for randomness
> levels 5
> level_map {
> [1-2 texture { trunknbranches }]
> [3 texture { greentrees }]
> [4 texture { greenleaves }]
> [5 texture { flowers }]
> } //might also use a 0-1 range
I think these need to be objects rather than textures.
> method dot_approximation //I've forgotten the name of this
Not sure what you mean here.
> //other method would be to draw every piece
> turbulence .25
> //turbulence might not be the right keyword; might have to
> //be separated into 'angle_turb' and 'size_turb'.
Probably should be per-level.
> //some items might not be able to be applied to some methods
> //also, a completely separate 'flower' object might not be a bad idea:
> //flower { object { treeFlower } }
> //which goes on the end of any branch that makes it to the top level
> }
>
> Have I forgotten any necessary information?
>
> Jerry
Sounds like it probably should be called tree{} rather than ifs{}
though.
Some other things.
Leaves tend to all be at the same angle to the ground (except in plants
where they're not), so you'd have to be able to specify that. Same for
flowers.
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
