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

In article <420ddedc@news.povray.org>, war### [at] tagpovrayorg says...

> > - - It won't remove the need for patches (New rendering features
> > couldn't go through such a mechanism, nor could existing rendering
> > features be extended easily), but it could provide some useful
> > modelling and texturing functionnalities.
> 
>   I think this is the most important realization of yours, and exactly
> my point.
> 
>   The only features you site in that paragraph as possible with plugins
> is something which will most probably be possible, in a much easier way,
> with the new scripting language of POV-Ray 4. It will probably be
> possible to do more with the scripting language than what you could
> do with a plugin feature like you described.
>   It shouldn't be necessary to list once again the advantages of having
> a "plugin" written in POV-Ray's own native scripting language as opposed
> to having a C++ patch (or C++ plugin).

Hmm.. On that thought... Such a system would be a bit like the plugin 
system for Mushclient. At one point it was realized that there where 
three *big* issues with having all your code in one file, even if you 
also used script functions to load some sort of .inc type file. The first 
issue is a non-issue with POV. Since multiple script languages where in 
use, the possibility existed that shared code would not work, since it 
would be in the wrong language. This obviously isn't a problem with POV-
Ray. The second issue was sharing things. If you wanted a plugin to keep 
track of potions, you could export a bunch of aliases, triggers, etc., 
shop out the needed code, hope you didn't miss anything and then have the 
user patch all of them into their client. By making a plugin system, all 
those things could be exported to a file with its own script, triggers, 
etc. The third issue was collisions. Situations where the script might 
contain the same variables or the same/similar aliases, triggers and such 
existed in more than one. By keeping them separate, even when in the same 
language as the 'master' script, there was no major issues with this. Oh, 
and it also allowed some plugins to be declared as 'global' to all 
worlds.

Seems to me that something like that in POV-Ray could kill the same two 
birds with one stone, allowing a 'plugin' to have its own functions and 
the like that won't collide with existing ones *and* make it possible to 
declare commonly used ones as 'global', so they are automatically 
available, without adding code to include them for every single scene 
that uses them. This also eliminates the issue of cross platform 
compatibility, since the 'plugins' are native SDL, just importer either 
as an object-like extension to a specific scene or as a global 'library'. 
The only real difference from the existing model would be how the engine 
'sees' certain types of includes. As a library, it would provide both the 
global option and automatic collision prevention. The only difference in 
the SDL itself might be a single directive, like <library "Blah">, which 
makes it treat the code in 'that' file as an object itself, called 
'Blah', instead of just imbedding it into the SDL as part of the global 
script. Any objects, variables, etc. would be accessed with Blah.Object, 
instead of just the name if referenced from the main SDL(s). Normal .inc 
files would still work as normal with no changes.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> or POV-Ray is too 
> complicated to figure out how to fit plug-ins into it.

  No, I didn't say that.

  I said that there's such a huge amount of little features in POV-Ray
that trying to support replacing/enhancing them through dll plugins is
just not feasible. I didn't say anything about figuring out how to
fit the plugins into it.

> All of *those* 
> arguments are bogus, and I think what I've been seeing here is people 
> shooting down the arguments in *this* paragraph, and not the 
> non-technical reasons above. :-)

  Yet you have still failed to give a description of which features
in the POV-Ray code should call a function implementable in a dll
plugin and what would that plugin do.
  You are still talking as if plugins were some magical code which
could be inserted anywhere and replace anything in the POV-Ray binary.
They simply don't work like that: You have to explicitly code in the
core the plugin calls, and that's my question: Where should POV-Ray
call the plugin and which features should be reimplementable with
the plugin?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> First, is it expected that POV-Ray 4.0 will be mostly upward compatible 
> in the SDL with 3.x? That is, are all the macros on povray.org right now 
> going to need to be written completely, or just tweaked?

  What kind of backwards-compatibility will pov4 support is to be seen,
but you should be aware that the current SDL is just not good. It's a
hack over a hack over a hack, which very limited and also extremely
slow (and very difficult to optimize faster). While the new scripting
language should (IMO) resemble somewhat the current SDL, it would not
be quite wise to drag support for the current SDL, except perhaps in
a kind of import mode.

> Secondly, if the people doing POV-Ray 4.0 are the same people who have 
> been working on the 3.x release, what reason is there to believe that 
> this'll make it possible to change the license if it isn't possible now? 

  3.x contains code made by people 10 years ago which cannot be reached
