 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rick [Kitty5] wrote:
> Christopher James Huff wrote:
>
>>Bloated, the resulting files would be huge,
>
>
> But thats not the point, The ability to get scenes onto other platforms is,
> and XML (no matter how bloated the files may be) is ideal.
No, if there was an existing file format widely supported for this
purpose that uses xml that would be a valid argument, if not xml would
probably be a guarantee that hardly any program will add an import
function for such a format when introduced by POV.
If you don't believe this give me a counterexample: an xml file format
introduced by a free program that got accepted by commercial
applications as an universal data exchange format.
If you are referring to xml being 'easily' translatable into arbitrary
other formats - just write a converter for the most common proprietary
formats. If such a converter existed it would surely be acceptable to
deal with GB sized xml files as in-between format but i don't see a
chance of this happening.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tyler Eaves wrote:
> This is a list of things I'd like to see in a future version
> of POV-Ray. While none of these are massive changes, they are
> all capabilites that I would find useful. Some of these are much
> more 'pie in the sky' than others.
Tweaks and fiddles are fine. The ONLY feature I would like to see is multi
threading with TCP/IP
I want to be able to render at 16200x10200 (and above) for print work and
not compromise on the features I use in my images. I don't use povray for
such work as it simply isn't practical.
I fully appreciate that multi threaded applications can be difficult to
write and thats without the special issues with some of povray's features.
But, it makes the difference between povray being a hobbyists toy and a
professional rendering engine.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rick [Kitty5] wrote:
>
> I want to be able to render at 16200x10200 (and above) for print work and
> not compromise on the features I use in my images. I don't use povray for
> such work as it simply isn't practical.
You can render such an image with POV-Ray without problems, if you are
referring to distributed renders try:
http://pvmpov.sourceforge.net/
http://www.tu-bs.de/%7Ey0013390/povany/index.html
> I fully appreciate that multi threaded applications can be difficult to
> write and thats without the special issues with some of povray's features.
>
> But, it makes the difference between povray being a hobbyists toy and a
> professional rendering engine.
I (and probably most others here) would appreciate if you'd not come up
with such conclusions before understanding why POV-Ray is not multithreaded.
Also note that multithreading will not help you to distribute a render
on several computers. Using several processors on one machine is one
thing - distributing a render on several computers in another.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> You can render such an image with POV-Ray without problems, if you are
> referring to distributed renders try:
>
> http://pvmpov.sourceforge.net/
http://sf.net/tracker/index.php?func=detail&aid=461989&group_id=35688&atid=415075
> http://www.tu-bs.de/%7Ey0013390/povany/index.html
Is filesystem based, Same reason SMPOV is useless to me.
I have no shortage of machines to set up as slaves, I just don't have them
all on me :)
> I (and probably most others here) would appreciate if you'd not come up
> with such conclusions before understanding why POV-Ray is not
> multithreaded.
I am well aware of the reasons (and resistance) for povray's lack of
threading, I am just making the point that for professional print work,
despite the quality of the output, POV is not a suitable tool.
It simply takes far to long to render on a single CPU, and the current
options for distributing a render fall short of the mark.
> Also note that multithreading will not help you to distribute a render
> on several computers. Using several processors on one machine is one
> thing - distributing a render on several computers in another.
Once you have the capability to scale, how you scale is a trivial matter.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rick [Kitty5] wrote:
>
>>http://www.tu-bs.de/%7Ey0013390/povany/index.html
>
>
> Is filesystem based,
It is not, RTFM.
>>I (and probably most others here) would appreciate if you'd not come up
>>with such conclusions before understanding why POV-Ray is not
>>multithreaded.
>
>
> I am well aware of the reasons (and resistance) for povray's lack of
> threading, I am just making the point that for professional print work,
> despite the quality of the output, POV is not a suitable tool.
With this reply you again show you either have no idea of the reasons or
you simply don't like the reasons and therefore decide to ignore them.
POV-Ray is an open program - if you are not happy with the way it works
you have two options: change the way it works (which of course requires
to understand the problem in the first place) or stop using it. What
you do instead is mostly unqualified mourning - when you state something
like "for professional print work, ... , POV is not a suitable tool" or
"I don't use povray for such work as it simply isn't practical" you
should back this with some actual reproducible facts or refrain from
stating it at all.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> wrote in news:c3pfol$4rp$1
@chho.imagico.de:
> Rick [Kitty5] wrote:
>>
>>>http://www.tu-bs.de/%7Ey0013390/povany/index.html
>>
>>
>> Is filesystem based,
>
> It is not, RTFM.
>
I read:
"Right now the exchange of data between the different computers
rendering a scene works via the file system. This allows distributed
renders on any group of computers that have access to a common
directory via SMB, NFS, etc. It is well possible to extend this with
exchange via ftp, email or any other network protocol by writing
additional scripts."
and came to the same conclusion as Rick. I am not looking to start a
fight, but I am genuinely interested in what I seem to be missing.
--
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Galvin wrote:
>>>
>>>Is filesystem based,
>>
>>It is not, RTFM.
>>
>
>
> I read:
>
> "Right now the exchange of data between the different computers
> rendering a scene works via the file system. This allows distributed
> renders on any group of computers that have access to a common
> directory via SMB, NFS, etc. It is well possible to extend this with
> exchange via ftp, email or any other network protocol by writing
> additional scripts."
>
That's completely right - but as the text says this distributed
rendering framework is not limited to file system based communication.
It is quite straight away to extend it to any other transport - the
system is designed to make this relatively easy. I am pretty sure
though that using the file system is the most convenient way for most
people (for using email to exchange data for example it would be
extremely necessary to implement a signing/encryption system which would
be more difficult to set up).
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <406004bf@news.povray.org>,
"Rick [Kitty5]" <ric### [at] kitty5com> wrote:
> Christopher James Huff wrote:
> > Bloated, the resulting files would be huge,
>
> But thats not the point, The ability to get scenes onto other platforms is,
> and XML (no matter how bloated the files may be) is ideal.
No it's not. Bloat means more to transfer over the network, and it has
no advantages over sending binary information.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> POV-Ray is an open program - if you are not happy with the way it works
> you have two options: change the way it works (which of course requires
> to understand the problem in the first place) or stop using it.
Fistly, providing the source does not make a program open.
I stopped using POV for large print work a long time ago for the reasons you
seem to be missing.
> you do instead is mostly unqualified mourning - when you state something
> like "for professional print work, ... , POV is not a suitable tool" or
> "I don't use povray for such work as it simply isn't practical" you
> should back this with some actual reproducible facts or refrain from
> stating it at all.
Say for example, I wanted to render an image that makes heavy use of
radioasity and print it as a 54"x34" poster at 300dpi
I would have to render the image at 16200x10200
Now, on the fastest single CPU I have, said image takes a day to render at
1024x768
How long would it take to render the poster size image (that is more than 10
times bigger) ?
Far to long, especially if you concider that its easy to make an image that
takes longer than a day to render at desktop resolutions.
And all this assumes that I will only have to render said poster sized image
once, how do I keep a client who wants to see a series of proofs and make
changes - tell them it could take months because povray doesn't scale!
"POV is not a suitable tool" and "simply isn't practical" are very clearly
valid statements.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> No it's not. Bloat means more to transfer over the network, and it has
> no advantages over sending binary information.
Bloat also compresses well.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
