 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <405b66f8@news.povray.org>,
> David Burnett <var### [at] ntlworld com> wrote:
>
>
>>Functions that can be more than one line. I'm guessing
>>that would be number one on the list.
>
>
> Then change functions to allow more complex constructs.
Fine, that we make a number of people happy, and satisfy many needs.
Of course its a lot of work for someone, they would be writing a whole
language parser by the time people stopped suggesting features. After
all I expect to be able to write a version of crackle it this that uses
the checkerboard distance between points. Perhaps it might be better
just to put a complete parser in.
> Lua and Python
> would be too slow for most of the things functions are used for anyway.
Its faster for the things that can't be done in functions right now
though. And if you improve functions, well chances are it would be
faster for the next thing someone thinks about until someone adds it to
SDL.
> The POV-Ray scene description language does some pretty specialized
> things...ever try to describe a scene in another programming language?
> Gets messy, fast.
>
I didn't know we there on about replacing SDL, I thought this was about
extending it via a plugin language. Putting that aside and playing
devil's advocate the only real advantage SDL has is access to run time
information, everything else is syntactical sugar.
>
>>Personally I'd love to see parrot used so you could pick
>>from a range of languages.
>
>
> None of them being very well suited to the task. I think improving
> POV-Ray's language would be a better approach.
>
But much slower to action as there no waiting for a release with the
SDL features you want, or merging unofficial versions until you've got
one with all the features you want. If no one adds that SDL feature
well tough, learn how to add them to pov yourself.
Adding a plugin language would lower barrier for entry for other
programmers. They would not need to have the right compiler environment
VC++ or CodeWarrior or be forced to compile a slower version of pov
because they do not have access to Intel's latest and greatest.
There would also be no dealing with the pov SDL parsing code to add a
quick new function or object.
Dave
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 19 Mar 2004 16:54:29 -0800, Darren New wrote:
> Tyler Eaves wrote:
>> Take a look at psyco. It's essentially a JIT compiler for Python.
>
> Bringing us back to compiled plug-ins?
>
> If anything gets added, Tcl would seem a good way to go. :-)
No, it's a JIT compiler, a python module. It compiles at runtime.
basically you add something like
import psyco
psyco.full()
at the top of your file and it works it's magic.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <405b1638@news.povray.org>,
> David Burnett <var### [at] ntlworldcom> wrote:
>
>
> The main reason against it is the
> support headaches.
>
Then don't support it. I don't expect Alias to support Maya plugin's.
You support the API and that is all. Same level of support as for the
unofficial pov versions.
> There is also a small security issue...if any scene could load and run
> code from a plugin included with it, it would be easy to write a trojan.
Some goes for any program that has plugins. Hell the unofficial pov
versions could have trojans, there is no guarantee that the source
available is the one used to compile the binaries. Same for the
official version. If the pov team would really be that pov could go the
embedded language route, most of them offer sandboxes.
Dave
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <405b7e15$1@news.povray.org>,
David Burnett <var### [at] ntlworldcom> wrote:
> Fine, that we make a number of people happy, and satisfy many needs.
> Of course its a lot of work for someone, they would be writing a whole
> language parser by the time people stopped suggesting features. After
> all I expect to be able to write a version of crackle it this that uses
> the checkerboard distance between points. Perhaps it might be better
> just to put a complete parser in.
A shader language capable of doing this would indeed be very nice. I
started such a thing with my G patch, now called Ember. Basically a
simplified C, with additional features for vectors and colors, written
for fast execution so it would be useful for shaders and other
render-time uses.
> > Lua and Python
> > would be too slow for most of the things functions are used for anyway.
>
> Its faster for the things that can't be done in functions right now
> though. And if you improve functions, well chances are it would be
> faster for the next thing someone thinks about until someone adds it to
> SDL.
They are too slow for anything that would be done at render time, so
they would only be useful for building the scene. And although the
existing POV language has problems doing anything really complex, those
languages would be very clumsy at scene description. Extending the scene
language seems like a far better solution...you end up with a language
that has the required flexibility and power, but is still convenient for
its intended use: scene description.
> I didn't know we there on about replacing SDL, I thought this was about
> extending it via a plugin language. Putting that aside and playing
> devil's advocate the only real advantage SDL has is access to run time
> information, everything else is syntactical sugar.
That syntactical sugar is the primary advantage, and it's a big one.
I'm no longer sure what problem you're trying to fix. You seem to want
additional languages to avoid the limitations of the scene description
language, but that assumes the scene language will always be as limited
as it is now.
> Adding a plugin language would lower barrier for entry for other
> programmers. They would not need to have the right compiler environment
> VC++ or CodeWarrior or be forced to compile a slower version of pov
> because they do not have access to Intel's latest and greatest.
However, it would add another thing to do when porting POV to a new
platform, another external thing that the developers have no control
over, and we would have to support it. And this is for the interpreted
languages you mentioned...compiled plugins *would* require a development
environment.
> There would also be no dealing with the pov SDL parsing code to add a
> quick new function or object.
That isn't exactly difficult. The parsing code is usually the easiest
part to write.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <pan### [at] NOSPAMml1net>,
Tyler Eaves <tyl### [at] NOSPAMml1net> wrote:
> Include files are written in SDL. That's a major limitation from where I'm
> sitting.
The current version is limited, but that will not necessarily always be
so.
> Plus I'm thinking of going beyond what include files can do, by
> providing access to POV internals for things like creating objects.
This would be no easier in Lua or Python than in POV, and by doing it in
POV you could include optimizations for what the plugins will be doing,
while Python and Lua would be extremely slow.
It would be a lot less work to do it in C++, but you're back to being
compiled there.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4058301d@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Speaking of #includes, one thing which may speed up a lot when implementing
> bytecode compiling/interpreting would be to have support for pre-compiled
> include files. That is, include files may be pre-compiled by the user and
> then each time that include file is #included, the already-parsed-and-compiled
> version is quickly loaded instead of the original one. This can save a great
> deal of parsing and compiling.
You just broke Parse_String(). Though you hopefully replaced it with a
better, hard-coded version somewhere along the way...
In my experience, the compiling step usually doesn't take much time. The
language is usually easier to compile than something like C++, and is
much faster than the current parsing method which crawls and jumps
throughout the scene files, seeking around and making many passes over
the same code. A loop can take minutes to execute, but be compiled in
milliseconds.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <cja### [at] earthlinknet> wrote:
> You just broke Parse_String(). Though you hopefully replaced it with a
> better, hard-coded version somewhere along the way...
I said it should be supported, not that it should be the only type
of include file.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Christopher James Huff, you recently wrote in povray.general:
> > Actually it also raytraces.
>
> Well, it certainly uses scanline algorithms heavily.
I can't see anything that indicates that it's using scanline
heavily...
> You can easily tell that the main rendering uses scanlining by the fact
> that it renders the scene object-by-object.
Maybe I'm just blind, but I don't see it rendering single objects at a
time, I see the entire scene being rendered and then refined, but
there are no objects being rendered.... In the 2nd movie I mentioned,
they open the regular Lightwave rendering engine for comparison (after
moving the FPrime window out of the way) and that one does render
object by object.... but none of the FPrime demos do this, they all
render the entire scene at once and refine it (like mosaic mode).
> Something like this could be done in a pure raytracer, but I don't think
> it can be done with POV-Ray's radiosity, reflections and refractions ...
I agree with that, it would probably be quite hard.
- Lutz
email : lut### [at] stmuccom
Web : http://www.stmuc.com/moray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <405b7e15$1@news.povray.org>,
> David Burnett <var### [at] ntlworldcom> wrote:
>
>>the checkerboard distance between points. Perhaps it might be better
>>just to put a complete parser in.
>
>
> A shader language capable of doing this would indeed be very nice. I
> started such a thing with my G patch, now called Ember. Basically a
> simplified C, with additional features for vectors and colors, written
> for fast execution so it would be useful for shaders and other
> render-time uses.
>
I remember that patch, it looked very good, I'd like to see Ember if its
publicly available.
>
>
>> > Lua and Python
>>
>>>would be too slow for most of the things functions are used for anyway.
>>
>>Its faster for the things that can't be done in functions right now
>>though. And if you improve functions, well chances are it would be
>
> They are too slow for anything that would be done at render time
>
We use a raytracer we are used to long waits :-)
I just think dog slow is better than not at all.
>
> That syntactical sugar is the primary advantage, and it's a big one.
> I'm no longer sure what problem you're trying to fix. You seem to want
> additional languages to avoid the limitations of the scene description
> language, but that assumes the scene language will always be as limited
> as it is now.
The problem, when you right right down to the basics is, I would like
it to be easier to add 'features' without the pain of having to break
out the pov source, work out how the parser works and where to plug
in your own code and syntax.
My personal interest is textures, and what I in particular would
want was Turing complete functions, that can return colours or
vectors or floats depending on their use and can be used anywhere
a colour or vector or float is used. By that I mean colour functions
could be used for pigments, vector functions for for warps. Oh
yes and this functions should have access to as much information
about the render as possible, not just x,y,z, the point where
the object was placed. The vector the ray is coming from, the
current colour of the object it the texture is layered. And
those are the one that I can think of of the top of my head.
I'm sure that would be a the less than idea solution for other
peoples wants.
Yes SDL can be extended by someone else, but they might do do the
feature 'I' need.
> However, it would add another thing to do when porting POV to a new
> platform
Most of the languages already have a cross-platform embedding API's,
even parrot.
> another external thing that the developers have no control
> over, and we would have to support it.
As you would have to support language extensions, thats a no win situation.
And this is for the interpreted
> languages you mentioned...compiled plugins *would* require a development
> environment.
>
Well there's no way compiled plugins needing a development environment
The advantage comes form a simplified API.
Not all the scripting languages are interpreted,parrot for example is
JIT'ed so any language used with parrot is JIT'ed.
>
>>There would also be no dealing with the pov SDL parsing code to add a
>>quick new function or object.
>
>
> That isn't exactly difficult. The parsing code is usually the easiest
> part to write.
>
Difference of opinion there. I think the parser code is quite difficult
to get into, especially to a new pov developer. There's a sub thread
about it somewhere in this big thread.
Dave
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <405ca0a7@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> I said it should be supported, not that it should be the only type
> of include file.
It would be trivial to just put a "#nocache" at the beginning of files
not to be cached. I still hope Parse_String() gets replaced with an
internal preprocessor directive, though...it doesn't quite work
perfectly.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
