 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
> This is the basis of our misunderstanding.
>
> POV script is good for what it is.
What you seem to fail to understand is that POV is not a rendering
engine, it is a scene description language.
Try to replace the language (I know you're not) and you'll not only get
howls of outrage from users, but you won't have POV any more.
Replace the rendering engine and it's still POV. If the new engine is
faster and/or gives the better output, you'll be congratulated.
Nobody really cares about the renderer except those who coded it.
The lagnuage *IS* POV-Ray.
------
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PoD wrote:
> Nobody really cares about the renderer except those who coded it.
> The lagnuage *IS* POV-Ray.
Yep !
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > The lagnuage *IS* POV-Ray.
The potential for POV-Ray is much more than POV script.
--
Nigel Stewart (nig### [at] nigels com)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
>
> > > The lagnuage *IS* POV-Ray.
>
> The potential for POV-Ray is much more than POV script.
POV-Ray will always be defined by the language fed to the rendering
engine. The statement "The lagnuage *IS* POV-Ray" is a valid one.
--
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 wrote:
> Nigel Stewart wrote:
> >
> > > > The lagnuage *IS* POV-Ray.
> >
> > The potential for POV-Ray is much more than POV script.
>
> POV-Ray will always be defined by the language fed to the rendering
> engine. The statement "The lagnuage *IS* POV-Ray" is a valid one.
>
It seems that what seems confusing to a few people here is that in other 3D
packages (and particularly the high-end ones) there is an apparently
clear-cut separation between the scene-design abilities and the rendering
ones. You often see pictures "created with A, rendered with B". This is
obviously a quite efficient way to do things, since you have the best of
both worlds.
However, POV is a free, amateur tool. AFAIK, people who use it usually don't
have much the choice when it come to scene design and rendering : it's
either POV or nothing at all. At best, some of us can afford commercial
utilities like Poser or Rhino. Those who can afford (or are willing to use
pirated versions of) Max or Softimage, or have enough programming skills to
use BMRT and learn the RIB specifications, have already done so.
So, for the rest of us who stick with POV, there's no particular reason to
make a difference between the language and the renderer, because it is the
intricate mixing of the two that makes the software usable in the first
place.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
>
> Ken wrote:
>
> > Nigel Stewart wrote:
> > >
> > > > > The lagnuage *IS* POV-Ray.
> > >
> > > The potential for POV-Ray is much more than POV script.
> >
> > POV-Ray will always be defined by the language fed to the rendering
> > engine. The statement "The lagnuage *IS* POV-Ray" is a valid one.
> >
>
> It seems that what seems confusing to a few people here is that in other 3D
> packages (and particularly the high-end ones) there is an apparently
> clear-cut separation between the scene-design abilities and the rendering
> ones. You often see pictures "created with A, rendered with B". This is
> obviously a quite efficient way to do things, since you have the best of
> both worlds.
> However, POV is a free, amateur tool. AFAIK, people who use it usually don't
> have much the choice when it come to scene design and rendering : it's
> either POV or nothing at all. At best, some of us can afford commercial
> utilities like Poser or Rhino. Those who can afford (or are willing to use
> pirated versions of) Max or Softimage, or have enough programming skills to
> use BMRT and learn the RIB specifications, have already done so.
> So, for the rest of us who stick with POV, there's no particular reason to
> make a difference between the language and the renderer, because it is the
> intricate mixing of the two that makes the software usable in the first
> place.
> G.
The important destinction between POV-Ray and many of the commercial
packages is the fact that POV-Ray does not provide an integrated
modelling environment such as many of the programs you listed. It
never was intended to. It's language does however help in the quest
to describe an image and any number of external tools can help in
the process.
One thing I still don't understand is why people want POV-Ray to
talk to other programs.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> One thing I still don't understand is why people want POV-Ray to
> talk to other programs.
Because there are all kinds of tasks that can't be
solved with the current tools, and there is no
technical reason that POV should be limited to
one single "view" or "interface" to the rendering
technology.
--
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, 31 Mar 2000 11:24:35 +0930, PoD wrote:
>The lagnuage *IS* POV-Ray.
This is a good point.
But somehow I don't think the POV-Ray team would be very happy if I
implemented a different renderer which uses the same szene description
language and called it POV-Ray.
hp
--
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter J. Holzer" wrote:
>
> On Fri, 31 Mar 2000 11:24:35 +0930, PoD wrote:
> >The lagnuage *IS* POV-Ray.
>
> This is a good point.
>
> But somehow I don't think the POV-Ray team would be very happy if I
> implemented a different renderer which uses the same szene description
> language and called it POV-Ray.
>
But if your renderer was better, you could release an unofficial version
and your renderer might even find its way into a future official
release.
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
><snipped/>
>First let me say that I like XML (and I do hand-code it, and I also
>think that vi is the best HTML-editor), but I think that omitting the
>algorithmic elements of POV-Script in POVML (or whatever we would like
>to call it) would be a mistake.
>
>Consider this fragment of POV-Script:
>
> #declare i = 0;
> #while (i < 360)
>
> object {
> vesta
> translate <830, 50+10, 0>
> rotate <0, i, 0>
> }
>
> #declare i = i + 12;
> #end
>
>This puts 30 "vesta" objects in a circle of 830 pov-units radius.
>
>If this would be converted to
>
> <object name="vesta">
> <translate><vector>830 60 0</vector></translate>
> <rotate><vector>0, 0, 0</vector></rotate>
> </object>
> <object name="vesta">
> <translate><vector>830 60 0</vector></translate>
> <rotate><vector>0, 12, 0</vector></rotate>
> </object>
> .
> .
> .
> <object name="vesta">
> <translate><vector>830 60 0</vector></translate>
> <rotate><vector>0, 348, 0</vector></rotate>
> </object>
>
>It isn't a circle of objects any more. These are 30 independent objects
>which just happen to form a circle.
>
>I do admit that I would prefer something like
>
> <loop start="0" end="348" step="12">
> ...
> </loop>
>
>to
>
> <set variable=i value="0" />
> <while expr="i < 360">
> ...
> <set variable=i expr="i+12" />
> </while>
>
>The latter doesn't really feel XMLish to me.
>
I agree.
How about a more declarative approach? For simple loops where you can do
some range analysis (all tagnames/attributes are tentative):
<forall subject="i" range="{0..360}">
<!--declare the range of i-->
<where expr="i%12 == 0">
<apply-in-sequence>
<!--not sure about this - see below-->
<rotate>
<vector>0 <valueOf select="i"/> 0</vector> <!--invoke
i within longhand rotate->
</rotate>
<transform t="t 830 60 0"/>
<!--use shorthand form where feasible
<object use="vesta"/>
<!--assume vesta is mesh, as opposed to macro. see below-->
</apply-in-sequence>
</where>
</forall>
The apply-in-sequence (or something like it) would be needed to avoid having
nested transforms like:
<rotate>
<vector>...</vector>
<transform t="...">
<object .../>
</transform>
</rotate>
This would be poor in the sense that the author could place the <vector> tag
pair after the <transform>. To check for this the DOM traverser would have
to scan all children to extract the info it needed. An event based XML
parser wouldn't be affected, though so the latter form is still viable.
I believe a suitable editor would be able to allow the user to edit this
shape by changing the expression in the <where> tag. If you look at XSL,
they have the <xsl:choose> tag, which has <xsl:when> and <xsl:otherwise>
tags. Take this idea and apply it to ranges of values rather than tag
patterns, and I think you've got a powerful
Macros are a bit trickier - to include a circle of circles you could a)
define a clause (a subroutine in procedural languages) which exposes a
variable, and then b) invoke the clause with a given range for the variable.
a)
<clause name="vestaTwist">
<expose subject="i" default-range="{0..360}"/>
<forall subject="i">
<where expr="i%12 == 0">
<apply-in-sequence>
<rotate>
<vector>0 <valueOf select="i"/> 0</vector>
</rotate>
<transform t="t 830 60 0"/>
<object use="vesta"/>
</apply-in-sequence>
</where>
</forall>
</clause>
b)
<forall subject="i" range="{0..360}">
<where expr="i%12 == 0">
<apply-in-sequence>
<rotate>
<vector>0,<valueOf select="i"/>,0</vector>
</rotate>
<transform t="t <830,60,0>"/>
<scale s="1/830 1/60 0"/>
<eval name="vestaTwist">
<supply id="i" range="{0..90}"/>
</eval>
</apply-in-sequence>
</where>
</forall>
Cheers,
Nick Drew
HyperSpace Ltd,Birmingham Research Park, Edgbaston, UK, B15 2SQ
(e) hyp### [at] btinternetcom (t) +44 (0)121 414 7019
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
