I want to do some disturbingly twisted things with Povray, involving
procedural generation. The built in scripting isn't powerful/fast
enough, so I'm going to have to modify Povray to add a custom function.

Rather than path Povray directly, I'd prefer to instead add code to
allow me to load native functions out of an external DLL. That way I
don't have to modify Povray itself as I work.

The actual code to do this seems fairly straightforward, but it would
save loads of time if someone had already done this. Has someone?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_

Post a reply to this message

On 28/09/2015 02:10, David Given wrote:
> Rather than path Povray directly, I'd prefer to instead add code to
> allow me to load native functions out of an external DLL. That way I
> don't have to modify Povray itself as I work.
> 
> The actual code to do this seems fairly straightforward, but it would
> save loads of time if someone had already done this. Has someone?

Doing it *portably* is not as straightforward as you may hope. I don't
know what platform you're using so I can't say what is likely to be
out there, but I don't recall coming across a generic solution yet.

If you just want to do it for yourself on a single platform, then you
could probably do so easily enough (but then you could just as well
compile the functions directly in).

That aside, it's one thing to load a native function from an external
DLL but another thing entirely to hook it into the rendering chain in
a coherent manner: there would need to be some sort of specification
(either in script, or built into the DLL) that defines how/where each
entry point within it gets hooked in. This isn't an issue for code you
insert directly into the source, of course.

-- Chris

Post a reply to this message

Am 27.09.2015 um 18:25 schrieb Chris Cason:

> That aside, it's one thing to load a native function from an external
> DLL but another thing entirely to hook it into the rendering chain in
> a coherent manner: there would need to be some sort of specification
> (either in script, or built into the DLL) that defines how/where each
> entry point within it gets hooked in. This isn't an issue for code you
> insert directly into the source, of course.

Given that I've abstracted away most all of the function VM out of the
core by now, it might be comparatively easy. Presuming the OP starts
with the most recent source code of course, and knows how to link in
DLLs at run-time.

Post a reply to this message

On 27/09/15 18:25, Chris Cason wrote:
[...]
> That aside, it's one thing to load a native function from an external
> DLL but another thing entirely to hook it into the rendering chain in
> a coherent manner: there would need to be some sort of specification
> (either in script, or built into the DLL) that defines how/where each
> entry point within it gets hooked in. This isn't an issue for code you
> insert directly into the source, of course.

Yes, this is the tricky bit. Looking at the Povray VM I see that scalar
functions and vector functions go through different pathways. It looks
like my easiest option is to add an OPCODE_DLL which behaves like a
vector function trap and takes the pointer to the native function in the
FunctionCode's private_data. Then add the code in
parser_functions_utilities.cpp to compile it.

This way I could do:

#declare fnord = function { dll("libfnord.so", "fnord") }

...to declare an external function.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_

Post a reply to this message

On 27/09/15 20:35, clipka wrote:
[...]
> Given that I've abstracted away most all of the function VM out of the
> core by now, it might be comparatively easy. Presuming the OP starts
> with the most recent source code of course, and knows how to link in
> DLLs at run-time.

Actually, I've done it. It wasn't even a lot of code.

https://github.com/POV-Ray/povray/compare/master...davidgiven:dlopen

It's all a shoddy prototype, of course. I couldn't figure out the
function calling conventions, so this is just a straight copy of the
vector function code, which means it's limited to three parameters. The
povray_vector_fn type probably wants to be a bit smarter, but a copy is
necessary anyway because the plugin can't tell what type DBL is. The DLL
lookup path needs to be filtered, otherwise a Povray script can run any
code in any DLL on the system. But it does show that it's plausible.

Example (for Linux):

test.pov:
---snip---
#include "colors.inc"

background { color Cyan }

camera {
  location <0, 2, -3>
  look_at <0, 1, 2>
}

#declare isofunction = function { dll("libfnord.so", "isofunction") }

isosurface {
  function { isofunction(x, y, z).x }
  max_gradient 3
  contained_by {
  	sphere { <0, 0, 0>, 2 }
  }
  texture {
    pigment { color Yellow }
  }
  translate <0, 1, 2>
}

light_source { <2, 4, -3> color White}
---snip---

libfnord.c:
---snip---
#include <stdlib.h>
#include <math.h>
#include "include/povray_plugin.h"

void isofunction(double data[])
{
	double x = data[0];
	double y = data[1];
	double z = data[2];
	data[0] = pow(x, 2) + pow(y, 2) + pow(z, 2) -
		(sin(x*10.0)*0.05) - pow(1, 2);
}
---snip---

To use:

$ gcc -Os -shared -fpic -fPIC libfnord.c -o libfnord.so
$ povray +Itest.pov

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_

Post a reply to this message

On 9/27/2015 9:25 AM, Chris Cason wrote:
> On 28/09/2015 02:10, David Given wrote:
>> Rather than path Povray directly, I'd prefer to instead add code to
>> allow me to load native functions out of an external DLL. That way I
>> don't have to modify Povray itself as I work.
>>
>> The actual code to do this seems fairly straightforward, but it would
>> save loads of time if someone had already done this. Has someone?
>
> Doing it *portably* is not as straightforward as you may hope. I don't
> know what platform you're using so I can't say what is likely to be
> out there, but I don't recall coming across a generic solution yet.
>
> If you just want to do it for yourself on a single platform, then you
> could probably do so easily enough (but then you could just as well
> compile the functions directly in).
>
> That aside, it's one thing to load a native function from an external
> DLL but another thing entirely to hook it into the rendering chain in
> a coherent manner: there would need to be some sort of specification
> (either in script, or built into the DLL) that defines how/where each
> entry point within it gets hooked in. This isn't an issue for code you
> insert directly into the source, of course.
>
> -- Chris
>
Well, one way around portability is, instead of trying to compile a dll, 
you just tack on something like Lua, as a extensible language for the 
core VM. Yeah, this might not be "efficient" speed wise, but.. you don't 
end up in the new version of DLL hell with it either (where there is 
this neat library someone wrote, for the freekie deekie OS, only FD uses 
zipidedooda libraries, which don't work anything like those for Fedora, 
and even less like the ones in Windows, and all they give you is a 
source, not even a compiled DLL, and no make file (never mind, zod 
forbid, one that isn't 5 years old, to convert to your compiler's 
syntax, for which specifications have changed 14 times since then...)

Man that sort of thing just royally frosts me. I don't know half the 
languages the things are written in well enough to figure out what they 
F they are "supposed to do", never mind the make file syntax well enough 
to figure out what the F its doing wrong, when trying to convert 
(assuming, again, it even has one). Maybe everyone else never has this 
problem? lol

Not that POV's developers would ever do this. But, we are not talking 
about "its" developers any more, when you start cramming someone else's 
extensions onto it. Somehow.. it just seems more sensible to me, in such 
cases, to have a language that is comprehensible, and isn't going to 
refer to strange stuff that doesn't exist on the machine I need to 
re-compile/install it for. ;)

-- 
Commander Vimes: "You take a bunch of people who don't seem any 
different from you and me, but when you add them all together you get 
this sort of huge raving maniac with national borders and an anthem."

Post a reply to this message