Jon Harrop wrote:
On Thursday 24 April 2008 20:29:50 Andrew Coppin wrote:
2. It's the only program I've seen that can render *real* curves, not
fake trickery with triangle meshes.
What you called fake trickery with triangle meshes is the core of all modern
computer graphics.
Jim Snow wrote:
The Scene Description Language (SDL) is the best and worst thing about
POV-Ray.
Indeed.
It's very intuitive and user-friendly, so a person can reasonably
write a complex scene in pure code without using an external GUI editor.
Not to mention that there's a smooth and
On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Personally, I don't see the point in rendering a couple of million
mathematically flat surfaces,
What about speed ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
david48 [EMAIL PROTECTED] writes:
Personally, I don't see the point in rendering a couple of million
mathematically flat surfaces,
What about speed ?
If it doesn't have to be correct, it can be arbitrarily fast
:-)
-k
--
If I haven't seen further, it is by standing in the footprints of
On Sat, Apr 26, 2008 at 10:21 AM, david48
[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Personally, I don't see the point in rendering a couple of million
mathematically flat surfaces,
What about speed ?
If you
david48 wrote:
On Sat, Apr 26, 2008 at 9:33 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Personally, I don't see the point in rendering a couple of million
mathematically flat surfaces,
What about speed ?
Speed is not always the most important thing. ;-)
[The best things come to
Jim Snow wrote:
Those are good links. It's good to see that the groups of people who
know about Haskell and people who know about ray tracing do, in fact,
overlap.
Background information for everyone else: Wald's work is related to
OpenRT, which is an OpenGL-like api for interactive ray
I've ended up writing something more like POV-Ray than OpenRT, and that's
fine with me. I'd rather have something that's slower but more expressive
than fast but inflexible. (The former is also perhaps more easily
attainable, particularly in Haskell.)
Not knowing anything about raytracing,
On Thursday 24 April 2008 20:29:50 Andrew Coppin wrote:
2. It's the only program I've seen that can render *real* curves, not
fake trickery with triangle meshes.
What you called fake trickery with triangle meshes is the core of all modern
computer graphics. Focussing on ray tracing instead of
Andrew Coppin wrote:
Wow. The POV-Ray guys are talking about Haskell [or rather, my
personal addiction to it] and the Haskell guys are talking about
POV-Ray... on the same day... How unlikely is that? ;-)
That's odd; I had a personal addiction to POV-Ray for a few years, and
just now have
On Fri, 2008-04-18 at 14:34 -0700, David Roundy wrote:
On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote:
On a particular scene with one instance of the single-threaded renderer
running, it takes about 19 seconds to render an image. With two
instances running, they each take about
Derek Elkins wrote:
Ingo Wald's work on interactive coherent raytracing springs to mind.
http://www.sci.utah.edu/~wald/Publications/
Interactive Rendering with Coherent Raytracing
http://graphics.cs.uni-sb.de/~wald/Publications/EG2001_IRCRT/InteractiveRenderingWithCoherentRayTracing.pdf
is a
jsnow:
A new version of my raytracer is out. It now supports cones, cylinders,
disks, boxes, and planes as base primitives (previously it only
supported triangles and spheres), as well as transformations of
arbitrary objects (rotate, scale, translate) and the CSG operations
difference
On Fri, Apr 18, 2008 at 7:43 PM, Don Stewart [EMAIL PROTECTED] wrote:
jsnow:
A new version of my raytracer is out. It now supports cones, cylinders,
disks, boxes, and planes as base primitives (previously it only
supported triangles and spheres), as well as transformations of
arbitrary
Don Stewart wrote:
jsnow:
A new version of my raytracer is out. ...
Very impressive. Did you consider cabalising the Haskell code, so it
can be easily distributed from hackage.haskell.org?
I note on the website you say:
no threading (shared-memory concurrency is not supported
On Sat, Apr 19, 2008 at 12:19:19AM +0400, Bulat Ziganshin wrote:
Saturday, April 19, 2008, 12:10:23 AM, you wrote:
The other problem I had with concurrency is that I was getting about a
50% speedup instead of the 99% or so that I'd expect on two cores. I
2 cores doesn't guarantee 2x
David Roundy wrote:
On Sat, Apr 19, 2008 at 12:19:19AM +0400, Bulat Ziganshin wrote:
Saturday, April 19, 2008, 12:10:23 AM, you wrote:
The other problem I had with concurrency is that I was getting about a
50% speedup instead of the 99% or so that I'd expect on two cores. I
2
On Fri, Apr 18, 2008 at 9:10 PM, Jim Snow [EMAIL PROTECTED] wrote:
The scene is shared between threads. (Complex scenes can be quite large.)
I'm assuming this is handled as a read-only shared memory region or
something similar, as one might expect, and is not actually copied.
Ah, when
On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote:
On a particular scene with one instance of the single-threaded renderer
running, it takes about 19 seconds to render an image. With two
instances running, they each take about 23 seconds. This is on an
Athlon-64 3800+ dual core, with
Jim Snow wrote:
The concurrency bug has to do with excessive memory use, and was
discussed earlier here on the mailing list (search for Glome).
http://hackage.haskell.org/trac/ghc/ticket/2185
Interesting. I looked at your test case. I can reproduce your problem
when I build with the
David Roundy wrote:
On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote:
On a particular scene with one instance of the single-threaded renderer
running, it takes about 19 seconds to render an image. With two
instances running, they each take about 23 seconds. This is on an
Athlon-64
jsnow:
David Roundy wrote:
On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote:
On a particular scene with one instance of the single-threaded renderer
running, it takes about 19 seconds to render an image. With two
instances running, they each take about 23 seconds. This is on an
22 matches
Mail list logo
