Jim Snow wrote:
I guess a pov importer wouldn't necessarily be all that difficult, or an exporter, for that matter. (Supporting every single primitive type, texture, and rendering feature would be a daunting challenge, but just supporting the basics might be relatively simple.) The problem comes when you want to import a nice short hand-edited script, and then do a few things to it and export it again: suddenly the file turns into a multi-megabyte monstrosity with all the loops unrolled and all the recursive macros expanded and you lose the ability to hand-edit the scene. Depending on what you're doing, this might not be a problem.
I see what you mean... I guess you'd want to seperate the machine-generated parts from the hand-written parts by careful use of #includes...
Well, for example, Haskell doesn't have hetrogenous lists - which are trivial in any OOP language. That's quite awkward to get around. Also, both spheres and cylinders have a "radius" property, but then you end up with name clashes. Again, a non-issue in OOP languages. [I gather there's some new GHC language extension to partially solve this one - but only when types are statically known. In the general case, you'd have to write a "radius class" and define instances... yuck!]
It's funny you mention that, those are actually problems I ran into, but (having learned my lesson the hard way in Ocaml), I decided not to try and force the language to do things my way, but instead try to do things in a way that Haskell makes easy. For instance, I started out by making each primitive a separate type (Sphere, Triangle, etc...), and then made a type class that defines a ray intersection method (and a few other odds and ends), but then I realized that I can't do something as simple as store a list of primitives (or if there is in fact a way, I'm not aware of it). Instead, I made a single large sum type with all my primitives:
so that now I can easily make a list of primitives. (In fact, that's what a Group is.) I also gave up on using named fields, since coming up with a separate name for each one gets ugly: instead of radius, you have sphere_radius, cylinder_radius, cone_radius disc_radius, etc...
All of which works, but now it's a pain to add new primitives. And *all* supported primitives must be defined in a single monolithic module. And you can't reuse spheres as bounding volumes without either reimplementing them or loosing type safety.
That world is a very slow oyster. I've used blobs and isosurfaces in POV-Ray, and they're wonderfully expressive but also incredibly slow.
This explains why my PC contains the fastest CPU that I could afford, and why a while back I actually considered purchasing an 8-core server box that was on special offer for £600. (I'm now really kicking myself that I didn't buy that! 8 Xeon cores... it would have been so fast!) But yeah, I guess it depends on what your patience level is. I like the way a couple of lines of SDL can construct a blob object so intricate that it would be impossible to construct a triangle mesh like that with any known tool... but that's just me.
There are also other problems: the isosurface solvers are sometimes wrong, leading to ugly artifacts
Only if you set the max_gradient too low. And that's not surprising, given how the algorithm works... [Indeed, what's surprising is that they built a solver that works for arbitrary functions!]
and applying a texture to an isosurface or blob isn't necessarily straightforward.
That is a pitty. On the other hand, with function-based pigments, you can do some pretty impressive stuff. [For example, using the same function as the isosurface to distribute a texture map.]
Another issue is that isosurfaces are great for filling the scene with procedurally-generated complexity, but sometimes you need to do actual physics computations in order to make the object do the right thing. For instance, in the image I linked above, the water looks pretty good, but the waves should really be reflecting off of the castle when they hit it, and there's no way I know of to do that without actually doing some sort of finite-element fluid simulation. And since that's already an approximation, and it's already taking up a lot of memory, you might as well just represent it as a triangle mesh (or whatever happens to be the easiest representation to render efficiently).
The way I did that is as follows: 1. Create a function that represents the waves. 2. Sample that function at multiple points along the edges of whatever is protruding through the water. 3. Add another wave source at that point with an appropreate phase offset as per the samples you just took. 4. The actual isosurface is the sum of all the waves thus mentioned. Apparently the samples just need to be "close together" relative to the wavelength of the waves and it looks right. So if you have fairly large waves, you don't need many samples [and many wave functions to sum!] The results looked fairly good to me. I have yet to see anybody doing water simulation using a triangle mesh. Invariably people just make each particle in the system into a blob component, and let POV-Ray smooth the surface.
There's really a trade-off here between quality, time, and space.
Indeed. If I was trying to render a feature-length movie Pixar style, I'd probably be making different choices. But I'm not. I'm building still images, and the occasional short animation. For me, quality is the main concern. ;-)
Any blob or isosurface can be approximated with triangles, and if the triangles are smaller than a pixel (or sometimes even if they're quite a bit bigger) the difference isn't going to be noticeable.
False. 1. As I understand it, tesselating arbitrary surfaces is still an unsolved problem. 2. If you have curved reflective or refractive surfaces, these can magnify elements of the geometry, so even if every triangle is smaller than a pixel, you can still see the difference. (Ditto for shadow considerations.)