Slashdot Mirror

Shouldn't it be possible to limit a process' duty cycle somehow? Some applications like POV-Ray offered this as an application switch (vital for rendering in space! ;)) but I could think of a similar limit imposed from the outside. SIGSTOP and SIGCONT have existed for the longest time and maybe today there's better options specifically on Linux.

I've tested version 13 of ICC using Povray on several of my AMD and Intel systems. I can tell you that the dispatch code works as you would expect: AVX (but not AVX2) code path does work on the FX8350, does not work on Phenom II x6 1090T so switched to SSE2 path. Of course, compiling without dispatch will cause seg faults on processors that don't support AVX or AVX2. But that doesn't necessarily mean ICC is the fastest compiler for AMD. For Povray at least that would be GCC.

Depends on program actually and what version of ICC. What you're describing was old ICC behavior before they were sued. My own tests compiling Povray with ICC 13 I've found that the ICC dispatch code does work properly on my FX 8350. In other words, compile with AVX dispatch support and the program will choose the AVX code path, which gives the same performance as compiling with only AVX support (the dispatched program also runs on my PhenomII 1090T, but the AVX exclusive program doesn't). But that doesn't necessarily mean the ICC code is always faster. Sometimes GCC code is faster because GCC can explicitly order instructions for Bulldozer, but it doesn't do autodispatch. That has to be coded separatley by the programmer.

Could you be a little more specific about the kind of software this is about?
That might reveal why people shy away from the project.

Tangentially, you manage to bring up a very good point. One huge problem is the software projects might be using. A number of companies open sourced their software before the notion of a 'standardized' license method became prevalent. If a project is not Mozilla, GPL, or BSD compatible then it will have a very hard time attracting new developers. I know would not want to work on something that did not have a useful open source license. I would encourage the submitter to make sure whatever he is working on have a standard, permissive as possible license (if possible) before he closes shop.

I know one interesting project (from a historical perspective) that suffers from this is the Open Watcom compiler with its non-compatible Sybase Public License. This project fits the submitter's description to a tee. I bet there are others like this. At least POV-Ray got around to fixing their license finally.

It might sound a little bizarre, but there are some users who demand that "exact reproduction of results of a previous run from the previous version" as an acceptance test of the new version. Even if the vendor proves the old run was buggy, and the old "gold standard" results are bad, they want exact rerun including the bugs.

There is nothing bizarre about this: sometimes output is best stored in the form of input (for example, see Pov-Ray) and repeatability trumps aesthetics.

perhaps you should explain what POV-Ray actually is?

Yeah, because google doesn't exist... Or would you like me to explain what a search engine and the internet are?

Here's a famous poster rendered with POV-Ray from space (the ISS).

Oh, I forgot you might not be a nerd for which this news is for. Perhaps you want me to explain what the ISS is?

Well, you see a when an aerospace engineer loves another celestial body very much they-- Fuck off, Lamer!

It's a way of making CGI (computer graphics) that actually look real. The engine calculates your light sources and then sends virtual light-rays from them to bounce of the objects in your scene and return them to the camera (the screen) The end result can be, if done right, photo-realistic. Also, the entire screen is by its very nature truly 3D. You can reposition the camera and move around the scene at will.
Here's a pretty old one: http://hof.povray.org/images/warm_up_Big.jpg

Someday... maybe a long way off... there will be Raytracing game engines. Current CPU tech is a bit slow for them. But when they do arise, games will truly look real.

The old license was open source but had restrictions on commercial use.

The old license is less permissive about commercial use:

Subject to the other terms of this license, the User is permitted to use the Software in a profit-making enterprise, provided such profit arises primarily from use of the Software and not from distribution of the Software or a work including the Software in whole or part.

Redistribution is more restricted:

This licence does not grant any right of re-distribution or use in any manner other than the above. The Company has separate license documents that apply to other uses (such as re-distribution via the internet or on CD)

I found the license for POV-Ray 3.6, but the usual page for software license teardowns doesn't mention POV-Ray.

Here are some tests I've done on my devices compiling Povray 3.6 (single threaded) and rendering the benchmark scene. I was rather surprised that my new Nexus 4 (Qualcomm S4) is slower per core than my SGS II (Samsung Exynos 4). Yet the Nexus 4 doesn't feel any slower and is my main phone now due to the larger and higher resolution screen.

Athlon II x4 (2.8 GHz): 179.82 pps ; 64.22 pps/GHz
Exynos 5 (1.7 GHz): 77.36 pps ; 45.51 pps/GHz (-mfloat-abi=hard -mcpu=cortex-a9 -mthumb -mthumb-interwork)
PowerPC 750 (700 MHz): 20.47 pps ; 29.25 pps/GHz

Exynos 4210 (1.2 GHz): 29.90 pps ; 24.91 pps/GHz (-mfloat-abi=hard)
Pentium 4m (1.5 GHz): 36.24 pps ; 24.16 pps/GHz
S4 Pro APQ8064 (1.5 GHz): 31.81 pps ; 21.20 pps/GHz (-mfoat-abi=hard -mcpu=cortex-a15)
Atom N270 (1.6 GHz): 28.96 pps ; 18.10 pps/GHz

Unfortunately can't post all the data I have because this site thinks there're too many 'junk' characters already...

Why massage and hack a program like blender when you can use the venerable POV-Ray, open source raytracer since 25 years back, first raytracer in space, etc.

You can already do all of this directly in its scene description language, and you will get exact results instead of interpolated meshes.

My target was SVG so I used Inkscape and gradients.

Why massage and hack a program like blender when you can use the venerable POV-Ray, open source raytracer since 25 years back, first raytracer in space, etc.

You can already do all of this directly in its scene description language, and you will get exact results instead of interpolated meshes.

Unfortunately, the term "supercomputer" isn't really being used properly. They built a cluster of computers, sure. But "supercomputer"??? Hardly. The Raspberry Pi uses a processor based on ARM v6. Lemme give a single-threaded rendering comparison (Povray 3.6 running the benchmark scene (here's what the benchmark image output looks like) with my old HTC Aria, which uses a Qualcomm MSM 7227 processor and has similar processor specs as the Raspberry Pi (ARM v6 + VFP2 floating point hardware):

