 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A DOS version of 3.0 POV-Ray (unofficial) called POV-Pro, so no 3.1
capablities.
It's a render-speed-increased-compile. Just lacks a lot of the
"official" look. From what I remember from using it some myself, it can
be much faster. Believe the author stated "up to 40 or 50%" faster. But
I recall 25% (or is it 125%, percentages always confuse me) being the
average.
My URL to it seems to be broken now though, browser errors if attempt is
made to use it.
You could email me and ask for POV-Pro, put that in the subject line,
I'll send it over, I seem to have misplaced the original archive of it
though. All I found here is the povpro.exe itself (714K), no readme,
nothing.
It's basically a plain old DOS POV-Ray though. Works in the same way, no
editor, help, nothing though. Use the official version for that.
Kyle wrote:
>
> Hi everyone. I'm using an old 486/100mhz to do raytracing, and when
> rendering a scene at 640x400 with antialiasing depth 2 the fastest I
> can seem to get it to go is 18 pps. (I'm using the WIN95 version) I
> have all other programs shut down. Render priority on highest, GUI
> priority on lowest, and the render window closed....are there any more
> ways to speed up render time? Besides the obvious "turn down AA" or
> "buy a new computer you cheapo". Any suggestions?
> Kyle
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.htm
=Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 7 set the virtual memory to "own settings" - Min=40Mb(more if you think you'll
need it)-
> -Max=300 (depends on free space)-
Actually, I've been told that setting your swap file to twice your
memory (unless you have 16 megs, then 3 times) with Min = 2 x Memory and
Max 2 x Memory. This creates a permanent swap file which works faster,
and should be large enough.
Steve
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbell net> wrote:
: Don't use refection in your finish statement.
: Don't use any objects that require csg operations.
: Don't use any high order polynominal objects.
: Don't use filter or transmit in your pigments.
: Don't use media or fog.
: Don't use while loops.
: Don't have more than a couple of objects in your scene.
: Don't use specular or phong highlights.
: Don't use high diffuse values.
: Don't use layered testures and pigments.
: Don't use area lights.
: Don't have radiosity turned on.
Don't use povray?
Btw, I am still using a 486 66MHz. Some of you may know my images. They
are all made with that computer (except a few, when I render
the final image on a pentium at the school...)
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Spider <spi### [at] bahnhofse> wrote:
: The more so, use union instead of merge where possible, it's faster
This isn't always true.
If you have several semi-transparent objects, usually merging them is
faster than unioning them (probably because povray has to do fewer lighting
calculations because there are fewer surfaces). Of course the resulting
object from merging semi-transparent objects is completely different from
a union of them.
: Difference is slowwwww...
This isn't always true either.
I just tested: Three unioned spheres took 46 seconds to render (at 640x480),
and the same spheres differenced took only 37 seconds.
The size of the visible surface plays a very important role in the
rendering time, obviously because the shading calculations are rather slow.
The fewer the surfaces and the smaller (on screen), the faster.
:> Don't use media or fog.
: Absolutely not...
Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
very nice results.
:> Don't have radiosity turned on.
: Never...
I wouldn't say "never".
: 4 reboot to DOS
: 5 reboot to windows
: 8 reboot
: 10 reboot.
"Windows has detected movement of the mouse. Please reboot the computer
for the changes to take effect."
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, but this is up to everyone on his own...
I don't intend to have 128 Mb swap because I have 64 Mb ram and some programs tell me
I
must have a swap file.... (I've used them....)
//Spider
Stephen Lavedas wrote:
>
> > 7 set the virtual memory to "own settings" - Min=40Mb(more if you think
you'll need it)-
> > -Max=300 (depends on free space)-
> Actually, I've been told that setting your swap file to twice your
> memory (unless you have 16 megs, then 3 times) with Min = 2 x Memory and
> Max 2 x Memory. This creates a permanent swap file which works faster,
> and should be large enough.
>
> Steve
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Mika wrote:
>
> Spider <spi### [at] bahnhofse> wrote:
> : The more so, use union instead of merge where possible, it's faster
>
> This isn't always true.
> If you have several semi-transparent objects, usually merging them is
> faster than unioning them (probably because povray has to do fewer lighting
> calculations because there are fewer surfaces). Of course the resulting
> object from merging semi-transparent objects is completely different from
> a union of them.
Ok, you got me. Everything depends and nothing is true... ehh.. did I just Lie ??
> : Difference is slowwwww...
>
> This isn't always true either.
> I just tested: Three unioned spheres took 46 seconds to render (at 640x480),
> and the same spheres differenced took only 37 seconds.
> The size of the visible surface plays a very important role in the
> rendering time, obviously because the shading calculations are rather slow.
> The fewer the surfaces and the smaller (on screen), the faster.
Hmm, most of my expereince with difference come from multiple objects, a difference of
a
text from a union... but then, text is generally pretty slow... IMHO
>
> :> Don't use media or fog.
> : Absolutely not...
>
> Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
> very nice results.
Yes, but then.... it is slow...
>
> :> Don't have radiosity turned on.
> : Never...
>
> I wouldn't say "never".
Hmm, Well, not until you have patience to wait...
>
> : 4 reboot to DOS
> : 5 reboot to windows
> : 8 reboot
> : 10 reboot.
>
> "Windows has detected movement of the mouse. Please reboot the computer
> for the changes to take effect."
Keyboard not present, press any key to continue.
//Spider
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey I'll add one for the VFAQ perhaps. Intersection can be really slow
if you are using two really large objects to make a smaller one. Manual
bounding is a good idea in this case to let POV know you just want to
check the smaller area where the visible object is.
-Mike
Nieminen Mika wrote:
>
> Spider <spi### [at] bahnhofse> wrote:
> : The more so, use union instead of merge where possible, it's faster
>
> This isn't always true.
> If you have several semi-transparent objects, usually merging them is
> faster than unioning them (probably because povray has to do fewer lighting
> calculations because there are fewer surfaces). Of course the resulting
> object from merging semi-transparent objects is completely different from
> a union of them.
>
> : Difference is slowwwww...
>
> This isn't always true either.
> I just tested: Three unioned spheres took 46 seconds to render (at 640x480),
> and the same spheres differenced took only 37 seconds.
> The size of the visible surface plays a very important role in the
> rendering time, obviously because the shading calculations are rather slow.
> The fewer the surfaces and the smaller (on screen), the faster.
>
> :> Don't use media or fog.
> : Absolutely not...
>
> Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
> very nice results.
>
> :> Don't have radiosity turned on.
> : Never...
>
> I wouldn't say "never".
>
> : 4 reboot to DOS
> : 5 reboot to windows
> : 8 reboot
> : 10 reboot.
>
> "Windows has detected movement of the mouse. Please reboot the computer
> for the changes to take effect."
>
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Jan 1999 03:58:23 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>Spider <spi### [at] bahnhofse> wrote:
>: Difference is slowwwww...
>
> This isn't always true either.
And even when it is true, it's no slower than intersection or merge.
In fact, difference and merge may both be expressed in terms of
intersections, and within the program differences are indeed expressed
as intersections.
For the curious:
difference {object {A} object {B}}
is equivalent to
intersection {object {A} object {B inverse}}
and
merge {object {A} object {B}}
is equivalent to
intersection {object {A inverse} object {B inverse} inverse}
(An aside: would making this substitution in the parser simplify the
CSG evaluation code sufficiently to gain any significant performance
on rendering? I doubt it. Currently, in fact, the intersection
version renders just a tiny bit slower than the merge version for the
same scene. I don't know why that is.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Spider <spi### [at] bahnhofse> wrote:
:> :> Don't use media or fog.
:> : Absolutely not...
:>
:> Fog isn't so cpu-hog. AFAIK fog is rather fast to calculate but achieves
:> very nice results.
: Yes, but then.... it is slow...
AFAIK, fog is about as slow as, for example, a phong finish calculation.
ie. rather fast.
A fog made with media IS slow.
:> :> Don't have radiosity turned on.
:> : Never...
:>
:> I wouldn't say "never".
: Hmm, Well, not until you have patience to wait...
Perhaps you have seen my radiosity test images on my page? They are all
calculated with my good old 486 66MHz.
Of course it requires a bit of patience.
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike <Ama### [at] aolcom> wrote:
: Hey I'll add one for the VFAQ perhaps. Intersection can be really slow
: if you are using two really large objects to make a smaller one. Manual
: bounding is a good idea in this case to let POV know you just want to
: check the smaller area where the visible object is.
Can you post a (very short) example code showing clearly this speedup
when bounding a difference by hand? I'll put it on the page if it's good.
Preferably with fast objects like spheres.
--
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
