Tim Cook <z99### [at] bellsouthnet> wrote:
> >   Now, would you care to explain how this basically simple plugin
> > ideology could be embedded into POV-Ray?

> Isn't that what macros are for?  O.o;

  I don't understand what you mean.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Where exactly would you put those lines and what would they do? What will
> > the library contain and where exactly should POV-Ray call the functions
> > in those libraries? Exactly what kind of interface should POV-Ray offer
> > to those libraries and what would they do? How would you write such a
> > library to do what you want? How could you use such library to add a
> > new feature (eg. a new primitive or a new pattern) to POV-Ray?

> Alright, so to get specific, *I* would add a preprocessor directive, 
> that says "the function named X is implemented at offset Y in library 
> Z."  Then POV-Ray, while interpreting the code, when it sees a call to 
> the function X, when it does its normal look-up, would find that it's 
> implemented in the DLL/SO, would load same, and invoke the specified 
> offset, with arguments matching the pattern of arguments supplied in the 
> declaration. Note, this is all pretty bog-standard stuff. :-)

  Perhaps you have reading comprehension difficulties?
  I asked "where?", not "how?".

  And even your answer to "how?" is obscure. Which "function named X"?
POV-Ray has thousands of functions and functionalities. Which one of
them could be overridden by the dll? If you are talking about a whole
new function, where exactly should POV-Ray call that function and
what it should give to it and what it should expect as a result?
What will be the feature the dll will be implementing (and why that
exact feature and not the tons of others in POV-Ray)?

> >   How would you make sure that the library is compilable in all platforms?

> If it only needs an entry point and an exit point, you could provide a 
> wrapper for it that is OS-specific. So for example POV-Ray comes with 
> code that is system-specific and which invokes the external function 
> "MyFunction" or some such. Again, this isn't *difficult*. It just needs 
> to be written.

  You still fail to answer the relevant questions: *Where* should POV-Ray
call these functions and what will they be doing?

  You seem to talk as if plugins where some kind of magic: You just
"plug them in" and they magically add a new feature to the program.
  A patch is exactly that: You merge it to the existing code, recompile
and presto, we have a completely new feature. However, a dll plugin does
not (and simply cannot) work like this because it can't modify the existing
code nor magically insert itself wherever it pleases. The core code needs
to support it specifically for a certain given task. So my question remains:
Where should POV-Ray call the functions in the dll and what will these
functions do?

> Or, as in Tcl, the DLL MyCode.dll has an entry point called 
> InitMyCode(), which registers in the internal tables of the interpreter 
> the names and calling conventions of its functions.

  That sounds to me more like scripting language extensions.
  POV-Ray is more than a scripting language interpreter. How do you
expect to add new rendering features (or modify existing ones) with
just a scripting language extension?

> (Or... compile stuff into some intermediate code and write a JIT for the 
> final step, if you *really* want to. This is *all* solved problems.)

  Now we are starting to go to the right direction:
  Not binary dlls. Scripting language.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Rafal 'Raf256' Maj <spa### [at] raf256com> wrote:
> I think it would be a greate idea. Hmm how about soemthing like this - 
> extent funcitons so that could work as a plugins for doing most things, not 
> only pattern functions (in density, pigment, and so on), but also while 
> shooting rays for camera and in other places.

  You are talking about a more elaborated SDL scripting language (which is
exactly what has been planned for pov4), not a plugin engine.
  In other words, you are in the right track.

-- 
#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

Rafal 'Raf256' Maj wrote:
> I hope this is not a big problem ;) Also there is povray.org not 
> pov-ray.org

   Sure? Did you try? ;)

--
Jaime

Post a reply to this message

> 
> * "It's useless" *
>     Let's assume that I want to use Renderman-like shaders and hdri
> output. How do I do that with the current system? Megapov has hdri but
> no shaders, and povman has shaders but no hdri. This is something that
> will crop up every time two people implement some great new features
> independently. If there was a plugin system they could simply each
> write a plugin and the user could then combine the capabilities of
> both plugins without having to wait for someone to (maybe) integrate
> both into a unified patch.

Neither HDR-Image support nor Renderman like shaders could be 
implemented as 'plugins' in current official POV-Ray even if it had 
plugin support and even if POV-Ray was a Windows-only program.

And there are reasons why MegaPOV currently does not include the POVMan 
patch and exactly the same reasons would prevent a POVMan plugin (that 
would not be possible anyway - see above) from being available.

So the idea that a plugin system would allow you to use two arbitrary 
patches that have not yet been combined in an unofficial version 
together without getting your hands dirty is not realistic.

