ok it's possible to run external code before and/or after the rendering in
PovRay.

What if having a syntax to run it from inside the script like a macro

#declare Result=external_code_lua("Path/Name",Arguments)
#declare Result=external_code_python("Path/Name",Arguments)
#declare Result=external_code_php("Path/Name",Arguments)
#declare Result=external_code_perl("Path/Name",Arguments)
#declare Result=external_code_java("Path/Name",Arguments)
#declare Result=external_code_bin("Path/Name",Arguments) (using stdout as
return-value)

- to run an external code, then convert it's information into CSV
- calculate big amounts of values faster, like convert PCM(PackedMesh) back into
mech or mesh2
- making SDS externally and much faster (a thing, that can become _very_ slow in
PovRay)
- converting NURBS into Mesh or Patches
- having excess to hardware, not available from Pov-script
- making Pov-script interactive (like making a 80s-like adventure-game with
PovRay) (ok, for this PovRay would also need to have the option to run in an
infinite loop then, or you start PovRay with your script or .ini-file as
post-command from PovRay... I never tried this!)

Think of it: depending on the language using, you can make PovRay
object-orientated!

From my personal taste, I would like to use Lua. It's designed to be used inside
other programs, or scripts. It's object-orientated, fast, free, opencource (I
think its MIT-License) and small.

If it's to complicate to program this, still a "bin"-call would be cool enough
to make extreme nice things.

Best regards,
Holger

Post a reply to this message

Attachments:
Download 'rendering.jpg' (26 KB)

Preview of image 'rendering.jpg'

Am 18.04.2010 21:44, schrieb H. Karsten:
> ok it's possible to run external code before and/or after the rendering in
> PovRay.
>
> What if having a syntax to run it from inside the script like a macro
>
> #declare Result=external_code_lua("Path/Name",Arguments)
> #declare Result=external_code_python("Path/Name",Arguments)
> #declare Result=external_code_php("Path/Name",Arguments)
> #declare Result=external_code_perl("Path/Name",Arguments)
> #declare Result=external_code_java("Path/Name",Arguments)
> #declare Result=external_code_bin("Path/Name",Arguments) (using stdout as
> return-value)
...
> Think of it: depending on the language using, you can make PovRay
> object-orientated!
>
>  From my personal taste, I would like to use Lua. It's designed to be used inside
> other programs, or scripts. It's object-orientated, fast, free, opencource (I
> think its MIT-License) and small.

Would there still be a big benefit in that, presuming the POV-Ray 4 SDL 
itself would be object-oriented and as fast as Lua or some such in the 
first place (which I consider a prime goal for POV-Ray 4)?

Post a reply to this message

> Would there still be a big benefit in that, presuming the POV-Ray 4 SDL
> itself would be object-oriented and as fast as Lua or some such in the
> first place (which I consider a prime goal for POV-Ray 4)?

Having this as the primary priority is definitely cool.

Maybe, it's a good thing to compile PovCode before rendering.

But I still say: keep it tiny and fast _and_ open for everything.

So maybe the people don't need to rewrite there code, already exist in another
language. Or you need to have some functions for some special things, you would
never ever put into a scrip-language, designed for 3d-graphics.

You never know what happens ...

Post a reply to this message

Am 20.04.2010 00:09, schrieb H. Karsten:

> But I still say: keep it tiny and fast _and_ open for everything.

The problem with these design goals is that they tend to be mutually 
exclusive. Especially being open for /everything/ is bound to add 
considerable overhead.

Post a reply to this message

> The problem with these design goals is that they tend to be mutually
> exclusive. Especially being open for /everything/ is bound to add
> considerable overhead.

Well ok - but if you open it for /something/, you already can use the next level
to go deepen into the problem and it's solve.

Like using some opening (if necessary) from inside the next language (like
hardware access, assembler connection, or some interactive windows for the user)

So maybe a bin-connection from inside the code is enough. The coder can do some
additional connection from the executable by himself.

Post a reply to this message

Am 20.04.2010 20:41, schrieb H. Karsten:

> Well ok - but if you open it for /something/, you already can use the next level
> to go deepen into the problem and it's solve.
>
> Like using some opening (if necessary) from inside the next language (like
> hardware access, assembler connection, or some interactive windows for the user)

Uh-huh... I'm not quite sure what this has to do with rendering (except 
maybe for the "assembler connection")...

> So maybe a bin-connection from inside the code is enough. The coder can do some
> additional connection from the executable by himself.

Can't be too difficult, huh?

May I put you on the list of volunteer developers for POV-Ray 4? :-P

Post a reply to this message

You could try and write a parser that reads whatever language you want 
as input and outputs POV SDL to see how easy it is. I've personally 
written a Lua parser, and despite all the work I put into it there are 
still probably situations where it chokes and fails!



-- 
http://isometricland.com

Post a reply to this message

On 7/26/2010 11:37 AM, SharkD wrote:
> You could try and write a parser that reads whatever language you want
> as input and outputs POV SDL to see how easy it is. I've personally
> written a Lua parser, and despite all the work I put into it there are
> still probably situations where it chokes and fails!

Oops, I need to check the original post dates more carefully. This 
thread is pretty dead.


-- 
http://isometricland.com

Post a reply to this message