anymore. Their code cannot be published under a license they didn't
agree to.
  POV-Ray 4 will be completely rewritten by the current developers
which can agree to a new license.

> IANAL, but I'm pretty sure that in the USA at least, POV-Ray 4.0 would 
> be considered a derivative work of POV-Ray 3.x, particularly if it's 
> done by the same people.

  If a code is rewritten and looks completely different, it doesn't
matter if it does the same thing as the old code. The new code will
be copyrighted by the new programmer.

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

Darren New <dne### [at] sanrrcom> wrote:
> No. I am familiar enough with how programs are written in C to know that 
> somewhere in the code there's a string that says "function" and that's 
> matched against the input to figure out that you're doing something like
>    #declare abc = function(x) {...}

  So you are talking about different functions than I am. Perhaps you
should read more carefully my replies in order to understand what I'm
talking about.

  If you are referring to the user-defined functions in the SDL (which
is a completely different thing than what I was talking about), then
why implementing a system-dependant plugin system would be better than
creating a better scripting language which can be used to do the same
things and more (for example, imagine that you would like to take
an object as parameter and trace it, or whatever).

> Not at all. All it would add is a new calculation. If you wanted 
> something like bozo or bumps or crackle, but a different pattern (say, a 
> fractal surface calculation of some sort), you could code it in C. 
> Myself, I write code that outputs a PPM map when I want to put a fractal 
> heightfield in my images.

> >   A patch is exactly that: You merge it to the existing code, recompile
> > and presto, we have a completely new feature.

> Thanks for that precise summary. ;-)  <Warp> Where would you merge it 
> in? What functionality would it supply? How would you invoke the 
> feature? </Warp> ;-)

  Sorry, I didn't understand.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Darren New wrote:
> I'd already suggested basing it on an existing scripting language, but I 
> got shot down without understanding what the actual objection was.

That you should not participate in discussions whose topic you don't 
understand.  This isn't Computer Science 101.

> I don't imagine anyone who wrote code 10 years ago cares, but if they 
> *did* want to sue, I'm pretty sure they could at least make a case that 
> POV 4.0 would be a derivative work of theirs if everyone working on 4.0 
> also helped develop 3.x, named it the same name, etc etc etc.

Please, spare us your amateur legal FUD.

	Thorsten

Post a reply to this message

Darren New wrote:
> Thorsten Froehlich wrote:
>> Please, spare us your amateur legal FUD.
> You know, there's a *heck* of a lot of STFU for an on-topic discussion 
> here.

That's Thorsten for ya ;)

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:420d12db$1@news.povray.org...
> Maurice wrote:
> > <cynic mode>
> > Sorry for interrupting your little flame war here. But I just wanted to
> > say that I really love to see people who only see problems and refuse to
> > see solutions.
> > ;-)
> > </cynic mode>
>
> No, it is a matter of experience.  Would you go to your local car mechanic
> and ask him to attach wings to your car?  You don't (I hope) because you
> know that would not give you a flying car and in general be useless.  Of
> course there is a solution even to getting a car to fly, but how feasible is
it?
>
> Either way, the real point here is that this whole discussion is *pointless*
> and I would really wish people would just for once not argue over something
> they so obviously do not understand.  After having had the same discussion
> for the 10th time in five years, it is only annoying, nothing else.

You aren't obligated to respond, Thorsten, you aren't even obligated to read the
posts.  If you are tired of the conversation you can just mark it as read and
ignore it.

Maybe people have new ideas that weren't thought of in previous discussions;
maybe people want to implement their own system and would like to discuss it
with other users; maybe there are users on the server now that would like to
contribute to such a discussion without having to dig up an old thread that
might have out of date information; maybe if you don't have anything
constructive to contribute you shouldn't bother saying anything at all.

These groups are for discussion about POV-Ray and getting help from other users,
so I don't see why anyone should be saying 'don't discuss this topic, it's been
discussed before' - that just turns off enthusiastic new users with big ideas,
and those are the sorts of users I really like to see posting.  I always think
it's best to let people discuss things anyway, even if you think they're
impossible and pointless, because sometimes great things come from such
discussions (e.g. the Daylon Graphics Patches for POV-Ray, that allow basic
OpenGL previewing).

Lance.

thezone - thezone.firewave.com.au
thehandle - www.thehandle.com

Post a reply to this message