Hi All:

   At last, after some 8 months, I'm nearly finished with my
lightmap-baking demo/tutorial. The technique I developed works great
within the limitations of lightmapping, but I've a problem deciding
which scripting language to use for a little external tool that is
necessary to write some files.

   I tried at first to use only POV-Ray for that, but there was a little
obstacle which forced me to use some external programming: I need to
read the geometry file exported by Poseray, to find the objects and
materials names... so I cannot use POV-Ray file I/O.

   As I'm used to write and read text files with PHP, I just wrote a
little script for use with PHP_CLI from the command line. It works
great for me, but perhaps it isn't a great choice for multiplatform
distribution... The problem is I cannot find anything better, as I will
prefer to distribute just a configurable text file.

   Any recommendations? (or perhaps I overlooked a way to do it only with
POV-Ray?)

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
> Any recommendations? (or perhaps I overlooked a way to do it only with
> POV-Ray?)

Something you can write in a portable scripting language that you can wrap 
up as a stand-alone executable for various common platforms is probably 
best. I use Tcl for that, personally.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
> > Any recommendations? (or perhaps I overlooked a way to do it only with
> > POV-Ray?)
>
> Something you can write in a portable scripting language that you can wrap
> up as a stand-alone executable for various common platforms is probably
> best. I use Tcl for that, personally.

it's a good choice, yes.  And even Tcl is a more sane language than PHP, aside
from the spaghetti-code like nature of being able to eval local variables in
"upper" environments... lol

Post a reply to this message

On 4/13/2011 19:42, nemesis wrote:
> eval local variables in
> "upper" environments... lol

If you do that for writing anything except your own flow control statements, 
you deserve what you get.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

El 14/04/11 04:21, Darren New escribió:
> On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
>> Any recommendations? (or perhaps I overlooked a way to do it only
>> with POV-Ray?)
>
> Something you can write in a portable scripting language that you can
>  wrap up as a stand-alone executable for various common platforms is
>  probably best. I use Tcl for that, personally.

   Perhaps I didn't emphasize it enough, but I really hoped not to have
to distribute an executable... the script is very simplistic right now:
it just defines some configuration variables at the top, and uses them
to read a POV-Ray include file, extract objects and material names, and
write some resulting files.

   So, at the moment, the "user" needs to edit the script before using it
on his own scenes. The ideal situation would be to write this tool with
POV-Ray SDL, so I could be sure any POV-Ray user will have the means to
use it, but I think this is not possible.

   Being that lazy, I didn't want to implement proper command-line
arguments or input dialogs, as the whole thing it's just a "proof of
concept" demo. But I would like others to test it, so I guess I will
have to...


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> El 14/04/11 04:21, Darren New escribió:
> > On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
> >> Any recommendations? (or perhaps I overlooked a way to do it only
> >> with POV-Ray?)
> >
> > Something you can write in a portable scripting language that you can
> >  wrap up as a stand-alone executable for various common platforms is
> >  probably best. I use Tcl for that, personally.

>    Perhaps I didn't emphasize it enough, but I really hoped not to have
> to distribute an executable... the script is very simplistic right now:
> it just defines some configuration variables at the top, and uses them
> to read a POV-Ray include file, extract objects and material names, and
> write some resulting files.

  Perhaps you could write several versions of the script for the scripting
