 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <470208a9@news.povray.org>, war### [at] tag povrayorg says...
> Ger <No.### [at] thankyou> wrote:
> > Does POV really need a new language
>
> Yes. You yourself gave the reason why:
>
> > lets
> > not forget that POV needs 3 things most. Speed, more speed and some spe
ed.
>
> The new language doesn't have to look very different from the current S
DL,
> but some changes are necessary (for example related to macros).
>
Precisely. It would be useful if a) it looked at least "close" to what
we are already using, b) didn't make using it overly complicated and c)
if they just clean up the SDL, to make it have certain features, there
is no reason why one can't discuss the merits of other languages, so we
have some idea what feature we *may* in fact want to add to it. If the
choice happens to be to keep the SDL as is and "not" separate object
handling or the like from the code level (at least enough so you can
declare objects separate from the code, instead of burying them
throughout the code, like they are now).
--
void main () {
If Schrödingers_cat is alive
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4701e40f@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > In *any* other language you need to do something like:
>
> That's not true. There are a number of other possibilities, including
> languages that have been around a lot longer than Lua and specifically
> designed for this sort of work (as Lua was).
>
> But since I got seriously harshed for even mentioning possibilities last
> time, I'm not going to continue on with this discussion.
>
Ok, I should have said, "any language I am aware of". Point is, its a
nice trick, which Java and many other supposed "modern" languages don't
allow for.
--
void main () {
If Schrödingers_cat is alive
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <47024d79$1@news.povray.org>,
nic### [at] gmailisthebestcom says...
> Patrick Elliott escribió:
> > And its method of
> > representing arrays allow you to *literally* drop complex data
> > structures in to the array, for immediate use. For example, in the
> > client I use it in, if you want to get data on something as simple as a
> > line of text, you need to just push the data into a table in Lua, then
> > access it like an array. The method for transferring such data "into"
> > Lua is fairly trivial. Other languages *can't* handle the transfer of
> > such structured data. They are forced to rely on creating multiple
> > arrays, to hold each subtype of data. So while Lua uses a single table
> > that looks like:
> >
> > mytable (position)
> > \---Letter
> > \---Font
> > \---Color
> > \---Ect.
> >
> > In *any* other language you need to do something like:
> >
> > dim letter()
> > dim font()
> > dim color()
> > dim etc()
> >
> > Then load **each** of those independently.
>
> Umm... Isn't that how things work on *any* loosely-typed language?
>
> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3)];
>
> A valid Javascript array containing a number, another array, a string, a
> regular expression, and a Sphere (provided that the Sphere object was
> defined).
>
Well, all I know is that it wasn't, for what ever reason, possible with
the client. That *may* be due to the fact that Java is *not* normally
that loosely typed, or that some serious problem existed in ActiveScript
which seriously fracked it (since it relies a lot of that for every
language except Lua. Though, mind you, half the ActiveScript languages
seem to not follow spec anyway and suffer from bloody silly
inconsistencies even in how you instance them, never mind get them to do
anything after they are linked.)
--
void main () {
If Schrödingers_cat is alive
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott escribió:
> In article <47024d79$1@news.povray.org>,
> nic### [at] gmailisthebestcom says...
>> Umm... Isn't that how things work on *any* loosely-typed language?
>>
>> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3)];
>>
>> A valid Javascript array containing a number, another array, a string, a
>> regular expression, and a Sphere (provided that the Sphere object was
>> defined).
>>
> Well, all I know is that it wasn't, for what ever reason, possible with
> the client. That *may* be due to the fact that Java is *not* normally
> that loosely typed, or that some serious problem existed in ActiveScript
> which seriously fracked it (since it relies a lot of that for every
> language except Lua. Though, mind you, half the ActiveScript languages
> seem to not follow spec anyway and suffer from bloody silly
> inconsistencies even in how you instance them, never mind get them to do
> anything after they are linked.)
>
You're mixing up Java and Javascript (they have nothing to do, name
similarity is apparently because of marketing reasons). Java is
strongly-typed, Javascript is loosely-typed. Java is compiled into
bytecode, Javascript is interpreted. Java has classes, Javascript has
prototype-based OOP instead.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> Warp a écrit :
>
>>> When POV-Ray renders the image it has tons of additional information
>>> about it besides simply the pixels. It has depth information, normal
>>> information, all kinds of other things. In order to post-process the
>>> image using this information you need to either save it all in files
>>> and then write a program which reads them and does the post-processing,
>>> or you can write a simple script in the future SDL to do the same thing.
>
>> How, in this model, do you adjust a parameter like focal point (in
>> the case of a blur process) and get a new image within seconds ?
>
> I'm not really sure what you are asking.
Let's say I have a scene that takes 3 hours to render. It shows an
orange, an apple and a banana, on a table.
I use post-processing to apply heavy focal blur (no oversampling
with the camera, it would take too long). Initially, the focal
point is the orange. But then, I want it to be the banana.
How, in the system you envision, will I be able to change the
focal point and get a new image within a few seconds, instead
of taking 3 hours to re-render everything ?
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Morpheus is fighting William Tracy!
>
[...]
> In all fairness, there *are* platform-independent uses for this sort of
> thing. How about being able to call Python from SDL? You don't want to
> just hard-code links to Python in POV...because then the Perl and Ruby
> hackers would get mad. ;-)
>
There's no need to fight : < http://www.parrotcode.org/ >
;)
> William Tracy
Slawek
--
________
_/ __/ __/ Kopernik ruszyl ziemie i dlatego zobaczyl, ze jest okragla
\__ \__ \_______________________________________________________________
/___/___/ S�awomir Szczyrba steev/AT/hot\dot\pl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How, in the system you envision, will I be able to change the
> focal point and get a new image within a few seconds, instead
> of taking 3 hours to re-render everything ?
We could expose images as assignable objects during
the post_process stage, which would allow layering and
other tricks that now are done with other software. And
we could expose the depth of the rays to make certain
filtering options much more accurate. Syntax might be
something like...
pre_process {...}
// scene
post_process {
#declare A = output_image;
#declare B = file_image "file";
#declare A = blurByDepth(A,focus_point,depth_of_field);
#declare C = layerImages(A,B);
final_image {
use_image C
type PNG
image_name "newfile.png"
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Warp a écrit :
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >> Warp a écrit :
> >
> >>> When POV-Ray renders the image it has tons of additional information
> >>> about it besides simply the pixels. It has depth information, normal
> >>> information, all kinds of other things. In order to post-process the
> >>> image using this information you need to either save it all in files
> >>> and then write a program which reads them and does the post-processing,
> >>> or you can write a simple script in the future SDL to do the same thing.
> >
> >> How, in this model, do you adjust a parameter like focal point (in
> >> the case of a blur process) and get a new image within seconds ?
> >
> > I'm not really sure what you are asking.
>
> Let's say I have a scene that takes 3 hours to render. It shows an
> orange, an apple and a banana, on a table.
>
> I use post-processing to apply heavy focal blur (no oversampling
> with the camera, it would take too long). Initially, the focal
> point is the orange. But then, I want it to be the banana.
>
> How, in the system you envision, will I be able to change the
> focal point and get a new image within a few seconds, instead
> of taking 3 hours to re-render everything ?
>
> Fabien.
Is it still ray-tracing? You only get an image that is based on a ray-traced
one. But if you end up with what you want, then OK.
My opinion is that ray-tracing is a technique that allows to apply physical
laws in order to match reality. I prefer 'match' than 'fake': POV's focal
blur matches a physical phenomenon, post-processing 'only' fakes. But in
many cases one may get satisfied. That's an essential point.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> As you might have noticed, not everybody is convinced we should have one.
Right.
But the concern is so present that the question of a new SDL is 'on air'
since quite a while, made this discussion happen, and interests a lot of
people (I think). And I bet that those people you mentionned, once/if ever
POV has its new nice syntax with new long-awaited features, will be the
first to use it with greed ... The demand for new POV-SDL araised from the
lacks and drawbacks of POV, even if it is a marvelous tool.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> How, in the system you envision, will I be able to change the
> focal point and get a new image within a few seconds, instead
> of taking 3 hours to re-render everything ?
Regardless of which method is used it's clear that povray must keep
all the necessary information in files (or at the very least in memory)
between renders.
There could be a few possibilities:
1) An option to tell POV-Ray to write all the necessary information on files.
Then if you want to re-post-process, you just use the option +C to skip
the rendering.
One disadvantage of this is that you have to remember to use the option
if you want to be able to post-process multiple times.
2) POV-Ray could always write the extra info on files, allowing
post-processing whenever you want.
The disadvantage is that it will consume disk space and the user would
have to manually delete those unneeded files to clean it up.
3) POV-Ray could automatically write the info on files and keep them there
as long a it's running, and when it's closed, it removes them (unless
an option is given). This would allow re-post-processing the image as
many times as necessary as long as POV-Ray is running.
The disadvantage is that this idea doesn't work with the command-line
version. Another slight disadvantage is that if the execution of the
program is ended abruptly, the files will be left there.
4) As 3, but the info is kept in memory until next render.
Doesn't garbage the disk, but has the same disadvantages.
Make your pick, or suggest something better.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> andrel wrote:
>> Can someone set something up somewhere?
>
> Can someone recommend specific Wiki software?
>
> It'd need to support external authentication (to link in to the POV user
> registration system), and captchas or other anti-spam measures.
Mediawiki seems a natural choice because a lot of people know how to use
it (from wikipedia) and anything we need in the lines of the above is
probably already available in some form. For authentication a long list
of extensions can be found on:
http://www.mediawiki.org/wiki/Category:User_identity_extensions
Christoph
--
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> * Existing data containers, namely arrays and strings (which are special
> arrays of characters), should be enhanced and new data containers introduced.
> For example the current array could be internally implemented as a C++ deque,
> which would make it work like the current one plus you can freely resize it
> (larger or smaller), append elements at the beginning and at the end, and
> you can still access any element fast, and none of these operations will be
> slow (eg. resizing does not require copying/moving any existing elements).
> Even inserting or removing elements from the middle of the array would be
> possible, although it would not be a constant-time operation.
The Asymptote array concept provides a fairly flexible sort of array:
http://asymptote.sourceforge.net/doc/Arrays.html
The internal representation is derived from deque i think.
Christoph
--
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson a écrit :
> Is it still ray-tracing? You only get an image that is based on a ray-traced
> one. But if you end up with what you want, then OK.
It's not raytracing, indeed, it's post-processing. The post-processing
included in megapov (for example) isn't raytracing, either. The purpose of
post-processing is precisely to allow some transformations over the already
rendered image, ideally using more data (like depth or normals) than the image
itself, but it happens AFTER rendering, which makes it fast and flexible.
If we are discussing render-time effects, well, okay, but let's not call it
POST-processing, then. Just call it 'effects' (and limit them to things
that *cannot* be done in post-processing).
Nevertheless, simultaneous output of rendered image, and depth, normal,... data
would allow extremely interesting things to be done (besides being easy to
implement).
(BTW, thinking of it, being able to simultaneously output images with different
settings would be great; i.e : rendering an image with and without media,
but doing intersection calculations only once; of course, it becomes
complicated...)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> How, in the system you envision, will I be able to change the
>> focal point and get a new image within a few seconds, instead
>> of taking 3 hours to re-render everything ?
>
> Regardless of which method is used it's clear that povray must keep
> all the necessary information in files (or at the very least in memory)
> between renders.
>
> There could be a few possibilities:
>
> 1) An option to tell POV-Ray to write all the necessary information on files.
> Then if you want to re-post-process, you just use the option +C to skip
> the rendering.
> One disadvantage of this is that you have to remember to use the option
> if you want to be able to post-process multiple times.
If POV-Ray "sees" there's a file with post-process data, it can ask the
user if he really wants to re-render or not. Also, an "archival" mode (POV-Ray
gives an automatically numbered name to its output) would avoid any
dangerous overwrite (and allow to easily keep a record of an image's evolution,
which is currently tedious).
> 2) POV-Ray could always write the extra info on files, allowing
> post-processing whenever you want.
> The disadvantage is that it will consume disk space and the user would
> have to manually delete those unneeded files to clean it up.
Disk space is cheap in these days of hard-disks filled with music and videos.
> 3) POV-Ray could automatically write the info on files and keep them there
> as long a it's running, and when it's closed, it removes them (unless
> an option is given). This would allow re-post-processing the image as
> many times as necessary as long as POV-Ray is running.
> The disadvantage is that this idea doesn't work with the command-line
> version. Another slight disadvantage is that if the execution of the
> program is ended abruptly, the files will be left there.
>
> 4) As 3, but the info is kept in memory until next render.
> Doesn't garbage the disk, but has the same disadvantages.
>
> Make your pick, or suggest something better.
All in all, I think that there could be a choice (for the user) between :
1) write to files, keep it forever (default)
2) write to files, keep it until session ends
I think that "keep in memory" would quickly lead to memory saturation (fast
memory is precious for rendering).
Option 2 would be unavailiable to command-line, but there could be a script
to clean unused files afterwards. Maybe the files (in option 2) could be
written in some temporary path.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson wrote:
>
> Right.
>
> But the concern is so present that the question of a new SDL is 'on air'
> since quite a while, made this discussion happen, and interests a lot of
> people (I think). And I bet that those people you mentionned, once/if ever
> POV has its new nice syntax with new long-awaited features, will be the
> first to use it with greed ... The demand for new POV-SDL araised from the
> lacks and drawbacks of POV, even if it is a marvelous tool.
>
> Bruno
:)
I guess you would call me one of "those people".
Don't get me wrong, I'm not against a new language perse but I am against "a
new language for the sake of a new language". If at the end of the
discussion it turns out that the current SDL cannot be cleaned up/extended
to do what we all want it to do, then off course we need a new language.
But implementing a new language has major cons.
1) All current and older projects are useless because of loss of backwards
compatibility.
2) We'll upset/drive away a good portion of the current userbase because of
the new syntax.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien escribió:
> If POV-Ray "sees" there's a file with post-process data, it can ask the
> user if he really wants to re-render or not. Also, an "archival" mode
> (POV-Ray
> gives an automatically numbered name to its output) would avoid any
> dangerous overwrite (and allow to easily keep a record of an image's
> evolution,
> which is currently tedious).
That's just a GUI detail. Well, you *better* aren't thinking on adding
"ask the user" to the rendering backend...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez a écrit :
> Fa3ien escribió:
>> If POV-Ray "sees" there's a file with post-process data, it can ask the
>> user if he really wants to re-render or not. Also, an "archival" mode
>> (POV-Ray
>> gives an automatically numbered name to its output) would avoid any
>> dangerous overwrite (and allow to easily keep a record of an image's
>> evolution,
>> which is currently tedious).
>
> That's just a GUI detail. Well, you *better* aren't thinking on adding
> "ask the user" to the rendering backend...
That would logically be done at front-end (CLI or GUI) level.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Disk space is cheap in these days of hard-disks filled with music and videos.
Not when rendering animations.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> Disk space is cheap in these days of hard-disks filled with music and videos.
>
> Not when rendering animations.
Well, let's give the option to not keep the files, then.
(hope some wiki or dedicated group will come soon, this thread
is becoming huge !)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <No.### [at] ThankYou> wrote:
> I guess you would call me one of "those people".
> Don't get me wrong, I'm not against a new language perse but I am against "a
> new language for the sake of a new language". If at the end of the
> discussion it turns out that the current SDL cannot be cleaned up/extended
> to do what we all want it to do, then off course we need a new language.
> But implementing a new language has major cons.
> 1) All current and older projects are useless because of loss of backwards
> compatibility.
> 2) We'll upset/drive away a good portion of the current userbase because of
> the new syntax.
>
> --
> Ger
That's not so obvious to me. AFAIK, compatibility problems already happened
in POV's life when the syntax evolved and new features were added. The
#version clause was added for that. If the new syntax inherits enough from
the current one, we can imagine either that the new is a subset of the old
and the new parser will understand old syntax, or converters can be
developped (which is not far from the first case). I can't imagine that the
new syntax makes less features than the old, so I dont't see why there would
be an impossibility.
However, the arrival of a new syntax is a major change, thus we can't hope
making a significant step without some eventual concessions.
Even if lots of nice stuff was produced with pov 3.6 & megapov 1.2.1 syntax,
it appears that many people feel limited and want something new. That's the
reason of this discussion and justifies we think seriously about it and try
to determine the WHAT, the WHY, and the HOW.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Shay <Sha### [at] cccc> wrote:
>> C) Invent and code a new programming language and then code the
>> algorithm in that language.
>
> Right, because all that is necessary for every single algorithm which
> will be ever made for POV-Ray.
>
Not quite. I suppose one set of commands would take care of a handful of
converters. The mesh-handling stuff? Well there's decimation for
marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates
mesh models without a mouse (except me)?
This will all sound a lot better after someone has taken care of the
many things that POV users cannot do (rendering algorithms). After that,
what POV users cannot *conveniently* do might seem a lot more important.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> Not quite. I suppose one set of commands would take care of a handful of
> converters. The mesh-handling stuff? Well there's decimation for
> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates
> mesh models without a mouse (except me)?
I really don't understand your attitude. You are mocking the few
examples given (and even quite illogically at that) and you refuse to
see the big picture behind those examples.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <470313c2@news.povray.org>,
nic### [at] gmailisthebestcom says...
> Patrick Elliott escribió:
> > In article <47024d79$1@news.povray.org>,
> > nic### [at] gmailisthebestcom says...
> >> Umm... Isn't that how things work on *any* loosely-typed language?
> >>
> >> var arr = [123, [12,34], "foo", /\s+public ?(.*)/g, new Sphere(1,2,3
)];
> >>
> >> A valid Javascript array containing a number, another array, a string,
a
> >> regular expression, and a Sphere (provided that the Sphere object was
> >> defined).
> >>
> > Well, all I know is that it wasn't, for what ever reason, possible with
> > the client. That *may* be due to the fact that Java is *not* normally
> > that loosely typed, or that some serious problem existed in ActiveScrip
t
> > which seriously fracked it (since it relies a lot of that for every
> > language except Lua. Though, mind you, half the ActiveScript languages
> > seem to not follow spec anyway and suffer from bloody silly
> > inconsistencies even in how you instance them, never mind get them to d
o
> > anything after they are linked.)
> >
>
> You're mixing up Java and Javascript (they have nothing to do, name
> similarity is apparently because of marketing reasons). Java is
> strongly-typed, Javascript is loosely-typed. Java is compiled into
> bytecode, Javascript is interpreted. Java has classes, Javascript has
> prototype-based OOP instead.
>
I realize there are differences between them, didn't know that was one
of them though. I still don't like the syntax that well. My point was
though that you get the same issues trying to use something like Python.
It didn't link the same way, even though it should have, and worse,
there actually seems to be some sort of insane memory leak in it,
triggered when you drop in some temp code to run, then try to remove it
again. We are not sure if its garbage collection not handling the
deleted code correctly or what, but its frustrating.
Oh, and using Java may not be useful precisely *because* it relies on
compiled Bytecode. Why? Because I am not sure how well it can handle
shifting code in/out on the fly, and while I am not sure how/if that
would be useful in POVRay, since it kind of assumes you are going to
render one frame, then exit, it is a nice things to have some times.
Like say you have a flag to turn off a certain feature, while testing
colors, because it slows things down. So, you figure, "Ok, color is
good, so lets just type in "myflag = 1", so the next frame will render
"with" the feature turned on, so I can see it that is working too,
without having to restart the entire render." Sure, its not the sort of
thing you "expect" to be doing in a program like this, but it can be
useful some times to have immediate execution of a comment "into" the
code that is already running, in some cases. You can't do that with
compiled code.
Now, whether there is a legitimate reason to allow such a thing in
POVRay is another question entirely, as well as how that would effect
speed. But it is something that might be considered. Its also used in
the client I use to do things like reacting to some event, then
inserting code to do some specific task "at that event". Probably not
useful or necessary for POVRay, since coding that in directly, then re-
running the script, is probable just as easy, but again, its something
that could be done real time, even as processing is being done, in the
client I use, while a compiled language simply wouldn't support it.
Useful for something like POVRay or completely useless? Not sure myself.
I am sure I could think of uses for it "if" I had the option, but
thinking of them now is a bit harder.
--
void main () {
If Schrödingers_cat is alive
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4703e3e6@news.povray.org...
> Shay <Sha### [at] cccc> wrote:
>> Not quite. I suppose one set of commands would take care of a handful of
>> converters. The mesh-handling stuff? Well there's decimation for
>> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates
>> mesh models without a mouse (except me)?
>
> I really don't understand your attitude. You are mocking the few
> examples given (and even quite illogically at that) and you refuse to
> see the big picture behind those examples.
Erm... calm down Warp. I've read every post here and Shay has offered
no less than anyone else. As it happens, from a non-programmers point of
view, I think this thread has been a frenzy of what everyone *wants*, and in
the end, I think nothing will happen directly resulting from this thread
imo.
It's a shame really, because the skill is here, in our very own
community.
(But, I'll be happy to download the 'new' version when it's ready).
~Steve~
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 03.10.2007 20:35, Shay nous fit lire :
> Subdivision? Of what? Who creates
> mesh models without a mouse (except me)?
>
Well, as you ask, me! I transform some solid object in mesh, then
deform them in pov. (personnal edition, of course...)
> This will all sound a lot better after someone has taken care of the
> many things that POV users cannot do (rendering algorithms). After that,
> what POV users cannot *conveniently* do might seem a lot more important.
I'm afraid of a chicken-egg issue in this sterile discussion about SDL.
A full clean-up of the data model would be needed first (far away
from the SDL, at the lowest memory level). Once the future data
model is stable (and beautiful ?), we could look at any rendering
algorithm to see if it fit the actual data or require an extension
(or a bigger evolution). That's something that cannot be done "on
the wind", you need a practical algorithm. Documenting the
data-model could save the trouble for the future generation.
Then, with a reliable data-model, you can have any loony designs its
own SDL to fill that data (or explore it, too). You can even
anticipate a serialisation of the actual data, for easier
saving/loading (including distributed rendering). And again, the
serialisation can be done in whatever loony's designed syntax (XML,
ASN.1 (BER or PER or whatever), bytecode, ...) they want it.
The purpose of parsing is to generate the data for the rendering
engine, everything else are just commodities for the users.
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. <dot### [at] dotcom> wrote:
> As it happens, from a non-programmers point of
> view, I think this thread has been a frenzy of what everyone *wants*
No, it's not about what everyone wants, it's about what POV-Ray needs.
POV-Ray needs to improve, else it will slowly fade into oblivion.
The SMP support in POV-Ray 3.7 bought it time, which is really great,
but I'm afraid that will not be enough in the long run. The SMP support
is a huge card for POV-Ray, but it just needs more if it wants to survive
another 15 years.
One thing which POV-Ray needs is more rendering features which would
bring it back in par with other renderers.
While many such rendering features must be added to the core code
because there's no other option, there are, however, a whole lot of
features which can and should be implemented by scripting. These can
often be implemented as surface shaders and such.
Implementing them with scripting has tons of advantages. The features
become more flexible, easily modifiable (without having to recompile
the entire program) and extensible. POV-Ray should move from a rigid
monolithic architecture to a more flexible architecture where features
can be added without touching the core code. Only features which simply
cannot be implemented with scripting, for example because of efficiency
reasons, should be implemented in the core code.
There are also many other features which would benefit from scripting
support, such as importing and exporting of file formats (how many times
has a converter from POV-Ray to other formats been requested?)
Also, POV-Ray cannot simply drop its scripting language. This is simply
because the scripting language is one of the major features, which
differentiates it from many other similar renderers. I fear that if
POV-Ray was a pure renderer, with no scripting support, it would have
been forgotten long time ago.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escribió:
> POV-Ray should move from a rigid
> monolithic architecture to a more flexible architecture where features
> can be added without touching the core code. Only features which simply
> cannot be implemented with scripting, for example because of efficiency
> reasons, should be implemented in the core code.
In my opinion, it's currently in a state where it is a rigid monolithic
architecture where adding features even by touching the core code is
very hard. It should start by being flexible there. Then make it scripted.
Adding a pattern, an object, a camera projection, or a different
lighting algorithm shouldn't take months of trying to figure out the
existing code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> In my opinion, it's currently in a state where it is a rigid monolithic
> architecture where adding features even by touching the core code is
> very hard. It should start by being flexible there. Then make it scripted.
Making it scripted is exactly the way to move out from being monolithic.
You can't separate these two things.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> No, it's not about what everyone wants, it's about what
> POV-Ray needs.
The Big Picture:
What POV-Ray needs to survive for another 15 years is for a decent
number of people to post high-quality work on places like CGTalk. For
that to happen, the program needs rendering capabilities and users.
Features like shaders (with necessary procedural capabilities), improved
motion-blur, improved AA, nurbs, an accessible scripting language, and
modeller integration will draw more users and allow those and current
users to create more impressive works. Adding clutter (and almost
certainly new bugs) to the interface for the purpose of overlapping the
capabilities of existing, non-renderer tools will not.
The low-level language creating the mid-level language creating the
high-level language (resulting in "#include ... function-call ( ...") is
a programmer's fantasy somewhat like "you can use c++ as a high-level
language if you have the right libraries." Introduce lower-level
programming tools into the SDL for the purpose of coding
mesh-manipulation or text-reading libraries, and these tools will creep
into the high-level (common user) code. The effect of this is that
examples of POV SDL become nearly useless to those not familiar with a
very large portion of the SDL.
> Also, POV-Ray cannot simply drop its scripting language. This is
> simply because the scripting language is one of the major features,
> which differentiates it from many other similar renderers.
Agreed, but this scripting support must be accessible to draw and keep
users.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:47040a89@news.povray.org...
> St. <dot### [at] dotcom> wrote:
>> As it happens, from a non-programmers point of
>> view, I think this thread has been a frenzy of what everyone *wants*
>
> No, it's not about what everyone wants, it's about what POV-Ray needs.
Well, yes, that's true.
>
> POV-Ray needs to improve, else it will slowly fade into oblivion.
I'm with you, I understand this.
> There are also many other features which would benefit from scripting
> support, such as importing and exporting of file formats (how many times
> has a converter from POV-Ray to other formats been requested?)
True, many, many, times.
>
> Also, POV-Ray cannot simply drop its scripting language. This is simply
> because the scripting language is one of the major features, which
> differentiates it from many other similar renderers. I fear that if
> POV-Ray was a pure renderer, with no scripting support, it would have
> been forgotten long time ago.
Couldn't we just call Moray 'Pov-Ray', and work with that?
~Steve~
>
> --
> - Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> Agreed, but this scripting support must be accessible to draw and keep
> users.
I second that. Simple things (and moderately complex things) that we do
now with POV 3.6 must remain simple to do in any future development.
However, provided the above, being able to do more complex things, or
doing it with more flexibility, on top of that, is a necessary evolution.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> Adding clutter (and almost
> certainly new bugs) to the interface for the purpose of overlapping the
> capabilities of existing, non-renderer tools will not.
For some reason you have this obsessive fixation about "if it can be
done with third-party tools, it should not be added to POV-Ray".
Well, you know what? 3D images can be rendered with third-party programs.
Thus, by your logic, rendering support is not necessary in POV-Ray because
you can do it with other programs.
So what if you can calculate subdivision of meshes with third-party tools.
Can you guess how many of these tools I have in my computer? Moreover, can
you guess how many of these tools are not available at all for my OS?
Besides, even if I had a subdivision-capable program available for my OS,
it would still be clumsy to use. I would have to create or convert the mesh
to a format supported by that program, then I would have to perform the
subdivision, then I would have to export or convert the result to a POV-Ray
mesh, and then I would have to write the SDL file to read that mesh.
Naturally this becomes more complicated if the original mesh was created
with POV-Ray itself (for example I have an include file which creates a
mesh in the shape of a surface of revolution, given the outline spline).
It would be really, really handy if I could perform the subdivision in
POV-Ray itself. No conversions, no saving, no temporary files, no nothing.
Just one command and there you are: I have the subdivided mesh.
Why you think enhancing POV-Ray in a way that allows creating this kind
of functionality is a bad thing goes beyond my comprehension.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. <dot### [at] dotcom> wrote:
> Couldn't we just call Moray 'Pov-Ray', and work with that?
No, because Moray is windows-only.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> St. <dot### [at] dotcom> wrote:
>> Couldn't we just call Moray 'Pov-Ray', and work with that?
>
> No, because Moray is windows-only.
I think he's joking...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> So what if you can calculate subdivision of meshes with third-party tools.
> Can you guess how many of these tools I have in my computer? Moreover, can
> you guess how many of these tools are not available at all for my OS?
Good example. Imagine you have a mesh which requires subdivision, and are
making an animation. If POV-Ray performs the subdivision, various instances
of the mesh could be subdivised at different levels, according the distance
from the camera (thus optimizing memory requirements and rendering time).
It wouldn't be easy to get that with an external tool.
Advanced features such as displacement mapping would also benefit from an
integrated model (well, the list is long).
Of course, there are features that would be better handled externally,
but, before saying "it shouldn't be within POV-Ray", first answer the
question : "won't it be faster or more flexible if done within POV-Ray ?".
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Good example. Imagine you have a mesh which requires subdivision, and are
> making an animation. If POV-Ray performs the subdivision, various instances
> of the mesh could be subdivised at different levels, according the distance
> from the camera (thus optimizing memory requirements and rendering time).
> It wouldn't be easy to get that with an external tool.
Also: Being able to subdivide using POV-script allows more flexibility.
For example, suppose you want to subdivide the mesh only at parts which
are outside of a given object, but not in parts which are inside. Or you
want to subdivide only at places where the mesh is green.
Those kinds of things would be simply *impossible* with a third-party
tool.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > Good example. Imagine you have a mesh which requires subdivision, and are
> > making an animation. If POV-Ray performs the subdivision, various instances
> > of the mesh could be subdivised at different levels, according the distance
> > from the camera (thus optimizing memory requirements and rendering time).
> > It wouldn't be easy to get that with an external tool.
>
> Also: Being able to subdivide using POV-script allows more flexibility.
>
> For example, suppose you want to subdivide the mesh only at parts which
> are outside of a given object, but not in parts which are inside. Or you
> want to subdivide only at places where the mesh is green.
> Those kinds of things would be simply *impossible* with a third-party
> tool.
>
> --
> - Warp
Can we imagine a fragment of code like this:
my_mesh = mesh { ... } // or: pov.primitive.Mesh.read("body.msh");
my_mesh.nose.subdivide(...);
my_mesh.nose.smooth(...);
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Fa3ien" <fab### [at] yourshoesskynetbe> wrote in message
news:47050742$1@news.povray.org...
> Warp a écrit :
>> St. <dot### [at] dotcom> wrote:
>>> Couldn't we just call Moray 'Pov-Ray', and work with that?
>>
>> No, because Moray is windows-only.
>
> I think he's joking...
No, I wasn't, I didn't know that. I have it, but don't use it. Anyway,
why can't it be ported then?
~Steve~
>
> Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> As you might have noticed, not everybody is convinced we should have one (SDL).
hello?! Drop povray's SDL and povray is just among many rendering engines.
I believe to be the crown jewel of povray!
We should have one and only povray SDL and it should have easy syntax and
semantics, should be mostly declarative interspeced with a few useful
control flow commands and should be modular. If someone wishes to program
in another language which suits his needs best, do it and create a program
in said language which compiles his scene or library to povray SDL, just
like today.
I think if povray loses its SDL, it'd lose its identity. If it shipped just
with some sort of bytecode VM for which lots of languages could compile to,
it'd still lose its identity.
Povray needs its SDL, period.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien wrote:
>
> Imagine you have a mesh which requires subdivision, and are
> making an animation. If POV-Ray performs the subdivision,
> various instances of the mesh could be subdivised at different
> levels, according the distance from the camera
Best example I've seen yet, and a very compelling, but I'm not sold.
This simplification would require more than just distance to the camera,
angle of incidence would also have to be considered. The system would
need to be fairly complex to produce a decent result, and characters,
landscape, and teapots would all require different rules. One person
might someday do this if the SDL were extended enough.
But how many people are we excluding by obfuscating the SDL?
When much of the code in p.text.s-f looks like this:
MacroName (*Param1, %Param2%$, ....)
new users will not be willing to commit to learning POV's (among free
renderers) "Killer App" (scripting interface).
"Scripting" may mean something different to programmers. but it means
something particular to me - something distinct from "Programming." I
think POV is best served by a "Scripting Interface."
I've said several times that if it's necessary for shaders, it needs to
be included. Modeling *will* be done 99% with outside apps, no matter
what is included in the SDL. A lot lost for very little gained IMO. If a
non-user read this thread, he might conclude that there are scores of
people hand-coding complex scenes in POV or MEL[1], just champing at the
bit waiting for the ability to make even more complex scenes this way -
this is NOT the case.
-Shay
[1] Maya scripting interface
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay <Sha### [at] cccc> wrote:
> Best example I've seen yet, and a very compelling, but I'm not sold.
Ok, clearly there's no way to convince you, so we can stop trying.
You have expressed your opinion at it has become clear. Case closed.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escribió:
> St. <dot### [at] dotcom> wrote:
>> Couldn't we just call Moray 'Pov-Ray', and work with that?
>
> No, because Moray is windows-only.
>
Not necessarily forever ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> But how many people are we excluding by obfuscating the SDL?
Who wants to obfuscate the SDL ? I believe (and hope I'm right)
that its both possible to have a simple SDL, accessible
even to beginners, and to have new extended programming possibilities.
(and 90% backward compatibility, too). That should be
verified by producing theorical SDL code for simple situations.
> When much of the code in p.text.s-f looks like this:
> MacroName (*Param1, %Param2%$, ....)
> new users will not be willing to commit to learning POV's (among free
> renderers) "Killer App" (scripting interface).
As I already said, it's all a matter of compromise. POV-Ray's SDL
won't be a "full featured" OO language like C++ or such. I imagine*
there would be :
- no pointers
- only a few data types (we don't need an "integer" type, for example)
- no polymorphism or other advanced brainf***ing technique
- ... ?
(* : Warp, don't jump on this, it's only some vague speculations)
> "Scripting" may mean something different to programmers. but it means
> something particular to me - something distinct from "Programming." I
> think POV is best served by a "Scripting Interface."
POV-Ray's current SDL is already a programming language. There are
loops, conditional, and functional macros. What is needed is mainly to
enhance these, for speed (macros are currently darn slow) and
flexibility. And some object-orientedness won't harm.
> I've said several times that if it's necessary for shaders, it needs to
> be included. Modeling *will* be done 99% with outside apps, no matter
> what is included in the SDL.
90% of my scenes (well, when I did scenes) were done in SDL.
95% of my meshes were done by an external app (of course), but
there's much more than meshes in a POV-Ray scene. If CSG could be
instanciated, and if we had more programming power (and speed) within
SDL, we could make images of unprecedented complexity, images that
couldn't be done with any other app, while not requiring extreme skills.
If you look at Gilles Tran's images, you will see that, except for
pre-made people, cars, and such, everything is done in SDL.
> A lot lost for very little gained IMO. If a
> non-user read this thread, he might conclude that there are scores of
> people hand-coding complex scenes in POV or MEL[1], just champing at the
> bit waiting for the ability to make even more complex scenes this way -
> this is NOT the case.
Non-users, don't read this, please :-)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay a écrit :
> But how many people are we excluding by obfuscating the SDL?
Who wants to obfuscate the SDL ? I believe (and hope I'm right)
that its both possible to have a simple SDL, accessible
even to beginners, and to have new extended programming possibilities.
(and 90% backward compatibility, too). That should be
verified by producing theorical SDL code for simple situations.
> When much of the code in p.text.s-f looks like this:
> MacroName (*Param1, %Param2%$, ....)
> new users will not be willing to commit to learning POV's (among free
> renderers) "Killer App" (scripting interface).
As I already said, it's all a matter of compromise. POV-Ray's SDL
won't be a "full featured" OO language like C++ or such. I imagine*
there would be :
- no pointers
- only a few data types (we don't need an "integer" type, for example)
- no polymorphism or other advanced brainf***ing technique
- ... ?
(* : Warp, don't jump on this, it's only some vague speculations)
> "Scripting" may mean something different to programmers. but it means
> something particular to me - something distinct from "Programming." I
> think POV is best served by a "Scripting Interface."
POV-Ray's current SDL is already a programming language. There are
loops, conditional, and functional macros. What is needed is mainly to
enhance these, for speed (macros are currently darn slow) and
flexibility. And some object-orientedness won't harm.
Before POV 3.0, POV-Ray was pure scripting. You had to use an
external proggy to create a spiral. Imagine that ! When 3.0
and its programming features, though somewhat simplistic, arrived,
a new world opened, just have a look at the images produced before
and after. When 3.1 introduced macros, another new world opened, 3.1
have been the pinnacle. Let's open new worlds again ! Let's go higher !
> I've said several times that if it's necessary for shaders, it needs to
> be included. Modeling *will* be done 99% with outside apps, no matter
> what is included in the SDL.
90% of my scenes (well, when I did scenes) were done in SDL.
95% of my meshes were done by an external app (of course), but
there's much more than meshes in a POV-Ray scene. If CSG could be
instanciated, and if we had more programming power (and speed) within
SDL, we could make images of unprecedented complexity, images that
couldn't be done with any other app, while not requiring extreme skills.
If you look at Gilles Tran's images, you will see that, except for
pre-made people, cars, and such, everything is done in SDL.
> A lot lost for very little gained IMO. If a
> non-user read this thread, he might conclude that there are scores of
> people hand-coding complex scenes in POV or MEL[1], just champing at the
> bit waiting for the ability to make even more complex scenes this way -
> this is NOT the case.
Non-users, don't read this, please :-)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp a écrit :
> Shay <Sha### [at] cccc> wrote:
>> Best example I've seen yet, and a very compelling, but I'm not sold.
>
> Ok, clearly there's no way to convince you, so we can stop trying.
> You have expressed your opinion at it has become clear. Case closed.
The goal of this discussion, IMO, is not to convince someone that
someone else is right, it's to draw a picture of what can be ahead,
including the pros and the cons of any proposal.
His worries are perfectly licit and likely represent those of many
people. This should be adressed with enough distanciation.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Warp a écrit :
> > Shay <Sha### [at] cccc> wrote:
> >> Best example I've seen yet, and a very compelling, but I'm not sold.
> >
> > Ok, clearly there's no way to convince you, so we can stop trying.
> > You have expressed your opinion at it has become clear. Case closed.
>
> The goal of this discussion, IMO, is not to convince someone that
> someone else is right, it's to draw a picture of what can be ahead,
> including the pros and the cons of any proposal.
>
> His worries are perfectly licit and likely represent those of many
> people. This should be adressed with enough distanciation.
>
> Fabien.
I don't really see that this kind of support is a key point in POV 4, but I
also don't see how it could be a bad thing. I suspect the people spending
time implementing these libraries in SDL' aren't going to be the same
people writing the core code, or rather they don't have to be.
On the mesh issue, render-time subdivision would be interesting, although
for me textures usually seem to outweigh meshes in storage requirements,
and (again for me) minimising render time is more important than memory
use. Render-time subdivision is nice for the first use case, and I would
hope it wouldn't adversely affect the other. I can't see myself making much
use of more general mesh manipulation capabilities in POV, but I can't see
the negative impact, really. From the description it sounds like they would
be a "there-if-you-need-them" feature.
Other things I wanted to mention:
* There seems to be a lot more talk about the future SDL than any future
rendering capabilities.
* Specifically on programmable shaders, how will we maintain backwards
compatibility to the somewhat bitty and odd features like irid? Built-in
shader "library"?
* Probably been mentioned before, but I can't remember; will POV 4.0
incorporate any code at all from 3.7, or will it be a complete rewrite?
* I love media {}. Most of the jobs it fails at are actually jobs for an
improved shading language, in my view. For many things it's excellent, even
compared to some professional applications, unusually.
Tom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> His worries are perfectly licit and likely represent those of many
> people. This should be adressed with enough distanciation.
His worries may be valid, but his proposed solution is not.
He has got it completely backwards. The new scripting language is going
to make the core code *simpler*, not more complicated (because tons of
features currently in the core code can be removed from there and moved
to libraries). Also there's nothing in a more powerful scripting language
that will automatically make it harder for the average user to use. In
fact, it could well be the opposite: If well designed, the new scripting
language could be *easier* to use than the current SDL (or at least make
many things a lot easier).
With a powerful scripting language lots of features of the core code
can be removed from there, making the core code smaller and simpler, and
it will then be easier to add features to the core code which really need
to be there (if they can't be implemented in the scripting language or it
would be too inefficient to do so).
Also a well-designed scripting language will make it much easier to
offer an easy-to-use interface to the core features. In the current SDL
each time a new feature is added, adding the correspondent SDL construct
is usually a pain, makes the parser more complicated and overall has a lot
of overhead.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Shay wrote:
> Warp wrote:
>> Shay <Sha### [at] cccc> wrote:
>>> C) Invent and code a new programming language and then code the
>>> algorithm in that language.
>>
>> Right, because all that is necessary for every single algorithm which
>> will be ever made for POV-Ray.
>>
>
> Not quite. I suppose one set of commands would take care of a handful of
> converters. The mesh-handling stuff? Well there's decimation for
> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates
> mesh models without a mouse (except me)?
>
I do (sometimes)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> As you might have noticed, not everybody is convinced we should have one (SDL).
>
> hello?! Drop povray's SDL and povray is just among many rendering engines.
> I believe to be the crown jewel of povray!
So do I. "one" did not refer to "SDL", as you are apparently assuming,
but to "new SDL".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
St. wrote:
[snip]
> As it happens, from a non-programmers point of
> view, I think this thread has been a frenzy of what everyone *wants*,
What I get from the thread so far is that:
- syntax of the declarative part (objects, textures, transformations,
...) should stay the same.
- the control structures with # (#if, #macro, ...) should stay (at least
for now)
- there should be a new set of control structures. Especially to replace
the #declare and #macro. This should be closer to a conventional
programming language
- it should be possible to create new objects with the same syntax as
current ones (box, sphere, etc.)
- More of the internals should be exposed. The representation of e.g. a
mesh should be known and modifiable at user level to create a
subdivision, to convert an isosurface of the fly into a mesh, to write
new import routines, etc.
- At many points it should be possible to call user functions in stead
of predefined choices. And those functions should be able to call many
internal functions. This is needed for new shaders and such.
- binary input and output should be supported from within new style
functions.
> and in the end, I think nothing will happen directly resulting from
> this thread imo.
I expect all of these things to be in POV4.
Anyone dare to answer the question on whether POV4 should be a scene
description language or a scriptable ray tracer?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