HTC Aria (MSM 7227 @ 0.6 GHz) *
    Debian 6.0(armel), gcc 4.4, -mfloat-abi=softfp -mthumb
    Parse Time: 0 hours 1 minutes 3 seconds (63 seconds)
    Photon Time: 0 hours 53 minutes 49 seconds (3229 seconds)
    Render Time: 57 hours 31 minutes 41 seconds (207101 seconds)
    Total Time: 58 hours 26 minutes 33 seconds (210393 seconds)

For comparison, here's a faster ARM processor from my Samsung Galaxy S II:

Exynos 4210 @ 1.2 GHz (ARM Cortex A9),
    Debian 7.0(armhf), gcc 4.6, -mcpu=cortex-a9 -mhard-float -mthumb -mfpu=vfpv3 -ffast-math -funsafe-math-optimizations
    Parse Time: 0 hours 0 minutes 4 seconds (4 seconds)
    Photon Time: 0 hours 1 minutes 33 seconds (93 seconds)
    Render Time: 1 hours 26 minutes 34 seconds (5194 seconds)
    Total Time: 1 hours 28 minutes 11 seconds (5291 seconds)

And here's from an Intel Core i5 2400s @ 2.5 GHz:

Core i5 2400s @ 2.5 GHz, Ubuntu 12.04, gcc 4.6, -march=corei7-avx
Total Scene Processing Times
    Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
    Photon Time: 0 hours 0 minutes 14 seconds (14 seconds)
    Render Time: 0 hours 10 minutes 12 seconds (612 seconds)
    Total Time: 0 hours 10 minutes 27 seconds (627 seconds)

The ARM v6 processor took more than 2 days to render something that takes 10 minutes on a Core i5. So, "supercomputer" this cluster is not.

* You may say, "Hey, this test is running using soft-float! If you used hard float, it'd be faster!" Well, you would be right that it would render faster under hard float, but this processor still wouldn't finish rendering in less than a day, let alone come anywhere close to Core i5 or Cortex A9.

Unfortunately, the term "supercomputer" isn't really being used properly. They built a cluster of computers, sure. But "supercomputer"??? Hardly. The Raspberry Pi uses a processor based on ARM v6. Lemme give a single-threaded rendering comparison (Povray 3.6 running the benchmark scene (here's what the benchmark image output looks like) with my old HTC Aria, which uses a Qualcomm MSM 7227 processor and has similar processor specs as the Raspberry Pi (ARM v6 + VFP2 floating point hardware):

