> 
> Written in an interpreted (or maybe p-code) language.  Not fast enough for 
> raytracing by a long shot.
> 


???? My option is, that GIMP plug-in is a piece of C code, which is 
compiled on target platform with gimptool, so it is not interpreted...

>

Post a reply to this message

>>
> 
> And still not ready for primtime on Win32


But GIMP for Win32 exists?? OK, I don't tried it, I don't use this M$ 
thing..

> 
> --

Post a reply to this message

On Thu, 04 Oct 2001 12:06:53 +0200, Disnel wrote:
>> 
>> Written in an interpreted (or maybe p-code) language.  Not fast enough for 
>> raytracing by a long shot.
>> 
>
>
>???? My option is, that GIMP plug-in is a piece of C code, which is 
>compiled on target platform with gimptool, so it is not interpreted...

I'm pretty sure that most plugins for the GIMP are written in Scheme, but
I suppose I could be misremembering.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

>
> 
> I'm pretty sure that most plugins for the GIMP are written in Scheme, but
> I suppose I could be misremembering.


Yes, a lot of plugins are in scheme, but there is also possibility to 
create compiled plugin (for example gimpprint plugin)

> 
>

Post a reply to this message

On Thu, 04 Oct 2001 17:06:30 +0200, Disnel wrote:
>>
>> 
>> I'm pretty sure that most plugins for the GIMP are written in Scheme, but
>> I suppose I could be misremembering.
>
>
>Yes, a lot of plugins are in scheme, but there is also possibility to 
>create compiled plugin (for example gimpprint plugin)

But then we come back to the problem of requiring anyone who wants to use
POV to have access to a compiler of some sort, or of creating our own compiler
for plugins.  The first is, IMHO, an unfair expectation given the nature of
most POV users.  The second is a lot of work.  That's not to say it will never
happen, because we are moving in that direction slowly with things like the 
new function evaluation engine in POV 3.5 (here I'm thinking of features of 
the function engine that haven't been made public yet, so you'll have to take
my word for it) but it's not going to happen overnight.

