Greetings Unix users!

I'm soliciting input on what Unix users think are the most important
platform-specific changes that could be made to POV-Ray.  This is mostly
to help me figure out what my priorities should be.  Current possible
projects include:

- improved installation script for binary packages (minor adjustment
planned for 3.1 yet)
- binaries for a broader range of platforms (possible for 3.1 yet)
- http://unix.povray.org (possible for 3.1 yet)
- ./configure; make; make install (possible for 3.5)
- documentation in info format (possible for 3.5)
- GUI frontend (possible for 4.0)
- built-in editor for a GUI interface (possible for 4.0)
- better support for POV-Ray through existing widely-used editors
(possible for 4.0)
- framebuffer output (possible for 4.0)
- anything else you come up with

Some of these (GUI frontends, povmode for Emacs) are already provided by
third parties.  Is the status quo satisfactory, or should POV-Ray on
Unix have an official GUI frontend, an official emacs mode, etc. that is
packaged with everything else?  

Also, while you're at it, feel free to comment on things that aren't
platform-specific (scene description language, scripting language,
rendering, file formats, choice of programming languages, license, etc.)
and potentially platform-specific (threading, network rendering, etc.). 
Here I'm looking mostly for the general opinion of the Unix user base,
which I can then relay to the rest of the team.

Discuss.  Comment.  Vent.  I'll be reading and commenting from time to
time.

-Mark Gordon

Post a reply to this message

Mark Gordon wrote:

> Greetings Unix users!
>
> I'm soliciting input on what Unix users think are the most important
> platform-specific changes that could be made to POV-Ray.  This is mostly
> to help me figure out what my priorities should be.  Current possible
> projects include:
>
> - improved installation script for binary packages (minor adjustment
> planned for 3.1 yet)
> - binaries for a broader range of platforms (possible for 3.1 yet)
> - http://unix.povray.org (possible for 3.1 yet)
> - ./configure; make; make install (possible for 3.5)
> - documentation in info format (possible for 3.5)
> - GUI frontend (possible for 4.0)
> - built-in editor for a GUI interface (possible for 4.0)
> - better support for POV-Ray through existing widely-used editors
> (possible for 4.0)
> - framebuffer output (possible for 4.0)
> - anything else you come up with
>

**** ./configure; make; make install (possible for 3.5)

*** - better support for POV-Ray through existing widely-used editors
(possible for 4.0)

* - improved installation script for binary packages (minor adjustment
planned for 3.1 yet)

No - - built-in editor for a GUI interface (possible for 4.0)


--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Mark Gordon wrote:
> 
> Greetings Unix users!

yea verily !

Its strange that you posted this at 02:20 because I decided to download the source and
rebuild
Pov-Ray 3.1g again about an hour ago.  I haven't done that in many months, since May
anyways.

You probably know what I'm going to say.  Brace yourself.

A multi-threaded povray and a platform independant network rendering option.  The
network rendering
option, in my dream world, would turn rendering into a client server model where a
povray server
would manage the workload for a set of clients.  Some high TCP/UDP port service number
like 7890
could be used to communicate between clients and the server.  The image file could get
dumped on
some NFS mount or whatever, thats not important.  The network rendering feature could
utilize two
modes of workload distribution, balanced per image and balanced per frame.  What I
mean by that is
that a single image could be rendered by distributing the scanline tasks to the
clients OR for
animation you could have the frames distributed to the clients.  The possibility for
supporting
client dropout would be slick but not needed at first pass.  Essentially the server
could check the
operational status of the clients with a PINC ( Povray Intenet Network Check ) packet
that would
demand a response from the listening clients ( I'm thinking of a broadcast packet but
who knows )
and if one had dropped out then its job gets reassigned or put back in the work queue.

Just my dreaming ...

Dennis Clarke

http://www.interlog.com/~dclarke/povray/povray.html

Post a reply to this message

Mark Gordon wrote:
> 
> Greetings Unix users!
> 
> I'm soliciting input on what Unix users think are the most important
> platform-specific changes that could be made to POV-Ray.  This is mostly
> to help me figure out what my priorities should be.  Current possible
> projects include:
> 

./configure && make && make install

Cheers, PoD.

Post a reply to this message

Mark,

I wonder if the POV-Ray team has discussed GPLing the source and adopting
the development model used by Linux projects.  I think this would speed up
evolution/development and generally be good for the project.  The current
team, or a designated member thereof could still act in the capacity as
project maintainer(s) and have final say in what actually makes it into the
program.  If this model were used, for example, some of the nice patches
that have come along might be "official" already.

Warren Mann

Post a reply to this message

Dennis Clarke <dcl### [at] interlogcom> wrote:
: animation you could have the frames distributed to the clients.

  This, of course, would be great, but it may cause problems when frames
depend on the result of previous frames by file-io.
  (Well, then you just don't render separated frames in separated threads...)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I'll probably be the only one who thinks so, but I would definitately enjoy
having the built in editor. At least have it available in the POV source,
like a configureable option, i.e. ./configure --enable-gui. I know there are
plenty of 3rd party ones out there, but I've tried most of them, and, no
insult to anyone who worked on them, I don't like them. I'm very used to the
Win version, and enjoy having the source and most of the INI options just a
keystroke away (yes, I know the command line works just fine, but I always
end up with one thing out of place. As for the Emacs mode, well, I haven't
quite figured out Emacs yet. Just my half a pence,
Krystian
www.geocities.com/kgbates

Post a reply to this message

configure make install


Marc

-- 
Marc Schimmler

Post a reply to this message

Hello Mark,

here are my wishes:

Mark Gordon <mtg### [at] mailbagcom> writes:

> - ./configure; make; make install (possible for 3.5)

would be great. Particularly, if it makes it easy to use the installed
png and z lib.

> - better support for POV-Ray through existing widely-used editors
> (possible for 4.0)

If (when) good packages exist for editors, it would be nice to include them
in the official distribution.

The same is true for macro and include files. Lense flares, trees and the
like should be part of the official distribution. My guess is that their
authors would be glad to contribute their work in most cases.

A thing that I would really like to see is a CVS server with the current
development state.

Thomas

-- 
http://thomas.willhalm.de/ (including pgp key)

Post a reply to this message

Multithreading multithreading multithreading. There's some work on it now,
true, but you need to run some strange virtual machine to do so and thats
just icky. As it is, I have a shell script that will distribute the top and
bottom halves to seprate instances of Pov, but man, that eats up the RAM.
And then I have to GIMP 'em back together.

Had I the talent, I'd do it myself instead of piss & moan to somebody
else...

DirkBoy

Post a reply to this message