NURBS oconv?

Would it be possible, do people think, to do a version of oconv that would accept a NURBS model, perhaps in .3dm format, as input?

···

--
Randolph M. Fritz

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 would have
the advantage of including surface normal smoothing and uv textures.
Implementing NURBS natively in Radiance would be a major undertaking by
comparison.

-Greg

Would it be possible, do people think, to do a version of oconv that

would accept a NURBS model, perhaps in .3dm format, as input?

···

On Monday, January 30, 2012, Randolph M. Fritz <[email protected]> wrote:

--
Randolph M. Fritz

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

···

On 2012-01-30 18:52:13 +0000, Greg Ward said:

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" <[email protected]>
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

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.

Oh, I see.

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.

Yes, McNeil's Rhinoceros does for export--I can send you some samples if you'd like. Let me know what shapes to export. I can also ask some of the media people I know if 3ds max and Maya do.

Randolph

···

On 2012-01-30 22:03:46 +0000, Gregory J. Ward said:

If you could export one .OBJ file with NURBS representations, then the same object as an expanded triangle mesh (with normals, preferably), that would be sufficient.

I don't see much point in supporting 3ds or Maya, as those data formats tend to change with new releases. Not good from a software support standpoint....

Cheers,
-Greg

···

From: "Randolph M. Fritz" <[email protected]>
Date: January 30, 2012 9:41:57 PM EST

On 2012-01-30 22:03:46 +0000, Gregory J. Ward said:

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.

Oh, I see.

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.

Yes, McNeil's Rhinoceros does for export--I can send you some samples if you'd like. Let me know what shapes to export. I can also ask some of the media people I know if 3ds max and Maya do.

Randolph

Did anyone ever think about linking to the opencascade libraries? Not
only they support a wide range of file formats (including high-level
ones such as step) - they also provide meshing routines. Just a thought.

Cheers, Lars.

In short, Open CASCADE Technology Public License is LGPL-like with certain
differences.... that sounds fugly.

···

On 02/01/2012 09:36 PM, Lars O. Grobe wrote:

Did anyone ever think about linking to the opencascade libraries? Not
only they support a wide range of file formats (including high-level
ones such as step) - they also provide meshing routines. Just a thought.

--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F