 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Just out of curiosity, is there a plan for a beta of a Linux build?
>
> Kinda itching to get my hands on it to start playing with it (particularly
> interested in MP support). :-)
builds for other platforms will most likely wait until the core code settles
down. the changes necessary to get POV to the state where we can support SMP
properly (we didn't want to do a hack) are massive, as will become clear when
the source code is released. apart from the internal re-structuring needed
for threading we have both logically and physically separated the front and
back ends (frontend being the UI, backend being the renderer), which has
changed the way that the platform-specific code integrates. As this work is
not yet complete, it's probably better that we get it all done to avoid
duplication of effort before other platforms follow.
sorry that's not much of an answer but it's the best I can give right now :-(
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kinda what I expected, really - and if it were me making the decision, I
probably would do the same thing....Still, I had to ask. :-)
Thanks, and look forward to seeing it on Linux. I'm quite interested to
see how long it takes to render the "Blueblob" post from p.b.i on a DP
system at the settings I've used - right now, it's around 160 hours or so
and about 33% done...
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Thanks, and look forward to seeing it on Linux. I'm quite interested to
> see how long it takes to render the "Blueblob" post from p.b.i on a DP
> system at the settings I've used - right now, it's around 160 hours or so
> and about 33% done...
That's what happens when you use AA depth 9 =)
I hope that's method 1 and not 2.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 04 May 2005 13:28:47 -0400, Slime wrote:
>> Thanks, and look forward to seeing it on Linux. I'm quite interested to
>> see how long it takes to render the "Blueblob" post from p.b.i on a DP
>> system at the settings I've used - right now, it's around 160 hours or
>> so and about 33% done...
>
> That's what happens when you use AA depth 9 =)
>
> I hope that's method 1 and not 2.
It's method 2, actually - mostly a curiousity thing than anything -
machine with one processor sitting idle most of the time - it's weird
having a render run at niceness -20 and still being able to play
armagetronad with the first-person view/highest quality/highest
resolution/all reflections turned on. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's method 2, actually
Do you know that method 2 with depth 9 is a possible 263,169 samples per
pixel? =)
Of course, often you'll get much fewer than that... but even so, I doubt
you'd ever notice a difference between depth 3 and 4, let alone 9.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.general Slime <fak### [at] email address> wrote:
> Do you know that method 2 with depth 9 is a possible 263,169 samples per
> pixel? =)
> Of course, often you'll get much fewer than that... but even so, I doubt
> you'd ever notice a difference between depth 3 and 4, let alone 9.
According to my experience method 2 gives higher quality results at
bigger threshold values than method 1.
Using a very high number of samples is reasonable only if there are
*tons* of subpixel-sized details. This is usually rare.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> According to my experience method 2 gives higher quality results at
> bigger threshold values than method 1.
> Using a very high number of samples is reasonable only if there are
> *tons* of subpixel-sized details. This is usually rare.
Infinite checkered plane has infinitely small squares.
But they cover such a *tiny* area of the surface...
Similar situation with (say) reflections on a cylindrical shape. Lots of
small details; you definitely need good AA for it to look right. But I
don't think I have *ever* been above depth 4...
It would, of course, be trivial to do a back to back compare to see the
results...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 04 May 2005 16:18:59 -0400, Slime wrote:
>> It's method 2, actually
>
> Do you know that method 2 with depth 9 is a possible 263,169 samples per
> pixel? =)
Actually, I didn't know that. :-)
> Of course, often you'll get much fewer than that... but even so, I doubt
> you'd ever notice a difference between depth 3 and 4, let alone 9.
Possibly - I may do one that's a depth 3/4 (heck, that'd give the other
processor something to do) to compare the results. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4278cb12@news.povray.org>, nospam-
new### [at] deletethispovrayorg says...
> Jim Henderson wrote:
> > Just out of curiosity, is there a plan for a beta of a Linux build?
> >
> > Kinda itching to get my hands on it to start playing with it (particularly
> > interested in MP support). :-)
>
> builds for other platforms will most likely wait until the core code settles
> down. the changes necessary to get POV to the state where we can support SMP
> properly (we didn't want to do a hack) are massive, as will become clear when
> the source code is released. apart from the internal re-structuring needed
> for threading we have both logically and physically separated the front and
> back ends (frontend being the UI, backend being the renderer), which has
> changed the way that the platform-specific code integrates. As this work is
> not yet complete, it's probably better that we get it all done to avoid
> duplication of effort before other platforms follow.
>
Would this imply that it may then become possible to use a more simple
front end or even create one as a module that could one Windows be an
ActiveX control or a Python app on Linux, etc? In other words, strip off
the existing front end and make one that can be tied into another
application, as long as appropriate information is provided to state that
the backend is in fact POVRay when its first loaded? I mean the plugin
system that is available and programs like Moray use is nice, but I felt
it always did leave a bit to be desired in some cases.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
>
> Would this imply that it may then become possible to use a more simple
> front end or even create one as a module that could one Windows be an
> ActiveX control or a Python app on Linux, etc? In other words, strip off
> the existing front end and make one that can be tied into another
> application, as long as appropriate information is provided to state that
> the backend is in fact POVRay when its first loaded? I mean the plugin
> system that is available and programs like Moray use is nice, but I felt
> it always did leave a bit to be desired in some cases.
First of all a dynamically linked frontend and a stripped-down backend
would violate the spirit and the letter of the current license - this
has been explaind in depth in the past including the lack of possibility
to simply change the license.
Apart from that what you wrote does not mention what you think would be
possible by dynamically linking the POV-Ray backend with a different app
that is not possible to do via stdin and stdout of the official version.
Note i am not saying such things don't exist but you have not
mentioned any. One thing i could think of is the possibility to pause
and resume a render (without stopping it) but this would be quite simple
to add by having POV-Ray interpret pause and resume commands from stdin.
BTW i just announced a program in tools.general that demonstrates how
you can integrate POV-Ray into another program using these means.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 03 May. 2005 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