> * "The povray license doesn't allow this" *
>     I thought one of the effects of the complete code rewrite with pov
> 4.0 is supposed to be a possible change of license? I know we're not
> supposed to talk about pov 4.0, but if that is the case, it might
> become possible to write such a plugin system then (as an unofficial
> patch of course) without licensing issues.

Just to avoid wrong conclusions.  The idea that POV-Ray 4.0 will have a 
changed license does not mean it will have a do-whatever-you-want 
license.  And to make it possible for people to distribute platform 
specific binary-only extensions is not exactly a very good reason to 
change the license.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Jim Henderson wrote:
> That maybe that implementation was sub-optimal.  I personally think it's
> foolish to think that something can *never* be accomplished, if everyone
> thought that way, we wouldn't have technology to the state it's in now.

You totally miss  the point: The limits are not just technological, they 
have serious design and more important usability implications.  And unless 
the whole world suddenly moves to a single operating system and that 
operating system gets a compiler the average user can use without knowing 
_anything_, the technology you have does not matter.

> Well, that's your opinion.

No, it is a previously stated official opinion of the whole team.

> amount of discussion this has generated.  Personally, I find it a very
> interesting bit of cognitive dissonance to be closed-minded about
> something relating to what is for all intents and purposes an open-source
> project.

You are mistaken.  It is simply that the "solution" proposed here not only 
(as pointed out numerous times by others) has no real use, it is also simply 
the completely wrong way to go, and everybody except a small handful of 
people have recognised this.

That is also why nobody after the many other discussions about the same 
topic implemented it.  Eventually everybody will realise it, but sadly it 
tends to generate endless discussions as people who simply do not know what 
they are taking about discuss it.  As soon as those who want to learn look 
into the structure of a ray-tracer, they realise the same an are never read 
from again (at least about that topic).

So it is not about being "closed-minded", it is about having the same 
pointless discussions coming up every half year or so, and having a 50+ or 
post long thread about them.

	Thorsten

Post a reply to this message

Rafal 'Raf256' Maj wrote:
> All other modern renderers can be extended rapidly by own shaders, plugins, 
> and so on. Why There is no such thing for PovRAY? 

Because all POV-Ray developers have to spend countless hours to explain to 
some people over and over again rhat plug-ins are pointless.

	Thorsten

Post a reply to this message

Christoph Hormann schrieb:

>>>
>>>   Show me the C++ code which performs loading of dynamically linked
>>> libraries in any platform.
>> 
>> Not on any. The platform has to support dynamic loading. If POVRay also 
>> compiles on plain old DOS than this feature will not be possible. But on 
>> all others:
>
> None of the variants is standard C++.  And note you won't find any such 
> port to specific platforms in the POV-Ray core code - it is portable per 
> se because it complies with the standard and does not need to be ported.

That's OK for me. If the core of POVRay has to be implemented in pure 
standard C++ than this feature will not be possible.

> Also note the #ifdef LINUX is incorrenct because only some of the 
> various flavours of Linux support this.

Correct. As I mentioned the platform has to support dynamic loading. But 
I think thats the case for 99% of the systems POVRay is really running 
(not only compiling) on.

> This whole thread is - like its predecessors - completely pointless 
> because it lacks examples what such a feature can be useful for that 
> won't be better solved with a different technique.  I don't know any 
> (and don't come up with nonsense like 'controlling Excel from a POV-SDL 
> script').

As I wrote above I dont need this feature. It was only a technical question.

-- 

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

As you may have noticed, thanks to Christoph's post, I "get it" now. :-)

Seems to me that just stating it the way he did would clarify very quickly
what the issues are.  But that's still no reason to say "let's just not
talk about it" - most newsreaders do have the option to ignore threads
that are of little or no interest to the operator. :-)

Jim

Post a reply to this message

Darren New wrote:
>> This whole thread is - like its predecessors - completely pointless 
>> because it lacks examples what such a feature can be useful for that 
>> won't be better solved with a different technique.  
> 
> 
> I am curious how one would build a fractal surface in SDL. It would seem 
> to be tremendously inefficient. (By "fractal surface" I mean a surface 
> where you can specify control points and a dimensionality between 2 and 
> 3 and get an infinitely-detailed surface.) Sort of like
> http://home.san.rr.com/dnew/island.gif
> [...]

i am not in the mood for downloading an animated gif today but in 
general there are four common ways of modeling a fractal surface in POV-Ray:

- using the builtin julia_fractal object
- using a mesh
- using a heightfield
- using an isosurface

You did not explain what other method you want to implement with a plugin.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message