In any case, it turns out that there aren't that many primitives that are
just begging to be added.  Most of the patches collected in MegaPOV fall 
into three categories: 
 - general, widespread changes to the rendering engine (photons, dispersion, 
   light groups, UV mapping) 
 - parser-only changes (most of mine: #ifdef(A[i]), trace, min/max_extent)
 - new textures or variations on old textures (object pattern, crackle)

The only really new primitives are the isosurface and the parametric 
object, and I can't envision trying to implement either of them as a
plugin even if the mechanism for doing so existed.  I certainly can't see
being able to make the changes necessary to make pigment functions if
isosurfaces *were* implemented as a plugin.

Recently, the most-requested features have been more texture-oriented 
things (lighting models, subsurface scattering, blurred reflection) and
more widespread changes (tesselation).  I haven't heard a lot of people
asking for new primitives.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

Ron Parker wrote:

> On Thu, 04 Oct 2001 17:06:30 +0200, Disnel wrote:

> But then we come back to the problem of requiring anyone who wants to use
> POV to have access to a compiler of some sort, or of creating our own compiler
> for plugins.  The first is, IMHO, an unfair expectation given the nature of
> most POV users.


OK this is true. I have slightly different point of view, because I'am 
using only linux and there I have always compiler.

> The second is a lot of work.  That's not to say it will never
> happen, because we are moving in that direction slowly with things like the 
> new function evaluation engine in POV 3.5 (here I'm thinking of features of 
> the function engine that haven't been made public yet, so you'll have to take
> my word for it) but it's not going to happen overnight.


I think, that this is nearly impossible to create "unviersal compiler" 
for all processors and systems.

> 
> In any case, it turns out that there aren't that many primitives that are
> just begging to be added.  Most of the patches collected in MegaPOV fall 
> into three categories: 
>  - general, widespread changes to the rendering engine (photons, dispersion, 
>    light groups, UV mapping) 
>  - parser-only changes (most of mine: #ifdef(A[i]), trace, min/max_extent)
>  - new textures or variations on old textures (object pattern, crackle)
> 
> The only really new primitives are the isosurface and the parametric 
> object, and I can't envision trying to implement either of them as a
> plugin even if the mechanism for doing so existed.  I certainly can't see
> being able to make the changes necessary to make pigment functions if
> isosurfaces *were* implemented as a plugin.

> 
> Recently, the most-requested features have been more texture-oriented 
> things (lighting models, subsurface scattering, blurred reflection) and
> more widespread changes (tesselation).  I haven't heard a lot of people
> asking for new primitives.


This all is true, again, but plugins may be used not only for new 
primitives..

But maybe sufficient solution will be new C++ design of POV4 with 
possibility to add new things as childrens of some POV classes, I only 
like idea of plugins, which I can download and add to my local copy of 
POV without recompilation of whole package....

> 
>

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Thu, 04 Oct 2001 17:06:30 +0200, Disnel wrote:
> >>
[snip]
> In any case, it turns out that there aren't that many primitives that are
> just begging to be added.

    Well, now that you bring it up -- heh,heh -- Has anyone checked out Softy3D?
There is a link to it on povray links pages. I think blob-able splines would be
cool. And like that program, if blobs in general had grouping capabilities
(similiar to light groups) that would be super-cool. :D

>Most of the patches collected in MegaPOV fall
> into three categories:
>  - general, widespread changes to the rendering engine (photons, dispersion, >
light groups, UV mapping)
>  - parser-only changes (most of mine: #ifdef(A[i]), trace, min/max_extent)
>  - new textures or variations on old textures (object pattern, crackle)
>

    Speaking of textures. . . I noticed some odd, but not unexpected (after some
consideration) behavior while experimenting with cutaway textures and uv_mapped
boxes. It led me to implement a generic box-mapping function. The process wasn't
too difficult and it works well on several arbitrary shapes(objects that taper
too much need a little work though, but I think it can be done without too much
more effort).

Given your relatively strong mathematical skills and programming prowess,(not to
mention those of the other programming team members as well) I have to wonder
"What were map_types 3&4 ("still under development" since at least 2.2) supposed
to be?" And, "Why isn't one of them a box-mapping type?" And, "What about a
box-mapping warp type?"

I don't suppose any necessity for these implementations of box-mapping now with
the pigment functions. It's just one of those things that make me go
"Hmmmmmmmmm."

--
Batronyx ^"^
bat### [at] cadronhsacom //old & going away
bat### [at] alliancecablenet new & active now.
http://www.batronyx.com

Post a reply to this message

POV is a get-it-and-shut-up thing.

If you like it, use it.
If you can live with its limits, work around them.
In any other case, shut up and look somewhere else.

There is no point in asking for changes.

Alessandro Coppo
a.c### [at] iolit

P.S.: there is also another route, but this requires rolling up sleeves 
and writing code...

Post a reply to this message

Alessandro Coppo schrieb in Nachricht <3BC### [at] iolit>...
>POV is a get-it-and-shut-up thing.

[...]
>There is no point in asking for changes.


I can't agree with you here. I once mentioned a pattern-type feature that
would be cool. It did not take long (days, not weeks) and someone had
written the code for something similar. It was not the same I asked for, but
one would have been able to achieve similar results with it. Okay, that
patch was never published, but that did not matter that much, as I went on
and was already at another project. And the author was willing to send a
copy to me.

I'm sure, this is not a one-time-event. Those programmers here do really
listen to things people ask for. Try the same with multi $ products. They
will take your money, but they won't incorporate your wishes. The Pov-Team
won't take your money and if you are able to convince them, that your way is
the better one (including necessary programming time and conception) - I
can't imagine, that they were not at least interested. And don't forget:
It's their program not ours. It's their time which they are willing to spend
to produce something which becomes even better all the time.

They even share the code with the community, so you don't even have to
convince one of the Pov-Team programmers to incorporate your wishes.
Everyone with knowledge of C(++) and a compiler can do it for you.

So where is the point in complaining? What do you want to achieve by that?

Just my two "only-user" Groschen,

Marc-Hendrik

Post a reply to this message

In article <3BB### [at] hlavacek-partnercz> , Disnel 
<dis### [at] hlavacek-partnercz>  wrote:

> I think, that this is nearly impossible to create "unviersal compiler"
> for all processors and systems.

No, not really.  It is very simple but has one catch: The compiler will not
deliver optimal code.  Still, you get at least 10 to 20 times the speed of a
purely emulated virtual machine.

But as Ron mentioned, writing a just-in-time compiler is no trivial task at
all and takes a lot of time...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message