I've looked at this in the past. Aside from the programming effort required to intersect voxels and rays with NURBS, there is the fact that most such algorithms end up dynamically subdividing such surfaces down to pixel resolution. This is a problem for Radiance because pixel size is not known in the general context. Also, subdividing once at the outset into triangles results (in most cases) in faster rendering times. I decided it made more sense just to store a NURBS as a mesh object and render that.
It still would be nice to have code in obj2mesh to accept NURBS. Do you know if anyone actually uses .OBJ format for higher-order surfaces? I saw it in the specification, but I've never seen any example files. Cheers, -Greg > From: "Randolph M. Fritz" <rfr...@lbl.gov> > Date: January 30, 2012 3:34:39 PM EST > > On 2012-01-30 18:52:13 +0000, Greg Ward said: > >> Hi Fritz, >> The usual strategy is to convert to Radiance format, like obj2rad. I don't >> know how often it's used, but the .OBJ format has a NURBS specification, and >> it should be easy enough to support it with obj2mesh. > > That's an interesting thought. > >> That would have the advantage of including surface normal smoothing and uv >> textures. Implementing NURBS natively in Radiance would be a major >> undertaking by comparison. > > I suppose it would. > > I'm just getting tired of proliferating polygons. Most curved objects these > days are either modeled as NURBS objects, or by some subdivision method. And > yet--unless I grossly misunderstand Radiance octrees, which is > possible--octrees don't actually care about polygons at all. > > Oh, well. One more research project. > > Randolph _______________________________________________ Radiance-dev mailing list Radiance-dev@radiance-online.org http://www.radiance-online.org/mailman/listinfo/radiance-dev