HTC Aria (MSM 7227 @ 0.6 GHz) *
    Debian 6.0(armel), gcc 4.4, -mfloat-abi=softfp -mthumb
    Parse Time: 0 hours 1 minutes 3 seconds (63 seconds)
    Photon Time: 0 hours 53 minutes 49 seconds (3229 seconds)
    Render Time: 57 hours 31 minutes 41 seconds (207101 seconds)
    Total Time: 58 hours 26 minutes 33 seconds (210393 seconds)

For comparison, here's a faster ARM processor from my Samsung Galaxy S II:

Exynos 4210 @ 1.2 GHz (ARM Cortex A9),
    Debian 7.0(armhf), gcc 4.6, -mcpu=cortex-a9 -mhard-float -mthumb -mfpu=vfpv3 -ffast-math -funsafe-math-optimizations
    Parse Time: 0 hours 0 minutes 4 seconds (4 seconds)
    Photon Time: 0 hours 1 minutes 33 seconds (93 seconds)
    Render Time: 1 hours 26 minutes 34 seconds (5194 seconds)
    Total Time: 1 hours 28 minutes 11 seconds (5291 seconds)

And here's from an Intel Core i5 2400s @ 2.5 GHz:

Core i5 2400s @ 2.5 GHz, Ubuntu 12.04, gcc 4.6, -march=corei7-avx
Total Scene Processing Times
    Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
    Photon Time: 0 hours 0 minutes 14 seconds (14 seconds)
    Render Time: 0 hours 10 minutes 12 seconds (612 seconds)
    Total Time: 0 hours 10 minutes 27 seconds (627 seconds)

The ARM v6 processor took more than 2 days to render something that takes 10 minutes on a Core i5. So, "supercomputer" this cluster is not.

* You may say, "Hey, this test is running using soft-float! If you used hard float, it'd be faster!" Well, you would be right that it would render faster under hard float, but this processor still wouldn't finish rendering in less than a day, let alone come anywhere close to Core i5 or Cortex A9.

