|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Warp
Subject: Re: Calling external Math functions from .dll or .so
Date: 12 Feb 2005 19:56:48
Message: <420ea5d0@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Warp
Subject: Re: Calling external Math functions from .dll or .so
Date: 12 Feb 2005 20:05:36
Message: <420ea7e0@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Warp
Subject: Re: Calling external Math functions from .dll or .so
Date: 12 Feb 2005 20:12:00
Message: <420ea960@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Calling external Math functions from .dll or .so
Date: 12 Feb 2005 22:16:05
Message: <420ec675$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Tim Cook
Subject: Re: Calling external Math functions from .dll or .so
Date: 12 Feb 2005 23:38:31
Message: <420ed9c7$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Lance Birch
Subject: Re: Calling external Math functions from .dll or .so
Date: 13 Feb 2005 01:03:42
Message: <420eedbe$1@news.povray.org>
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Calling external Math functions from .dll or .so
Date: 13 Feb 2005 02:40:02
Message: <cun081$2cb$1@chho.imagico.de>
|
|
|
| |
| |
|
|
Darren New wrote:
>
> This, by the way, is the kind of fractal I'm talking about:
>
> http://www.fractal-landscapes.co.uk/images.html
Oh come on - all those images use very crude meshes, admittingly quite
efficiently hidden by detailed textures. So all this from the point of
geometry is really easy to make with POV-Ray, even with pre-3.5 versions
and it would not be inefficient and no plugin system would make this
better in any way. But in addition POV-Ray offers much more advanced
techniques for landscapes that beat these images by far in terms of
geometric resolution, like:
http://www.tu-bs.de/~y0013390/pov/pict/hole1.jpg
http://www.tu-bs.de/~y0013390/pov/pict/eroded.jpg
Again you won't gain anything by the possibility of using 'plugins'
(which like mentioned elsewhere is an extremely vague and undefined
concept) - plugins would need to be written just like SDL macros,
patches and external programs.
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
|
|
| |
| |
|
|
From: Lance Birch
Subject: Re: Calling external Math functions from .dll or .so
Date: 13 Feb 2005 02:46:36
Message: <420f05dc$1@news.povray.org>
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:cun081$2cb$1@chho.imagico.de...
> Darren New wrote:
> >
> > This, by the way, is the kind of fractal I'm talking about:
> >
> > http://www.fractal-landscapes.co.uk/images.html
>
> Oh come on - all those images use very crude meshes, admittingly quite
> efficiently hidden by detailed textures. So all this from the point of
I don't want to sound like I'm speaking on Darren's behalf, but I think Darren's
entire point was that you should be able to do it without having to resort to
using meshes, but because the function needed to be iterative, it wasn't
possible with isosurfaces.
That was my interpretation anyway.
Lance.
thezone - thezone.firewave.com.au
thehandle - www.thehandle.com
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: Calling external Math functions from .dll or .so
Date: 13 Feb 2005 03:20:02
Message: <cun2hh$2qb$1@chho.imagico.de>
|
|
|
| |
| |
|
|
Lance Birch wrote:
>>>
>>>http://www.fractal-landscapes.co.uk/images.html
>
> I don't want to sound like I'm speaking on Darren's behalf, but I think Darren's
> entire point was that you should be able to do it without having to resort to
> using meshes, but because the function needed to be iterative, it wasn't
> possible with isosurfaces.
And my point was that landscapes like on the URL above are entirely
possibe to do in much higher quality in POV-Ray using existing means and
without meshes and a plugin system would not improve this in any way.
And also classical fractals can be rendered as isosurfaces using
POV-Ray's builtin fractal patterns.
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
|
|
| |
| |
|
|
|
|
| |
|
|