languages that are most "native" to each of the three major operating
systems. IIRC there's some scripting language that Windows supports
out-of-the-box, and on the linux side you have plenty to choose from
(one to consider, if possible, is using shell scripting, if its features
are enough, as that's the most ubiquitous in unix/linux). On the Mac you
could look at AppleScript, which is supported natively (or if the shell
scripting works, it should work there as well, although Mac users are not
very accustomed to using the command line).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> > El 14/04/11 04:21, Darren New escribió:
> > > On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
> > >> Any recommendations? (or perhaps I overlooked a way to do it only
> > >> with POV-Ray?)
> > >
> > > Something you can write in a portable scripting language that you can
> > >  wrap up as a stand-alone executable for various common platforms is
> > >  probably best. I use Tcl for that, personally.
>
> >    Perhaps I didn't emphasize it enough, but I really hoped not to have
> > to distribute an executable... the script is very simplistic right now:
> > it just defines some configuration variables at the top, and uses them
> > to read a POV-Ray include file, extract objects and material names, and
> > write some resulting files.
>
>   Perhaps you could write several versions of the script for the scripting
> languages that are most "native" to each of the three major operating
> systems. IIRC there's some scripting language that Windows supports
> out-of-the-box, and on the linux side you have plenty to choose from
> (one to consider, if possible, is using shell scripting, if its features
> are enough, as that's the most ubiquitous in unix/linux). On the Mac you
> could look at AppleScript, which is supported natively (or if the shell
> scripting works, it should work there as well, although Mac users are not
> very accustomed to using the command line).
>
> --
>                                                           - Warp

I fail to see the advantage of going bonkers providing multiple versions of the
same script to support multiple "native" scrpting environments when there are
multiple far better offerings than the native stuff that are both a fast and
free download and also multiplatform.

Jaime, being able to wrap your script in an executable together with the
interpreter is a bonus.  Tcl is just like any other scripting language and you
can just distribute the script and a link to where to obtain the interpreter.

I prefer python as a language, but Tcl is a good choice too.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> I fail to see the advantage of going bonkers providing multiple versions of the
> same script to support multiple "native" scrpting environments when there are
> multiple far better offerings than the native stuff that are both a fast and
> free download and also multiplatform.

  You fail to see the advantage? How about you take the script and just
run it, without having to figure out what else you need to download and
install before you can run it. The less steps one needs to run the script,
the better.

-- 
                                                          - Warp

Post a reply to this message

Am 14.04.2011 00:38, schrieb Jaime Vives Piqueres:

> At last, after some 8 months, I'm nearly finished with my
> lightmap-baking demo/tutorial. The technique I developed works great
> within the limitations of lightmapping, but I've a problem deciding
> which scripting language to use for a little external tool that is
> necessary to write some files.

Any popular general-purpose scripting language will probably do: I guess 
Perl, Python and Ruby all come with interpreters for most any platform 
you might name.

I know none of these, so like Darren I'd personally go for Tcl; as 
already mentioned, you don't need to use Tk (the most popular GUI 
toolkit for Tcl), but I find it a nice-to-have. I know of free 
interpreters for both Linux and Windows, and I guess there's something 
for the Mac available as well.

One thing that should be noted is that not all people accept all 
scripting languages equally well, and some may refuse to install 
interpreters for whatever language you choose. I, for instance, would 
hesitate to install a PHP interpreter on my machine, but would be ok 
with Perl, Python or Ruby (and, as you probably guess, have Tcl 
installed already); I must confess this is an only marginally 
rationalized preference, but I may not be alone with such a preference.

Interestingly enough, I don't recall ever hearing anyone take a 
categoric stance against Tcl, so it might raise the fewest resentments.

That said, when it comes to writing platform-independent scripts with 
the intention to distribute them, I think the most commonly used 
language for such a purpose might be Perl.

In case you should decide to split up the script into a kind of config 
file and the actual code, Java would probably be the way to go.

Post a reply to this message

On 4/14/2011 6:56, Warp wrote:
> nemesis<nam### [at] gmailcom>  wrote:
>> I fail to see the advantage of going bonkers providing multiple versions of the
>> same script to support multiple "native" scrpting environments when there are
>> multiple far better offerings than the native stuff that are both a fast and
>> free download and also multiplatform.
>
>    You fail to see the advantage? How about you take the script and just
> run it, without having to figure out what else you need to download and
> install before you can run it. The less steps one needs to run the script,
> the better.

Well, as nemesis says, my intention was to suggest a simple cross-platform 
scripting language (like Tcl or Python) for the script, *plus* do the 
up-front work of wrapping it in a native no-install executable for each of 
the major platforms if you care to promote usage. Distribute both the short 
script and the "use this if you don't want to install the scripting 
environment" version.

My MakeDF3 code[*] is like that.  It's a Tcl script that I run through 
freewrap, so you have MakeDF3.tcl if you want to edit it or you already have 
Tcl installed, or MakeDF3.exe if you're on Windows and you just want to use 
the tool and don't mind that it takes up another meg of disk space.

If you're just writing files and not using a whole bunch of utility 
libraries, writing it in C and asking someone to compile it for each 
platform for you can also work well. Once you start linking in things like 
Windows or Linux packages, that becomes less feasible.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/14/2011 8:16, clipka wrote:
> I know none of these, so like Darren I'd personally go for Tcl;

I only mentioned Tcl because on Windows at least it's trivial to wrap up the 
Tcl code into a no-install stand-alone .exe.  I don't know how OSX handles 
what Linux calls repositories, but installing the Tcl interpreter on modern 
Linux is pretty straightforward. (Pretty straightforward on Windows once you 
track it down, too, but that's an extra step people might not want to go for 
if they just want to try your code once.)

Does OSX have something like Yum to which people submit that stuff, or is it 
more like Windows where you have to track down where the software is?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Does OSX have something like Yum to which people submit that stuff, or is it 
> more like Windows where you have to track down where the software is?

  AFAIK there's no official repository/package manager, but there's a
third-party system that does exactly that: http://www.macports.org/

  It works in the same way as the command-line versions of linux package
managers.

-- 
                                                          - Warp

Post a reply to this message

On 4/14/2011 9:09, Warp wrote:
>    AFAIK there's no official repository/package manager, but there's a
> third-party system that does exactly that: http://www.macports.org/

Oh, I've heard of that. I've seen books about XYZ that say something about 
getting the XYZ interpreter from macports, for example.

Cool, thanks for the info!

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> I fail to see the advantage of going bonkers providing multiple versions of the
>> same script to support multiple "native" scrpting environments when there are
>> multiple far better offerings than the native stuff that are both a fast and
>> free download and also multiplatform.
> 
>   You fail to see the advantage? How about you take the script and just
> run it, without having to figure out what else you need to download and
> install before you can run it.

how about clicking on a link right next to the script download instead 
of "figuring it out"?

BTW, I wonder when will OS'es finally automatically download and install 
required interpreters based on file type.  You click on a script and if 
there's no interpreter, the OS informs you of the file type and required 
interpreter and if you want it to fetch, install and then execute the 
script.  Security risk?  Not like you don't have to provide an 
administrative password to install things...

I mean, it's not like python and company are completely unfamiliar to 
desktop OSes.  They've been around for so long, how come there's no 
standardized database of known scripting languages and it's file types...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On 4/14/2011 10:13, nemesis wrote:
> BTW, I wonder when will OS'es finally automatically download and install
> required interpreters based on file type.

When the people distributing the commercial OS can get an *official* version 
of an interpreter and want to support it. Windows already does this, but it 
almost always comes up with "I don't know which interpreter you want", 
because if people get Ruby from Windows, they'll expect MS to support it.

It's basically the problem with closed-source commercial software - you 
don't want to take on responsibilities you're not paid for (like supporting 
arbitrary interpreters you don't own) and you can't support them anyway if 
they're closed source.

 > You click on a script and if
> there's no interpreter, the OS informs you of the file type and required
> interpreter and if you want it to fetch, install and then execute the
> script. Security risk? Not like you don't have to provide an administrative
> password to install things...

Try this. Pick an extension for an interpreter you don't have installed 
under Windows. (Like, create a xyz.rb file.) Click on it. Watch the magic of 
exactly what you're asking for.

> I mean, it's not like python and company are completely unfamiliar to
> desktop OSes. They've been around for so long, how come there's no
> standardized database of known scripting languages and it's file types...

Because nobody paid Microsoft to add Python to the list?

Heck, linux people laugh at having a central registry to map file extensions 
to mime types. Java programs have all kinds of problems running with the 
wrong JVM. With that sort of attitude, you think they'll make a global list 
of the definitive versions of an interpreter?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/14/2011 10:13, nemesis wrote:
> BTW, I wonder when will OS'es finally automatically download and install
> required interpreters based on file type.

Actually, Windows does.  Create "xxx.pl" as a file, assuming you don't have 
Perl installed. Click on it. It brings up a web page that says "Hey, this 
looks like a Perl file. Do you want to go download the Perl development 
environment?"

I wonder how much MS charges for being listed, that so many interpreters are 
*not* listed there.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New escreveu:
> On 4/14/2011 10:13, nemesis wrote:
>> BTW, I wonder when will OS'es finally automatically download and install
>> required interpreters based on file type.
> 
> Try this. Pick an extension for an interpreter you don't have installed 
> under Windows. (Like, create a xyz.rb file.) Click on it. Watch the 
> magic of exactly what you're asking for.

then I guess problem already solved for 90% of people out there, let 
alone technical people wanting to export and render a scene with povray.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

El 14/04/11 15:56, Warp escribió:
> ... without having to figure out what else you need to download and
> install before you can run it.

   Yes, that was my original concern, but I'm not very inclined to learn
JScript and Applescript, to not talk about unix shell script... :)

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

El 14/04/11 17:57, Darren New escribió:
> Well, as nemesis says, my intention was to suggest a simple
> cross-platform scripting language (like Tcl or Python) for the
> script, *plus* do the up-front work of wrapping it in a native
> no-install executable for each of the major platforms if you care to
>  promote usage. Distribute both the short script and the "use this if
>  you don't want to install the scripting environment" version.

   My problem with the executable option was that my script needed
editing in *all cases*, for every scene.

   But now that the apparent "simple" option of distributing a script
showed to be too complex, I've decided to do a more proper
application... nothing fancy, just a little dialog window with a few
input controls and a big button.

   But most likely I will use Java, as it seems to fill all my
requirements and expectations... and also because a close friend is
willing to help me learning to use Netbeans.

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

El 14/04/11 19:13, nemesis escribió:
> BTW, I wonder when will OS'es finally automatically download and
> install required interpreters based on file type.

  What I wonder is why doesn't exists a standard scripting language
available on all platforms by default...


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

On 4/14/2011 14:22, Jaime Vives Piqueres wrote:
> My problem with the executable option was that my script needed
> editing in *all cases*, for every scene.

You *could* prompt every time you run the script? Or take a file name on the 
command line to indicate what the parameters are? Or the name of an ini file 
to read from? Depending on how many there are?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

El 14/04/11 17:16, clipka escribió:
> One thing that should be noted is that not all people accept all
> scripting languages equally well, and some may refuse to install
> interpreters for whatever language you choose. I, for instance,
> would hesitate to install a PHP interpreter on my machine, but would
> be ok with Perl, Python or Ruby (and, as you probably guess, have Tcl
>  installed already); I must confess this is an only marginally
> rationalized preference, but I may not be alone with such a
> preference.
>

   That was exactly my fear about distributing just my handy PHP 
script... ;)

