 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<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] gte net> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
> > I think if this replaced POV-Script, people would go to other things
> > instead, and if it was an option along with POV-Script, very few
> > people would use it(even modellers would probably output in
> > POV-Script for file size reasons).
>
> Hmmm...
>
> A consistently negative reaction...
> An idea before it's time?
> Or a community behind the times?
>
XML defined languages are for ease of computer parsing, not for ease of
human writing/reading, though they are human readable since they're
plain text.
Also XML is for markup languages. OK for modeller output, not so good
for POV.
I don't think loops, macros etc. work well in XML.
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
> Not at all, you seem to get the impression that this is
> a new language - it's not. It's simply POV Script in an
> XML form. There are two issues here - (1) the data model,
> and (2) the way you encode it in ASCII. I am really only
> referring to (2). The whole point of XML is to allow you
> to manage the data model more effectively - but it doesn't
> mean that you throw away your existing data model to use XML.
>
POV script is very free-form, to be defined by XML, your language would
have to do away with that.
The freedom of the POV language is what makes it hard to parse, not the
fact that it uses
statement{ val }
rather than
<statement>
<arg1> val </arg1>
</statement>
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> POV script is very free-form, to be defined by XML, your language would
> have to do away with that.
No, I don't think so. Please explain why you think this.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <As3NOAOBs+Ru55ANkKtFBbwnSUuI@4ax.com>, Glen Berry
<7no### [at] ezwvcom> wrote:
> Poor design choices haven't stopped it yet. :)
>
> ...and yes, there *have* been at least a few poor design choices.
But none of them made the program unuseable without anything the user
hadn't already been using.
> I say if someone has the ability to write an XML based POV, more power
> to them. It would be nice to actually have such a program to test,
> instead of just speculating about it. You won't often find me
> discouraging experimentation with new ideas. It's often the more
> unusual ideas that end up being the most enlightening. Even if an idea
> never makes it into mainstream use, there is often still be a place
> for it, or it might lead to bigger and better things, as yet
> unforseen.
Yes, if there was something that could actually be tested and put to
use, that would be good. Maybe a translator program, something like
C-SDL?
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <D5TNOASIAvcmq=v7ZHjaH6KAifJl@4ax.com>, Glen Berry
<7no### [at] ezwvcom> wrote:
> >Still, my first point was a platform specific editor feature is no
> >substitute for a language feature.
>
> Whos said anything about a platform-specific editor?
Bob Hughes. He mentioned that auto-completion would be a "nifty feature"
in the Codemax editor, which as far as I know is Windows only. My point
is that auto-completion is an editor-dependant feature, and thus
platform dependant, and so it is a bad substitute for a language
feature.(which would be completely platform independant)
> 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.
Just because a program handles ASCII files doesn't mean it doesn't have
a platform-specific interface. Writing for the Mac GUI is quite
different from writing for the Windows GUI. The only way to get
something consistant and which wouldn't have to be rewritten every time
would be to use Java, which some people wouldn't like.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Mar 2000, Ken wrote:
>
>
> Nigel Stewart wrote:
> >
> > <AMUSED>
> > See, we're all getting the idea of tags now, arn't we?
> > </AMUSED>
>
> statement { I felt really dirty while doing it. }
statement { I have no idea what this whole discussion is about } ;)
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
cre### [at] belialrenonvus wrote:
> statement { I have no idea what this whole discussion is about } ;)
Comic relief ?
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
