 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbell net> wrote in message
news:38CD5D57.247F8422@pacbell.net...
> One thing I am slightly confused about is if you are using a
complicated
> scene description language to make a new scene and then convert it to
> POV-Ray won't you still be limited to what POV-Ray can actually do
> proceeduraly ?
>
> If POV-Ray can already do it proceeduraly why not do it in native Pov
> in the first place ?
This is about the same as if you were asking:
"Why is the POV-Ray software developed in C, when C is only compiled to
machine code? Aren't you still limited to what your computer can
actually do with machine code? If the computer can already do it in
machine code why not do it in the native machine code in the first
place?"
OK, the difference between machine code and C is more obvious than the
difference between POV-Script and a CSDL, but the analogy still stands:
A CSDL gives a different logical view on the same system (in this case a
3D scene) which will have benefits in some situations, while in other
situations a different view (for example using POV-Script or a visual
modeller) is better.
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> A CSDL gives a different logical view on the same system (in this case a
> 3D scene) which will have benefits in some situations,
Here is a conceptual breakthrough! "...a different
logical view on the same system..." You can have a
POV script view, a CSDL view, a VRML view, or an
XML view, or a visual modelling view.
Does everyone want the same view?
No.
Do we need to keep the POV script view?
Yes.
Should POV script be "native" view?
Probably not.
--
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 <38cd7c9a@news.povray.org>, "Johannes Hubert"
<jht### [at] mailacom> wrote:
> Learn how to make wheels? Good idea! But best done by learning from
> examples of the pros. If you can't get a book, search on the net, there
> should be loads of stuff about parser and compiler writing out there.
Know of any good ones? My searches revealed a huge quantity of parser
stuff, but not much of the "parser writing techniques" type.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 12 Mar 2000 12:02:32 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>In article <38CBC8F6.8B481E2A@pacbell.net>, lin### [at] povrayorg
>wrote:
>
>> A thought... Some of these files query the user for parameters during
>> the program run time. If added to Pov it sure would reduce the number
>> of predeclared variables needed in the scene.
>
>Are you talking about some kind of "query_user()" function that would
>pop up a dialog or a console input for the person rendering the file to
>enter values? Something like:
>#declare Name = query_user("Please enter your name: ");
>
>I don't think that would be a good idea. What if it pops up after 15
>minutes of parsing, and you left the computer going over the weekend
>expecting to have an animation finished when you got back?
Perhaps the parser could scan for such interactive features first, and
let the user know that they need to watch the screen to add input to
the scene data. If no interactive features were found in the scene
files, then the parser could even issue a statement to that effect,
and proceed to render the scene while you went out for the weekend.
>Besides, it could be a real pain to set those for every single little
>test render.
It should also be possible to "remember" the values entered during the
last rendering of an interactive scene file, and use them for
"default" values when queried by the current interactive rendering.
Let's say you have ten seconds to change the default value, or the
scene continues parsing with the default value. Hitting the "return"
key would simply accept the default value as-is, and avoid the ten
second delay. In order to store the previous query values, POV's
text-file output capabilities can be put to use in a method similar to
Nathan's use of an external file for storing photon or radiosity data
for subsequent renders.
I think this would work okay. I have wanted such an interactive aspect
added to POV-Ray myself.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 14 Mar 2000 00:14:11 -0500, Serge LAROCQUE
<sgl### [at] hotmailcom%> wrote:
>Just a question: Is keeping the backward compatibility of POV-Ray with older
>syntax important?
It isn't to me, but it is for some people. I would rather see old
versions of POV used to handle old POV code, than trying to make a new
version of POV bend over backwards and parse legacy code. It usually
isn't that hard to update a POV scene to fit a revised syntax. With
the exception of halos, the feature set only seems to grow, never
shrink. Even in the case of halos, there are work-arounds.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 12 Mar 2000 18:06:39 -0800, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:
>A floor wax _and_ a desert topping???
>
>Cool.
Not only that, but it tastes great, and it's less filling than other
brands.
:)
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13 Mar 2000 04:43:09 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:
>TonyB <ben### [at] panamac-comnet> wrote:
>: That is *exactly* the kind of reaction I got when I suggested those things a
>: year ago.
>
> If I remember right, I was one of those fighting agains adding a for-loop
>to povray.
> Well, I have grown out of that stage... :)
Hmmm... if a particular programmer could approve of for-loops, could
JPEG support happen in the future?
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> I think this would work okay. I have wanted such an interactive aspect
> added to POV-Ray myself.
I am glad someone else sees the potential value of this idea. It would
make using special include files much more versatile than they are now
and would make changing variables interactive. Your screwed if you forget
what values worked the best and forgot what variables you used but the
same is true of any command line utility that accepts switches as input.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Serge LAROCQUE wrote:
>
> Just a question: Is keeping the backward compatibility of POV-Ray with older
> syntax important?
Not for Glen Berry but for many other people, yes. There are a lot of
people out there who are sharing their scene files with the public.
Not everyone want's to spend 10 - 20 min. editing legacy code just to
render it to see if there is anything in there worth adopting in their
own work or simply because the like the image it produces so much they
want a higher resolution and quality version of it. Some very useful
utilities write code for earlier versions of POV-Ray yet the script they
produce is highly desirable. Some of these produce extremely large files
that are nearly impossible to edit manually. This is where the backward
compatiblity really pays off.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> Hmmm... if a particular programmer could approve of for-loops, could
> JPEG support happen in the future?
The POV-Team has already officially announced that jpeg input support has
been added to POV-Ray v3.5. Jpeg out will not be added or supported.
--
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
|
|
| |
| |
|
|
|
|
| |
