-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Hormann wrote:
| 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.
|
	All right so my example wasn't perfect. I suppose you won't like the
next either since both patches are available together in megapov now:
clothray and mechsim. There was  time when those two where completely
separate patches and couldn't be used together. Plugins would have
made that possible (and would have removed the requirement for someone
to spend time integrating the two together, so that person could have
spend his time working on new features/enhancements).

	Moreover, image formats could be implemented as plugins although not
with the solutions I suggested; and renderman-like surface shaders
could be implemented with what I said (just like any texture/pattern
could) so you could use both together, just by taking the HDRI patch
and the renderman plugin.

| 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.
|
	I didn't say it would have a "do-whatever-you-want license", nor did
I say that it should, nor that it would/should make it possible to
distribute binary-only extensions. The license could include a
provision stating that any code linked against the POV core should
follow certain restrictions like be open source and available for
free. This would allow more freedom than the current "patches-only"
model while keeping all pov-related code free.

		Jerome
- --
******************************
*      Jerome M. Berger      *
* mailto:jbe### [at] ifrancecom *
*  http://jeberger.free.fr/  *
******************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCDw7fqIYJdJhyixIRArX+AJ9Xd62qOa63hHGBocpREUCYvy074wCfVL91
b0Ox/F9L/XZmAVTgPhbmzqY=
=bcZJ
-----END PGP SIGNATURE-----

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news: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.

But you can't have an iterative user-defined function to define an isosurface,
right?  I believe that's the kind of thing Darren is talking about - being able
to create your own iterative functions and using those to create objects,
without having to resort to approximating them with meshes.

It's irrelevant to this situation to say that you can use builtin fractal
patterns with isosurfaces because that only includes the julia and madelbrot
sets.  These two fractals aren't appropriate for generating landscapes; you need
to be able to have user-defined iterative functions, and that's not currently
possible.

Lance.

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

Post a reply to this message

Lance Birch wrote:
> 
> It's irrelevant to this situation to say that you can use builtin fractal
> patterns with isosurfaces because that only includes the julia and madelbrot
> sets.  These two fractals aren't appropriate for generating landscapes; you need
> to be able to have user-defined iterative functions, and that's not currently
> possible.

Could you please enlighten me how i am able to create my isosurface 
landscape scenes then? And no - i don't use custom patches for this, all 
LOTW2 scenes for example render with plain MegaPOV 1.0/1.1.

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

>     All right so my example wasn't perfect. I suppose you won't like th
e
> next either since both patches are available together in megapov now:
> clothray and mechsim. There was  time when those two where completely
> separate patches and couldn't be used together. Plugins would have
> made that possible (and would have removed the requirement for someone
> to spend time integrating the two together, so that person could have
> spend his time working on new features/enhancements).

No, a clothray plugin for POV-Ray 3.1 would have had to be modified for 
3.5 just like the patch had to.  Same for mechsim.

The time spent 'integrating the two together' was exactly zero - except 
maybe a few shared keywords.

So if both patches were implemented with some theoretical plugin system 
(and i don't even want to try to imagine how this would have to look 
like for allowing the mechsim patch in the current form) they would not 
have been available to be used together a day earlier than they have 
been now.

To sum it up - your central argument seems to be a plugin system would 
offer the possibilities of patches without maintainance work in a 'write 

once - use forever' manner.  This is not the case.

And concerning Renderman-like shaders - i already explained that the 
POVMan patch would have not been possible to implement as a plugin.  But 

to have support for Renderman shaders in POV-Ray would of course be nice 

but this is not a plugin system (shaders are not dynamically linked 
external modules, they are possible to be implemented in a completely 
portable way).

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

Darren New <dne### [at] sanrrcom> wrote:
> Perhaps you should read more carefully the OP's post to see what he's 
> asking for. ;-)  That, after all, is what I was responding to.

  I was not replying to the original post.

  Even when an article is in the same thread as the original article, that
doesn't mean that each and every single article is answering the original
first article.
  I was talking about why plugins in general are simply not feasible
in POV-Ray. I thought that was pretty clear.

> (Unless, perhaps, POV-Ray was written in Java or C#

  Please don't swear. There may be children reading this.

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

Lance Birch wrote:
> 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.

No, not at all as nonsense is undisputed sticks in some people heads better 
than glue.

> Maybe people have new ideas that weren't thought of in previous discussions;

No, they have no, really <sigh>

	Thorsten

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:cun70p$3l5$1@chho.imagico.de...
> Lance Birch wrote:
> >
> > It's irrelevant to this situation to say that you can use builtin fractal
> > patterns with isosurfaces because that only includes the julia and madelbrot
> > sets.  These two fractals aren't appropriate for generating landscapes; you
need
> > to be able to have user-defined iterative functions, and that's not
currently
> > possible.
>
> Could you please enlighten me how i am able to create my isosurface
> landscape scenes then? And no - i don't use custom patches for this, all
> LOTW2 scenes for example render with plain MegaPOV 1.0/1.1.

To my knowledge none of them use fractal-based formulas, they are based on
patterns that aren't fractal in nature, or am I mistaken?

Lance.

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

Post a reply to this message

On 12 Feb 2005 01:56:59 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> > 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 
>
> All other modern renderers can be extended rapidly by own shaders, plugins, 
> and so on.

Could you name all those modern raytracers which are written in C++, support
lodable plugins compiled to machine code, exists in builds for Mac, Windows
nad *nixes and support all the possible CPU architectures where mentioned
OS-es are working? Best with similar set of features as in POV-Ray. There must
be many of them which draw the standard you refer here.

ABX

Post a reply to this message

On 12 Feb 2005 01:51:48 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> Now extent macro language. Would it be very hard to implement minimalistic 
> C-like language interpreter? Then, on some platforms such funcitons could 
> be compiled using gcc before rendering to speed it up (someone done this 
> patch already, AFAIK it was mostnly for isosurfaces on Linux?). On other 
> platforms - it would be interpreted.

... which is exactly functions which are compiled to machine code on some Macs
and compiled to virtual machine on other platform. Moreover examples you gave
already are "possible"

> #function Vector3 ShootRay(float x, float y) { 

see user-defined camera in MegaPOV which allow sending rays in any direction.

> #funcion Color Pigment1(float x, float y, float z) {

see images like
http://news.povray.org/povray.binaries.images/attachment/%3C39e71e97%40news.povray.org%3E/escher4.jpg
which are completly procedural

ABX

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ABX wrote:
| Could you name all those modern raytracers which are written in C++,
support
| lodable plugins compiled to machine code, exists in builds for Mac,
Windows
| nad *nixes and support all the possible CPU architectures where
mentioned
| OS-es are working? Best with similar set of features as in POV-Ray.
There must
| be many of them which draw the standard you refer here.
|
	Well, Pixie for one: http://www.cs.berkeley.edu/~okan/Pixie/pixie.htm

		Jerome
- --
******************************
*      Jerome M. Berger      *
* mailto:jbe### [at] ifrancecom *
*  http://jeberger.free.fr/  *
******************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCEOqiqIYJdJhyixIRAjNuAJ0VFE8AisAVYLZIaZ6KVSP7unjlYwCePGfm
sFD2TJp+glo6E1YFtjK1BjQ=
=N+d9
-----END PGP SIGNATURE-----

Post a reply to this message