Since I use Povray for image rendering, I decided to install Debian 7 on the two ARM devices I have at my disposal (Samsumg Galaxy S II and Barnes & Noble Nook Color), compiled Povray 3.6 (3.7 is a bit difficult to compile even though it's multithreaded, but 3.6 is good enough to see what the processor can do) and see what the real results are:

    Debian 7.0(armhf), gcc 4.6, -mhard-float -mcpu=cortex-a9 -march=armv7 -mthumb
        -mfpu=neon -funsafe-math-optimizations
    Parse Time: 0 hours 0 minutes 4 seconds (4 seconds)
    Photon Time: 0 hours 1 minutes 30 seconds (90 seconds)
    Render Time: 1 hours 20 minutes 38 seconds (4838 seconds)
    Total Time: 1 hours 22 minutes 12 seconds (4932 seconds)

    Debian 6.0 (armel), gcc 4.4, -mfloat-abi=softfp -mcpu=cortex-a9
    Parse Time: 0 hours 0 minutes 4 seconds (4 seconds)
    Photon Time: 0 hours 1 minutes 43 seconds (103 seconds)
    Render Time: 1 hours 49 minutes 59 seconds (6599 seconds)
    Total Time: 1 hours 51 minutes 46 seconds (6706 seconds)

OMAP 3621 @ 1.2 GHz (B&N Nook Color)
Debian 7.0 (armhf), gcc 4.6, -mhard-float -mcpu=cortex-a8
-mfpu=neon -funsafe-math-optimizations
Parse Time: 0 hours 0 minutes 9 seconds (9 seconds)
Photon Time: 0 hours 6 minutes 14 seconds (374 seconds)
Render Time: 5 hours 57 minutes 9 seconds (21429 seconds)
Total Time: 6 hours 3 minutes 32 seconds (21812 seconds)

Here are some results compared to other processors I have:
Ordered by pps:
Core i5 2400S (2.5 GHz): 235.177 pps ; 94.07 pps/GHz
Athlon II x4 (2.8 GHz): 179.82 pps ; 64.22 pps/GHz
Celeron 220 (1.2 GHz): 81.15 pps ; 67.62 pps/GHz
Pentium 4m (1.5 GHz): 36.24 pps ; 24.16 pps/GHz
Exynos 4210 (1.2 GHz): 29.90 pps ; 24.91 pps/GHz (-mfloat-abi=hard)
Atom N270 (1.6 GHz): 28.96 pps ; 18.10 pps/GHz
Exynos 4210 (1.2 GHz): 21.99 pps ; 18.32 pps/GHz (-mfloat-abi=softfp)
PowerPC 750 (700 MHz): 20.47 pps ; 29.25 pps/GHz
Pentium !!! (450 MHz): 12.43 pps ; 27.62 pps/GHz
OMAP 3621 (1.2 GHz): 6.76 pps ; 5.63 pps/GHz

Exynos is Cortex A9 and OMAP 3621 is Cortex A8. Cortex A9 is about on par with a Pentium 4. Cortex A8 can't even beat a a 14 year old Pentium !!! Currently there's only one Cortex A15 product that's available, but I don't have it.

I believe you're mistaken. Raytracing IS the technique where you're tracing light much the way it happens in the real world. The techniques usually used in GPUs are quite backward. It hasn't really been all that downhill, though; they've gotten pretty good at faking a lot of the effects, but when it comes to things like shadows, local lighting, radiosity, and refraction, Raytracing is where it's at.

Examples:
https://upload.wikimedia.org/wikipedia/commons/e/ec/Glasses_800_edit.png
http://hof.povray.org/images/chado_Big.jpg
http://hof.povray.org/micra1_09.html
http://hof.povray.org/images/warm_up_Big.jpg
http://hof.povray.org/images/kitchen.jpg

All of those are from POV-Ray. There are plenty more in their gallery over here:
http://hof.povray.org/

Feel free to send some counterexamples of other techniques doing it better.

I believe you're mistaken. Raytracing IS the technique where you're tracing light much the way it happens in the real world. The techniques usually used in GPUs are quite backward. It hasn't really been all that downhill, though; they've gotten pretty good at faking a lot of the effects, but when it comes to things like shadows, local lighting, radiosity, and refraction, Raytracing is where it's at.

Examples:
https://upload.wikimedia.org/wikipedia/commons/e/ec/Glasses_800_edit.png
http://hof.povray.org/images/chado_Big.jpg
http://hof.povray.org/micra1_09.html
http://hof.povray.org/images/warm_up_Big.jpg
http://hof.povray.org/images/kitchen.jpg

All of those are from POV-Ray. There are plenty more in their gallery over here:
http://hof.povray.org/

Feel free to send some counterexamples of other techniques doing it better.

I believe you're mistaken. Raytracing IS the technique where you're tracing light much the way it happens in the real world. The techniques usually used in GPUs are quite backward. It hasn't really been all that downhill, though; they've gotten pretty good at faking a lot of the effects, but when it comes to things like shadows, local lighting, radiosity, and refraction, Raytracing is where it's at.

Examples:
https://upload.wikimedia.org/wikipedia/commons/e/ec/Glasses_800_edit.png
http://hof.povray.org/images/chado_Big.jpg
http://hof.povray.org/micra1_09.html
http://hof.povray.org/images/warm_up_Big.jpg
http://hof.povray.org/images/kitchen.jpg

All of those are from POV-Ray. There are plenty more in their gallery over here:
http://hof.povray.org/

Feel free to send some counterexamples of other techniques doing it better.

I believe you're mistaken. Raytracing IS the technique where you're tracing light much the way it happens in the real world. The techniques usually used in GPUs are quite backward. It hasn't really been all that downhill, though; they've gotten pretty good at faking a lot of the effects, but when it comes to things like shadows, local lighting, radiosity, and refraction, Raytracing is where it's at.

Examples:
https://upload.wikimedia.org/wikipedia/commons/e/ec/Glasses_800_edit.png
http://hof.povray.org/images/chado_Big.jpg
http://hof.povray.org/micra1_09.html
http://hof.povray.org/images/warm_up_Big.jpg
http://hof.povray.org/images/kitchen.jpg

All of those are from POV-Ray. There are plenty more in their gallery over here:
http://hof.povray.org/

Feel free to send some counterexamples of other techniques doing it better.

I believe you're mistaken. Raytracing IS the technique where you're tracing light much the way it happens in the real world. The techniques usually used in GPUs are quite backward. It hasn't really been all that downhill, though; they've gotten pretty good at faking a lot of the effects, but when it comes to things like shadows, local lighting, radiosity, and refraction, Raytracing is where it's at.

Examples:
https://upload.wikimedia.org/wikipedia/commons/e/ec/Glasses_800_edit.png
http://hof.povray.org/images/chado_Big.jpg
http://hof.povray.org/micra1_09.html
http://hof.povray.org/images/warm_up_Big.jpg
http://hof.povray.org/images/kitchen.jpg

All of those are from POV-Ray. There are plenty more in their gallery over here:
http://hof.povray.org/

Feel free to send some counterexamples of other techniques doing it better.

Could you elaborate?

I have an AMD 1090T (6 cores @ 3.2 GHz) that I've run FreeBSD 8.2 and Debian 7 on. I run Povray 3.7, which is multi-threaded (compared to the prior version which was not), on this machine and was testing out OSes. Using the latest gcc version for each OS (4.6), it turns out running on FreeBSD is about 15% faster than on Debian running the standard benchmark:

FreeBSD 8.2, gcc 4.6, -march=barcelona

Render Time:
    Photon Time: 0 hours 0 minutes 2 seconds (2.390 seconds)
                            using 9 thread(s) with 2.763 CPU-seconds total
    Radiosity Time: No radiosity
    Trace Time: 0 hours 3 minutes 10 seconds (190.466 seconds)
                            using 6 thread(s) with 1113.568 CPU-seconds total

Debian 7.0, gcc 4.6.1, -march=barcelona

Render Time:
    Photon Time: 0 hours 0 minutes 2 seconds (2.277 seconds)
                            using 9 thread(s) with 2.648 CPU-seconds total
    Radiosity Time: No radiosity
    Trace Time: 0 hours 3 minutes 38 seconds (218.326 seconds)
                            using 6 thread(s) with 1277.363 CPU-seconds total

Having participated in the first of the Student Cluster Challenges at SC07 when I was still in undergrad, I can attest that there's far more to this than what the summary lets on. Not only are you limited to 26 Amps, which is the significant limiting factor, but you're located on the show floor and running your system for 36 hours straight in front of the conference attendees. Moreover, all hardware must be in production and unmodified and fit within a single rack. The Taiwanese team lucked out in this regard as they were using the (then new) 45nm Intel Xeons that were announced the day before the competition started. The only thing you can modify is the code for the programs you have to run (except for the HPC benchmarks).

Some of you might be thinking "pfff...I can stay awake for 36 hours, no problem". That's true, but you're not allowed to be in your booth for more than 12 hours straight and after you leave you must take an 8 hour break. Furthermore, the machines are firewalled from all incoming connections and do not share the same internet connection that the rest of the conference uses.

At SC07, there was a significant power failure on the second day of the competition which brought most teams to their knees. The applications we were running (GAMESS, POP, POV-RAY) are not designed to pick up from a power failure. While the Taiwanese had by far the most powerful system, they couldn't recover from the power failure that had corrupted their SAN in time to win.

To your point, I'm not sure you could get 158 Atoms in a set of off-the-shelf servers that would fit in a single rack to equal a cluster running the latest E series Xeons that perform at top clock but have a lower TDP.

• Oh no! The pixel next to me is WAY different! I'll bet that we missed something that goes between us!
• *look in between the pixels*
• Ah HA! I see that this is an edge of some sort, and human eyes would, if this were real, see this pixel as a mixture of colors
• *combine the samples taken when looking around in an average mimicking what real life would show*

So you see, it isn't blurring at all! It's taking more samples, and increasing the accuracy of the image relative to what is being sampled, where it is necessary.
As I said, this isn't the algorithm that everything uses, some do it for every single pixel, but the end result is about the same except in extreme corner cases.

The common Mandelbrot set is really a 2-dimensional slice of a 4-dimensional object identified by both the combination of the complex numbers Z0 and C in the canonical Zn+1 = Zn^2 + C. The mandelbrot set lives in the plane where Z0 = 0 + 0i, while the Julia sets live on infinitely-many-squared orthogonal planes in the remaining two dimensions, each one intersecting Mandelbrot's plane in a single point of complex coordinates C.

Visualizing this hyperspace monster was made easy by POV-Ray. It took my computer two week of computation to render 80 seconds of animated 3D slices of a the quaternion. Check out the scene source.

/me looks forward for a real-time Julia4D explorer.

Because you can just go out and grab a $300 netbook with 6GB of RAM, right? Even if you could, not all of the Atom processors support EMT64, though the most-popular ones do.

32-bit is still faster for a lot of things, too. The i486 has been around for 20 years now, amd64 not so long. The compilers haven't quite caught up.

To Microsoft's credit, they are requiring 64-bit for a lot of their enterprise products now. IIRC, Exchange 2007 and SQL 2008 both require either 2k3 or 2k8 64-bit.

I disagree. At least on x86-64 there's almost a doubling of the number of registers (twice the number of general purpose and SIMD FP registers). This greatly reduces the register pressure for compilers, which have been keeping up with processors thus far. For example, I use Povray a lot. I can guarantee you that a custom compiled 64-bit binary will definitely render faster than a custom compiled 32-bit binary on the same system.

Consider something like POV-Ray, since it's a programming environment with a visual payoff.

Show someone a simple program that generates 10 randomly positioned mirrored sphere over a checkered landscape then encourage them to play with the number of sphere, assign colors to them, etc.

Much more interesting to be able to *see* the output of your program than just reading "Hello World!".

G.

If you click through the sciencenews.org article, you can get to the actual website of the people who made these videos. From there you'll find that these videos are Creative Commons licensed, and available for download as high res MOVs. I tried the torrents, but they all stalled, so I just used wget to grab them from the US mirror.

The POV-Ray version 4.0 has been "informally decided" to be released under GNU GPLv3 by the devteam. Admittably, the release is probably far off in future, since it'll be almost complete rewrite.

Even with ray-tracing, colour mapping for textures will likely never disappear. You do, after all, need something to indicate to the ray tracer how the surface reflects light. Gazing through POV-Ray's documentation, there appears to be a variety of methods for accomplishing this, with bitmap-based color maps being just one (and perhaps one of the fastest). I believe this answers your question, too. A type of pixel shader is used in ray-tracing to describe materials, but somewhat differently from those used in rasterization-based rendering.

Not seeing what Microsoft has to do with X11 POV-Ray. been using it for like a decade now.

"What do you mean battle? They will happily use this hardware effects for faster rendering!"

How is that? Didn't realize that!

From: http://tag.povray.org/povQandT/miscQandT.html

  _ _

"Will POV-Ray render faster if I buy the latest and fastest 3D videocard?"

No.

3D-cards are not designed for raytracing. They read polygon meshes and then scanline-render them. Scanline rendering has very little, if anything, to do with raytracing. 3D-cards can't calculate typical features of raytracing as reflections etc. The algorithms used in 3D-cards have nothing to do with raytracing.

This means that you can't use a 3D-card to speed up raytracing (even if you wanted to do so). Raytracing makes lots of float number calculations, and this is very FPU-consuming. You will get much more speed with a very fast FPU than a 3D-card.
  _ _

Ok, as this is a CPU hardware improvement it can be used by povray I guess.

It looks like Povray is experimenting with one.

For those interested in real-time raytracing, the latest beta version of POV-Ray has a neat (but experimental) RTR feature. The source is now available for Windows and Unix/Linux. There also demo scenes available (and another demo scene with pre-baked textures can be found here).

This, this and this are fairly realistic. Those are only examples from povray hall of fame, there are better raytracers.

This, this and this are fairly realistic. Those are only examples from povray hall of fame, there are better raytracers.

I just made a quick check and found a download site with 1000 image editors. How many open source applications do you need? There's GIMP and Krita and... honestly, I can't think of a third one.

• POV-Ray
• Blender
• Xara
• Krita
• Inkscape

I've got a few more bookmarked. As for why there are so many, some are meant to do specific things, run in specific environments, or to edit specific formats. Some, like POV-Ray, are vector graphics editors. Some are bitmap editors. Some are 2D and others 3D. Some only run on Y OS in Z like Krita is for KDE. There are a number of reasons there are so many different FOOS image editors.

I wonder if the growing need for OS and client software diversity will finally make hardware manufacturers start to do real multiple OS support and web site designers to finally code to be non-client dependent.

I met one website developer who only used Macs. She ran Windows in a vm so she could test in Windows browsers but that's it. I've heard others are the same.

OpenOffice on Windows

Though I'm using Windows on my desktop now I plan on getting a MBP RSN, and I'll try OO, NeoOffice, or another version of OO. I'm wondering what db to get though. I don't know if it's still true but I heard MySQL doesn't properly handle relations, and I've been thinking of trying PostGres and, or Firebird.

Once you replace the killer app you really open the door to your flavor of linux distro on the PC.

I've got a PC running Linspire Linux which I use as a server or storage right now, but as I say above I want to get a Macbook Pro for a laptop. The killer app(s) for me will be a graphics/photo editor and tools for web development. Photoshop is available for the Mac however before I fork over the money for it I want to try some FOOS apps, like POV-Ray, blender, or Inkscape to see if any of them is a good replacement for PS.

Firstly, the current development version of POV may be the last one released under the POV license... there is talk of releasing it under GPL along with Moray in the future. Secondly ... POV-Ray is not a modeler. Unlike Blender or Moray, Povray scenes are coded, not modeled. That's kinda what the scene description language is all about. Moray and other modellers that can output .pov files are kinda like using Visual Basic to write a program ... but not really.

I have to respectfully disagree. Blender's learning curve is horrendous. I spent a fair amount of time (all of my free time+ over the course of about 3 weeks) and got no where when trying to create simple animations for my physics students. I spent a weekend with POV-Ray and completed the first of many such short animations.

I know that Blender's capabilities blows POV-Ray's out of the water, but I couldn't do simply and easy stuff easily with Blender that I can with POV-Ray. Every so often I'll spend a weekend with Blender and make some incremental progress in my understanding of how it works for still scenes, but I haven't even gotten near the animation tools.

Perhaps Blender is easy to pick up for those who are already familiar with similar professional level tools, but that does not describe the entire (or even the important part) of the learning curve for the rest of us.

CinePaint, aka FilmGimp already supports 32 bits per channel. Use it if that's what's important to you.

Ah, isn't Cinepaint for movies and not photo editing? The Cinepaint homepage even says it's for retouching and is not an editor. Even so, I may give it a try along with other programs such as POV-Ray.

I'm a professional. I even teach Photoshop classes. And this is not a big deal. Really you need the added bit depth for photography work. But when I do come across this shortcoming of GIMP from time to time, it DOES make itself annoying. So what do I do? Open the image in another open source image editor that can handle the extra bits. Make my edits. Back to GIMP.

Because I want to work in photography, I don't work now because of an injury and photography is something I can do and have experience both behind the camera and in darkrooms, I've been checking out different photo editors and I haven't been able to find any that come close to the capabilities of Photoshop nor has 24 bit colour depth. And I use film, develop it, and then I'd scan it. I'd use a dslr unfortunately ones with full frame sensors are priced out of my range right now (forgetting about medium format). Ooh I see POV-Ray does offer 24 bit colour depths. But it's more a general graphics program and not a photo editor. You say you use another OS program for higher colour depths then go back to GIMP. Don't you loose those "extra bits" once you save in gimp? If they are saved maybe I could use POV-Ray with it.

The only thing that Adobe's done for me (as someone who makes a living in computer graphics) is make me aware that they are attempting to force me to be their customer by monopolizing the industry. THAT feels really great to my sensitive, artistic side.

I'll have a problem with Adobe when they have patents issued and start going after others over violations of those patents, software should NEVER EVER be patented, only specific implementations as long as it is unique.

There's just no way GIMP comes close to being a dropin replacement for Photoshop!

I disagree - all it takes is a short discussion about Adobe to convince many pro artists that O/S software like GIMP is based on superior principles.

Idealism and reality are different, sure I agree ideally OS is better, but when it comes to what actually works, for photo editing Photoshop sets the ceiling, and it is high compared to other offerings. This is especially true for either commercial, fashion, or nature, photography, not that they can't be one and the same.

You might find that POV-ray is a better fit for your programmer brain. http://povray.org

Actually, the "Liquid Animation" series by fidos uses the Navier Stokes equations.... If anyone's interested, look for them here; the last one was posted on May 20, 2006.

First we'll toss in one some people will kick and scream about: Graphic Design. Yes, I know all about the Gimp.

I disagree.

Not about the GIMP; for production work on raster images it doesn't make sense to leave the known comforts of PhotoShop or Paint Shop Pro for a FOSS equivalent that might do the job as well, but offers no significant improvements. Yet tomorrow's graphics designers are currently on student budgets and are learning The GIMP because of that— something that should be making Adobe nervous about tomorrow's profits.

But Blender and POV-Ray are major presences in animation and ray tracing work: many of the younger people working in the field cut their teeth on these, and still use them for exploring some concepts. Inkscape has compatibility benefits over Illustrator and is beginning to attract commercial use for that reason, even though it is a long way from its v1.0. Scribus is poised to shoulder its way into first tier desk top publishing.

FOSS has become majorily important in the graphics sector.

I don't know anything about audio mixers. Maybe the value of 1 kazillion is closer to 10 than to 8. Maybe FOSS products like Audacity are making significant inroads among the independent bands. I've no idea.

I know nothing about games, either. I know a lot of tomorrow's animators and game designers are developing their techniques with Blender and POV-Ray— I expect that they will continue to use these to some degree when they get paying jobs.

Macs are fine, but you will be spending more on Photoshop licenses and such in addition to the extra Mac cost.

Yea, I know PS is expensive. Because of that I checked some into other software and have used some. I have used GIMP as well as Paintshop Pro and I've been thinking about trying out Corel Painter. Before I do I'll at least check out MacGIMP, POV-Ray, blender, and/or others. What I may end up doing though is buying an old version of Photoshop, there are some shops in the area that sale and we occasionally have computer shows that displayers sale them as well, and there's a steep discount for upgrades to PS CS.

And yes, I'd like to do some graphic design as well as web design. I was in college until running into some problems almost two years ago working on a web programming degree (it's only a two year degree not a four year degree). However I met a number of student photographers on campus, I took a couple of photography classes myself as well as hung out in the photography rooms, and a few of them expressed interest in setting up online portfolios to showcase their work and sale some photos as well, so I've been thinking of combining both interests and designing websites for photographers.

