 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Xplo Eristotle wrote:
> Finally, it's my opinion that the POV language is *already* OO. I would
> love for anyone who disagrees to explain to me how
Ok, I agree that POV is already OO. I personnally prefer the current "braces"
syntax, but let's say that it's just because I was trained in procedural
programming and that "dot" syntaxes are better for POV (note : I agree that they
are in professional development environments).
Now, what a full pov scene would look like if it was coded like that ?
For example, could it be possible to have an ideal "dot" translation of something
like the following (extract of a scene I'm working on). Or of a large CSG
construct ? I'm just curious.
G.
#declare m=2;
#declare ry=1*m;
#declare a=degrees(m/ry);
#declare at=0;
#declare tr=80;
#declare Pave = object{ #include "pave.inc" translate y*0.5 scale m*0.5*1.6}
#declare Paves=array[8]
#declare Paves[0]=object{Pave}
#declare Paves[1]=object{Pave rotate y*90}
#declare Paves[2]=object{Pave rotate y*180}
#declare Paves[3]=object{Pave rotate y*270}
#declare Paves[4]=object{Pave scale <-1,1,1>}
#declare Paves[5]=object{Pave scale <-1,1,1> rotate y*90}
#declare Paves[6]=object{Pave scale <-1,1,1> rotate y*180}
#declare Paves[7]=object{Pave scale <-1,1,1> rotate y*270}
#declare rd=seed(0);
#declare finPave=finish{ambient 0 diffuse 0.6 specular 0.02 roughness 0.05}
#declare sc=0.1;
#declare colPave=colHouse1+<0,0.04,0.04>;
#declare Sol=union{
#while (at<360*tr)
#declare np=int(rand(rd)*8);
#declare vpos=vaxis_rotate(ry*x,y,at);
#declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
!!!
#declare vturb2=vturbulence(3, 0.5, 6, vpos*0.08);
#declare coltmp=color colPave*(1+abs(vturb2.x));
object{Paves[np]
rotate (1-rand(rd))*20*y
scale <1,(1+vturb.y*2)*0.3,1>
translate <ry,(1+vturb.y*2)*0.3,0>
rotate y*at
texture{
pigment{granite color_map{[0 coltmp][0.4
coltmp][0.6 coltmp*0.8][1 coltmp*0.5]}}
finish{finPave}
scale 0.1
}
}
#declare ry=ry+ m*m/(pi*(2*ry+m));
#declare a=degrees(m/ry);
#declare at=at+a;
#end
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCCE55.DBB148AD@inapg.inra.fr>, Gilles Tran
<tra### [at] inapg inrafr> wrote:
> #declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
Er, actually, I didn't write that function. I wrote the vtransform()
function. :-)
Can someone try a vwarp function? I attempted one, but didn't make much
progress.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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?
--
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:
>
> > 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 behind the times...
> Or a community behind the times?
or a community that knows where it wants to go.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCD832.7716F736@nigels.com>, nig### [at] eisanetau 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?
Or a screwdriver being used as a hammer? It might eventually get the job
done, but isn't as easy to use, isn't designed to be used that way, and
will probably ruin the screwdriver.
The reason it got a consistently negative response is that it would
require a graphical editor to comprehend the simplest scene written in
that language. It just isn't the right tool for the job, there would be
no reason to use it, and several reasons not to use it(it would be even
harder to program complex stuff in than it would be in POV-Script, and
harder for non-programmers to write scenes in, file sizes would be much
bigger...).
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The reason it got a consistently negative response is that it would
> require a graphical editor to comprehend the simplest scene written in
> that language.
Keep in mind that you're speaking from the point of view of
having already made an investment in the current format.
As pointed out already - it's recognisably like DKBtrace,
the point being that the use of braces, tags or commas
is really quite irrelevant.
> It just isn't the right tool for the job
For text editing, perhaps not. But for other things, it leaves
POV script for dead.
> it would be even harder to program complex stuff in than it
> would be in POV-Script
No, it wouldn't. It would be more consistent, more flexible
and more extensible.
> harder for non-programmers to write scenes in
No, the data is the same, tags are arguably easier for
non-programmers to grasp than "sphere { <0,0,0> 1.0 }"
which isn't informative in the slightest.
> file sizes would be much bigger...
Mesh data aside, it is completely irrelevant.
5k vs 8k? Is it that important?
You're right though, a hybrid text/tree/graphical editor
would be the ideal incarnation of an XML based scene
development tool.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Check out http://www.vrml.org/x3d.html, the working group
> > who are figuring out how to migrate VRML to XML.
> VRML seems reaaaaaaaaaly ugly. Especially things like needing to
> actually create a visible object before being able to reuse it, etc.
The semantics of VRML are not the point. Eventhough VRML is not
perfect for everything, it is at least a standard. Is there no
benefit in taking about spheres in the same way that VRML does?
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> > #declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
>
> Er, actually, I didn't write that function. I wrote the vtransform()
> function. :-)
Oops, thanks Ron or Nathan then (it's not clear who wrote it, at least in the
docs, didn't check the source). Anyway it's a wonderful function.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38C### [at] nigelscom>, nig### [at] eisanetau wrote:
> > The reason it got a consistently negative response is that it would
> > require a graphical editor to comprehend the simplest scene written in
> > that language.
>
> Keep in mind that you're speaking from the point of view of
> having already made an investment in the current format.
> As pointed out already - it's recognisably like DKBtrace,
> the point being that the use of braces, tags or commas
> is really quite irrelevant.
Actually, I am not. I am actually working on a language that can be used
instead of POV-Script.
As you said, it resembles the scripting language for DKBTrace, which
wasn't designed with programming features in mind and was abandoned for
the current type of scripting language. I see no reason to go
backwards...
> > It just isn't the right tool for the job
>
> For text editing, perhaps not. But for other things, it leaves
> POV script for dead.
How is that so?
> > it would be even harder to program complex stuff in than it
> > would be in POV-Script
>
> No, it wouldn't. It would be more consistent, more flexible
> and more extensible.
And what makes you think this? Even with the current POV-Script syntax,
which is much more readable than this, it is easy to lose track of
things in complex looping/conditional structures.
Even a simple particle system would be a nightmare in that language...
> > harder for non-programmers to write scenes in
>
> No, the data is the same, tags are arguably easier for
> non-programmers to grasp than "sphere { <0,0,0> 1.0 }"
> which isn't informative in the slightest.
No, it would be harder for people to write, and nearly impossible to
read. Tags are *not* easier to understand, if you want to make the
current language easier to understand, try something like
"sphere {position = < 0, 0, 0>, radius = 1.0}".
Not only does your proposal require much more typing, it makes it much
easier to lose track of things. Everything disappears in a mess of tags.
> > file sizes would be much bigger...
>
> Mesh data aside, it is completely irrelevant.
> 5k vs 8k? Is it that important?
How about 1MB mesh vs 3.5MB mesh? Or 30MB mesh vs 75MB mesh? Or even
larger size increase?
This can be very important if you have several large files.
> You're right though, a hybrid text/tree/graphical editor
> would be the ideal incarnation of an XML based scene
> development tool.
It would be absolutely necessary if you want to write a complex scene,
and I still don't see how programming features fit in.
In order to use something like this, a GUI editor would have to be
created for each platform, even those without a built-in GUI.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCE1C6.275E2B13@inapg.inra.fr>, Gilles Tran
<tra### [at] inapginrafr> wrote:
> Oops, thanks Ron or Nathan then (it's not clear who wrote it, at
> least in the docs, didn't check the source). Anyway it's a wonderful
> function.
I think it was the Smellenberghs.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
