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

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

Christoph Hormann wrote:
| 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.
|
	Uh? I never said that they wouldn't need to be adapted when changing
versions of povray if the plugin interface changed.

| The time spent 'integrating the two together' was exactly zero - except
| maybe a few shared keywords.
|
	So why did it take over 6 month between the time they became
available as independant patches and the time they were both merged
into the "official" megapov?

| 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)
	Well, of course they would have had to be written as plugins in the
first place. I'm not saying that they *should* be reimplemented as
plugins if those ever became available but that if they *could* have
been, we would have gained in flexibility.

| they would not
| have been available to be used together a day earlier than they have
| been now.
|
	Sure they would. It would have been possible to use them together
immediately after release by their respective authors. There's nothing
preventing the use of several plugins at the same time!

| 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.
|
	Not *without* maintenance, but with less maintenance and most of it
done by the people writing the functionnality rather than requiring
the work of an integrator to put everything together.

| And concerning Renderman-like shaders - i already explained that the
| POVMan patch would have not been possible to implement as a plugin.
	No, you have stated that it wouldn't. Since I don't know how POVMan
itself is implemented I can't say how easy (or possible) it would be
to change it into a plugin, but the *functionnality* it provides could
be implemented as a plugin as long as the plugin system supported
texture plugins.

| 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,
	I never said they were. But the interpreter that runs the shaders
could be implemented as a "dynamically linked external module".

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

iD8DBQFCEO+wqIYJdJhyixIRAuWhAJsFvjlZsoYsOytE22PcVZbYnMzgIQCfZb12
/Q8AvPX79750aTglx8wNxKM=
=B1iZ
-----END PGP SIGNATURE-----

Post a reply to this message

On Mon, 14 Feb 2005 19:14:58 +0100, "Jérôme M. Berger" <jbe### [at] ifrancecom>
wrote:
>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

I don't think that (quoting Pixie sources which you probably refer here) in
simple #if #else:

    #ifdef WIN32
	// Win32 stuff here
	cModule	=	LoadLibrary(name);
    #else
	// Unix stuff here
	cModule =	dlopen(name,RTLD_NOW);

all the platforms are handled. Even in wxWidgets where we wrap C++ around native
APIs (http://www.wxwidgets.org/manuals/2.5.3/wx_wxdynamiclibrary.html), we have
5 different representations of wxDllType and still do not cover all the possible
cases:

  // Note: WXPM/EMX has to be tested first, since we want to use
  // native version, even if configure detected presence of DLOPEN.
  #if defined(__WXPM__) || defined(__EMX__) || defined(__WINDOWS__)
    typedef HMODULE             wxDllType;
  #elif defined(HAVE_DLOPEN)
    #include <dlfcn.h>
    typedef void               *wxDllType;
  #elif defined(HAVE_SHL_LOAD)
    #include <dl.h>
    typedef shl_t               wxDllType;
  #elif defined(__DARWIN__)
    typedef void               *wxDllType;
  #elif defined(__WXMAC__)
    #include <CodeFragments.h>
    typedef CFragConnectionID   wxDllType;
  #else
    #error "Dynamic Loading classes can't be compiled on this platform, sorry."
  #endif

ABX

Post a reply to this message

Darren New wrote:
> Altho Tcl does a very nice job (via the "stubs" interface) of avoiding 
> having to recompile extensions when new versions of Tcl come out. And 
> yes, all kinds of Tcl internals are exposed thereby, not just simple 
> one-interface things. Worth looking at, for anyone who is wanting to 
> implement a plug-in interface to anything other than POV-Ray, where such 
> would be impossible and foolish to even consider. ;-)

Oh please, could you stop spreading this nonsense around?  Also that is what 
  was contained in 90% of your posts so far, I have tried to resist replying 
to your Tcl "example" long enough now:  Tcl is at best byte-compiled (like 
Java) and then either interpreted or just-in-time compiled, which has 
exactly nothing to do with shared libraries (aka DLLs) and plug-ins based 
those, which is the topic discussed in this thread.

	Thorsten

Post a reply to this message

Darren New wrote:
>> what  was contained in 90% of your posts so far, I have tried to 
>> resist replying to your Tcl "example" long enough now:  Tcl is at best 
>> byte-compiled (like Java) and then either interpreted or just-in-time 
>> compiled,
> 
> Correct.  So?

That is *not* the topic of this discussion!  Yet you bring up Tcl over and 
over again.  Yet, as we are not discussing Tcl, you should not be bringing 
up Tcl.

Maybe simpler words will do: Tcl is not the same thing as a plug-in for 
POV-Ray, it cannot be used to write plug-ins for POV-Ray and it also 
provides nothing to implement plug-ins for POV-Ray.  So, while you may love 
Tcl, pointing that out repeatedly is of no use for the topic being discussed.

> Right. That's why I'm talking about the stubs interface to dynamically 
> loaded .DLL compiled code in Tcl. The fact that Tcl's interpreted has 
> nothing to do with the stubs interface or the fact that it loads DLLs 
> that are compiled machine code.

Which is not a plug-in, thus has nothing to do with the topic being 
discussed, and as such, also you have made clear now that your favorite 
language is Tcl, it is of no use to POV-Ray and cannot be used to implement 
POV-Ray plug-ins. As such, mentioning Tcl if of no use for the topic being 
discussed.

> In other words, while you're right that "Tcl is at best byte-compiled", 
> you're also right that that fact has nothing to do with shared libraries 
> and plug-ins based on those.

Exactly, and we are not discussing Tcl here.  As such, that you keep 
claiming Tcl would provide a solution to make shared-libary plug-ins for 
POV-Ray is based no no facts, it is just your imagination.  We are not 
discussing what is possible in your imagination. We already know from past 
discussions it is in conflict with the reality the rest of the world is 
living in.

	Thorsten

Post a reply to this message

Darren New wrote:
> But then I realized, maybe what you meant to be saying by calling 
> something "nonsense" is "it doesn't make sense to me."  In other words, 
> normally when someone calls something "nonsense", they're actually 
> saying "it's so factually incorrect that it's not even internally 
> consistent."

Actually, I am using it as adjective to describe the content of your posts. 
I suppose you could look up the meaning of it on the website you quoted. 
However, I doubt you will understand it.

	Thorsten

Post a reply to this message

tho### [at] trfde news:420e0903$1@news.povray.org

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

Yes, only stupid / small companies/programs use them, like OpenGL shaders 
(highlevel C-like syntax or lowlevel assembly), NVidia, 3dSMax plugins, 
bryce plugins, LightWorks shaders, even DirectShow Filters.

Indeed, lets stop adding any interesting new rewolutionary futures, since 
Pov-RAY already left all other renderers far-behind.

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

Rafal 'Raf256' Maj wrote:
> Yes, only stupid / small companies/programs use them, like OpenGL shaders 
> (highlevel C-like syntax or lowlevel assembly), NVidia, 3dSMax plugins, 
> bryce plugins, LightWorks shaders, even DirectShow Filters.
> 
> Indeed, lets stop adding any interesting new rewolutionary futures, since 
> Pov-RAY already left all other renderers far-behind.

Other than spreading misinformation or having fun bashing POV-Ray developers 
in our public forum, what is the purpose of your post again?  Contribute 
something or finally learn when to remain silent, please.

	Thorsten

Post a reply to this message