there really is very little hardware that does not have Linux support.

I've got an HP Pavillion which I got specifically because HP was supposed to be Linux friendly. When I got it I also got a second hdd as well as another graphics card. The second hdd was to install Linux on and the new graphics card was so I could setup a dual head, er two monitors. I only found out later that the PC wasn't Linux compatible, checking out hardware compatibility databases I didn't find any distro that supported it. Graphics, the modem, ethernet, sound, and such were all built onto the motherboard. I even emailed HP tech support about it and they said a PC had to be ordered for Linux, that otherwise they didn't check to see if PCs were Linux compatible.

I do have two PCs with Linux though. The first one is a dualboot machine with a DEC Alpha cpu running NT 4.0 and Redhat. However as the builder didn't offer a modem with the 56k standard my ISP used, I didn't get the PC with one. Then because the cpu's an Alpha I didn't get much software installed so I haven't used it much and not at all in more than 3 years. Recently however, about 2 months ago, I did get a new PC with Linspire Linux preinstalled. I haven't really used it much directly, about all I've done so far is to use one of the hdds for storage. I keep saying I'll actually start using it but I haven't done anything more than play games. I got it because the PC I'm using now has been giving me troubles constantly crashing and needing to be rebooted, now I'm thinking I won't actually get to using the new PC seriously until this one finally dies. At least when it does I'll have all my important files on the new PC, which takes up about 150 GB.

