ajb@spamcop.net wrote:

G'day all.

Quoting Andrew Coppin :

...

The "Haskell ray tracer" seems to be a pretty standard and widely-used example program. But has anybody ever seriously tried to make a "production-grade" implementation? (I.e., one that is user-friendly, efficient, and with lots of functionallity.)

Speaking as an ex-VFX head, there are very few "production-grade" renderers out there, and of those, very few are primarily ray tracers, and of those, almost none are what most would consider "user-friendly".

So you've set the bar quite high there.

By "production grade" I don't mean "you can put Pixar to shame", I just mean "it's not an experimental research project - it's something designed to actually be used by normal users".

Philippa Cowderoy wrote:

On Sun, 15 Jul 2007, Andrew Coppin wrote:

...

By "production grade" I don't mean "you can put Pixar to shame", I just mean "it's not an experimental research project - it's something designed to actually be used by normal users".

Or to put it another way, that the code and UI are appropriate for "production grade" software in general, as opposed to a raytracer that's suitable for production grade rendering.

Well, I don't know - POV-Ray on Unix doesn't have a UI at all. ;-) On the other hand, it's feature-rich, it's fast (as ray tracers go anyway!), it doesn't crash when you try to use it, and it has rich documentation. I'd say it's "production-grade". Similarly, Parsec is something that I'd think of as a "production-grade" Haskell library: It goes fast, it works well, and it's nicely documented. On the other hand, search the Haskell wiki and you'll find plenty of "example" ray tracers that probably work, but I doubt they're fast or user friendly. They're written to demonstrate how you'd do the thing, not to actually do it "for real", if you see what I mean...

G'day all. By "production grade", I assumed that meant "suitable for use in a production". Quoting Sebastian Sylvan :

Neither does mentalray!

Correct! Most production renderers don't have GUIs. Anything that REQUIRES a GUI is by definition a toy because it can't be used in a farm. But I digress.

"production grade" probably means:

"Production grade" means that you need to get a couple of hundred little things correct. That's true of any application, whether it's a renderer or a database server. For example: If memory can hold N "things", the system shouldn't thrash if you feed it N+2. On real productions, the #1 thing that you need is flexibility. You ideally want at least two ways to do any one task (so you can choose which is the most appropriate), and for as many knobs as possible to be exposed so you can tweak them. And at the highest level, the main thing I'd be looking for is some degree of standards compliance. I want to be able to take my modeller (say, Maya), and render the scene in at least two different renderers, and for the resulting images to line up exactly. That way, I can render elements separately, using the most appropriate tool for each element, and combine them afterwards. And given that ray tracing requires the highest-level geometry for the entire scene be retained in an online database (often in memory), I want to avoid that if I don't need it for some element. Remember that rendering 85 minute movie (typical length for an animated feature), at 24 frames per second, allowing a year of computer time, gives me less than five minutes to spend on each frame, and that assumes you can keep the pipeline full 24/7 and you only compute each frame once. Yes, you can multiply that by the number of CPUs in your render farm, but still, that's what you're up against when you're talking "production grade". Cheers, Andrew Bromage

G'day all. Quoting Dan Piponi :

But I don't think that means there is no role for Haskell in rendering. Examples of places I think Haskell could play a role are: the shader language, [...]

For the record, I've written 2.5 production shader compilers. The 0.5 was in Haskell. :-) Cheers, Andrew Bromage

Hello ajb, Monday, July 16, 2007, 5:00:54 AM, you wrote:

...

But I don't think that means there is no role for Haskell in rendering. Examples of places I think Haskell could play a role are: the shader language, [...]

For the record, I've written 2.5 production shader compilers. The 0.5 was in Haskell. :-)

and why you stopped at 0.5? was it due to haskell limitations or something else? how haskell looks in this area compared to other languages (and what other languages you used)? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Dan Piponi wrote:

On 7/14/07, Andrew Coppin wrote:

...

The "Haskell ray tracer" seems to be a pretty standard and widely-used example program. But has anybody ever seriously tried to make a "production-grade" implementation? (I.e., one that is user-friendly, efficient, and with lots of functionallity.)

I'm not very hopeful about writing a "production-grade" ray tracer completely in Haskell. In my experience, "production-grade" rendering is always banging up on the limit of how much RAM you have on your machine.

It seems everybody misunderstands what I mean by "production-grade". I only meant that the program actually works properly and has some usable documentation. ;-)