 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 () {
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 () {
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...
> > 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 () {
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...
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>
>>> 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
\__ \__ \_______________________________________________________________
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:
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >
> >>> 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
|
|
| |
| |
|
|
|
|
| |
|
|