Out of curiosity what is your disability?

It's a neurologcal impairment, I am a survivor of a TBI, Traumatic Brain Injury. And I do mean "survivor". That's what "we" are called, but also in my case while I was in a coma the docs told my family it would be a miracle if I lived. NOT!!! But that's another story.

They also didn't test it with povray, which would have been great since 3.7beta supports multithreading.

Shadows; they'd be Doom 3-like. Several games have full stencil shadows and that's just how raytraced ones would look: sharp and straight.

Sharp and straight shadows? Check out this example or this one or yet another. Granted, these scenes rendering times are measured in hours, not fractions of a second... but eventually games will be at that level of quality.

Shadows; they'd be Doom 3-like. Several games have full stencil shadows and that's just how raytraced ones would look: sharp and straight.

Sharp and straight shadows? Check out this example or this one or yet another. Granted, these scenes rendering times are measured in hours, not fractions of a second... but eventually games will be at that level of quality.

Shadows; they'd be Doom 3-like. Several games have full stencil shadows and that's just how raytraced ones would look: sharp and straight.

Sharp and straight shadows? Check out this example or this one or yet another. Granted, these scenes rendering times are measured in hours, not fractions of a second... but eventually games will be at that level of quality.

If i remember it correctly from my days of playing with POVRay (free raytracing app), the time it took to raytrace an image depended on things like the presence (or not) of semi-transparent, semi-reflective surfaces and on the number of light sources.

If this is still the case, then going from the current rendering techniques in games to raytracing would result in images with more realistic reflections and lighting but, due to performance tradeoffs, few reflective surfaces and light sources.

Besides, at the moment what games need the most is beter AIs and procedurally generated content, not yet another layer of eyecandy that requires gamers to upgrade their hardware (again).