> That said, when it comes to writing platform-independent scripts
> with the intention to distribute them, I think the most commonly used
>  language for such a purpose might be Perl.

   Yes, it seems so, but I've already decided in favor of the last of
your options:

> In case you should decide to split up the script into a kind of
> config file and the actual code, Java would probably be the way to
> go.

   Not for that reason, but I finally decided to write it in Java using
Netbeans. I can just distribute a single jar (plus the source code for
the curious), and seems easy enough as to have it finished by tomorrow.

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

El 14/04/11 23:29, Darren New escribió:
> On 4/14/2011 14:22, Jaime Vives Piqueres wrote:
>> My problem with the executable option was that my script needed
>> editing in *all cases*, for every scene.
>
> You *could* prompt every time you run the script? Or take a file name
> on the command line to indicate what the parameters are? Or the name
> of an ini file to read from? Depending on how many there are?
>

   Yes, of course all these were possible... I just wanted to avoid the
extra work of implementing any of them. So I was originally looking for
an interpreted language for which I could just distribute the editable
script. But by now I've already realized that I cannot be that lazy...
in the end, it's just a few text fields, some dropdowns and a button.

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Jaime Vives Piqueres escreveu:
> El 14/04/11 19:13, nemesis escribió:
>> BTW, I wonder when will OS'es finally automatically download and
>> install required interpreters based on file type.
> 
>  What I wonder is why doesn't exists a standard scripting language
> available on all platforms by default...

oh it does!  It's called javascript. ;)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message