Regarding Michaels suggestion to rather use OBJ formats to transfer 3D data as long as the render system does not have a very good NURBS mesher, I remembered the talks we had about improving Blenders vertex normal handeling.
Here is a screenshot from Rhino internal - all butter smooth no artifacts between NURBS and mesh object.
To get the same result I needed to remove few triangle faces and turn them into quads on the cylinders and also paint some hard edges along where the cylinders hit the sphere to make sure that the Split Edge modifier works the same way.
On this small model it was not a big issue but I had other models where the smoothing in Rhino was perfect but in Blender it literally destroyed the smoothness and thus made polished surfaces look more like hammered.
Sergey is rather strung up by the tracker workd for mango. I heard another name was mentioned when it came to nurbs dev on blender?
cekuhnen do you know how libraries like openCascade work? Solid modeling principles rely on nurbs or meshes?
boy you ask me something above my head regarding the libraries.
Solid modeling or surface modelers are nurbs based because tools like trim etc calculate the surface intersections.
Rhino as a surface modeler can close an object and than use a specific edge rounding tool, if you work with two surfaces you use a surface edge rounding tool.
I am not sure if the math is really that different - but I think the difference is more in the methodology in how you approach geometry generation.
In Rhino as a surface modeler offseting a complex object is a pain because Rhino offsets all the individual surfaces.
In a solid program it offsets rather the more basic shape of the object and then reapplies the features like edge rounding.
Solid Modeling kernels use NURBS as their basis. OpenCASCADE is not compatible with blenders license. It’s pretty much the only “free” kernel and it sort of sucks.
@cekuhnen - sorry about that but you seem to be one who knows of nurbs (or lack thereof) in blender
I use Rhino myself and although a very nice program in many respects it can become cumbersome to render in it so I have the same wish for a decent bridge between Rhino and blender.
I have always enjoyed the Operation on Operation workflow of CAD programs though I tend to think grasshopper is one way to go about that problem in Rhino.
then again @Zalamander - you speak of openCascade as if you know a bit of its inner workings. In that respect have you had a look at the nurbs code of blender (new or old)? Is it a good foundation for more work on it or (In your words) does it suck as well?
I ask because I would like to choose a good example of how nurbs are put into practice when it comes to code and 3d.
That would be an overstatement. While I did go through the trouble of downloading the code and looking at the examples I didn’t really do anything with it. When I say “it sort of sucks” I’m not referring to the code but to the quality of some of the operations that are notorious to fail or create good geometry (in any CAD program) by looking at some of the existing tools that use the OCC kernel (FreeCAD, NaroCAD)
Solid modeling kernels are a big deal. While there many many CAD programs out there, there are only very few kernels that are sublicensed (for a lot of money) or re-used for those programs.
In that respect have you had a look at the nurbs code of blender (new or old)? Is it a good foundation for more work on it or (In your words) does it suck as well?
I ask because I would like to choose a good example of how nurbs are put into practice when it comes to code and 3d.
I have not looked at blenders nurbs (which are very simplistic) or libNurbana etc, but those are different things than solid modeling kernels. While the foundation for solid modeling requires NURBS, it does much more to maintain the “solid” aspect of the model. Compare the way Rhino (a surface modeler) works with a solid modeler like 123D (I’m using 123D as an example because it is accessible, feel free to replace it with “SolidWorks” or “CATIA”). A surface modeler is simpler to develop and different to use.
@zalamander - hmmm I think i get it. It fits though as I am more interested int working with surfaces than volumes. My main interest though is the math of trimming and projecting an arbitrary nurbs curve onto a nurbs surface and get the resulting curve.
Do you know if in the industry standard programs like rhino you get an exact mathematical repressentation of the resulting curve or an approximation?
Sorry I keep asking but it is such an interesting area of math.
Do you know if in the industry standard programs like rhino you get an exact mathematical repressentation of the resulting curve or an approximation?
If by projection you mean the intersection of the surface swept out from the profile you want to project onto the surface you want to trim, then yes, that is approximated (and that is a problem indeed, your meshes aren’t perfectly watertight)
while NURBS is math based and you cannot see it or visually represent it you can define a tolerance value that is then applied to all modeling calculations.
The polygon mesh you see in Rhino for example is only a rough tessellation of the NURBS surface so you can preview your model.
Also there you can define how precisely the mesh has / should fit the NURBS surface.
You can raytrace NURBS directly instead of tesselating them.
Also there you can define how precisely the mesh has / should fit the NURBS surface.
Even at the NURBS level the curves at the trims do not fit each other precisely and no amount of tesselation can avoid cracks at a given magnification completely.
for rendering system like Renderman can render NURBS while on the fly tessellating it. However for realtime shading in the 3D view port you need a wiremesh for openGL.
I am not sure if I can follow you explanation that NURBS is not precise and water tight and also can mesh watertight models.
That is exactly what I thought after a few attempts on projecting an arbitrary curve on to a “blob” (well… as you more precisely put it: the intersection between the profile of the curve on to a “blob” surface).
I sought after nurbs for their precise definition. I thought Rhino had a way of defining the curve of an intersection but in this new light it seems in most cases (other that very simple setups ie. of planar or circular surfaces) impossible to make other that a close approximation. A little bit disappointing.
Interesting discussion. I think it is definitely possible to get the exact mathematical representation (equation) for any curve from a NURBS package. You can then use this in whatever calculations you want, eg export it to matlab. The problem is as soon as you want to display it you have to introduce some kind of error. But even with the “strictly mathematical” part you have to stop at some decimal point.
You can influence the precision based on the scale of the object and thus time needed for doing the calculations but I hardly think one can see this as an approximation. Otherwise all CAD surfaces could not be water tight when you cannot calculate the surface intersections. The question is only to what point is the intersection hitting the real spot but what comes out is a real intersection never the less.
Position. Rhino, like most CAD products, represents position in double-precision floating-point numbers. That means the x, y, or z coordinate of any point can have a value ranging from as large as ±10308 to as small as ±10-308. Most CAD software, including Rhino, uses double-precision floating-point arithmetic.
Because of the limitation of current computer technology, we expect calculations to be accurate to 15 digits of precision in a range from ±1020 to ±10-20. This limitation is found in all modern CAD products.
Intersections. In Rhino, when two free-form surfaces are intersected, the resulting intersection curve is calculated to the accuracy specified by the user. The Rhino default accuracy (tolerance) is 1/100 millimeter. Many CAD systems have built in tolerances that the user cannot override.
If you carefully examine the geometry other modelers produce from free-form surface intersections, free-form fillet creation, and free-form surface offsets, you will discover that this free-form geometry is actually calculated with accuracy between 10-2 and 10-4 meters even though they advertise precision of 10-8 (without mentioning that the units are meters)
for rendering system like Renderman can render NURBS while on the fly tessellating it. However for realtime shading in the 3D view port you need a wiremesh for openGL.
Renderman is not a raytracer, so it requires a tesselated curve. The intersection of a ray and a NURBS patch can be analytically determined, therefore we can raytrace them without tesselation. This can also be done in realtime these days, although common design tools do not do that.
Otherwise all CAD surfaces could not be water tight when you cannot calculate the surface intersections
As far as I know, no CAD software produces truly watertight surfaces with trimmed NURBS. It’s not merely a floating-point precision issue but a practical impossibility. That is, the curves used for trimming (splines of reasonable degree) can only approximate the true intersection. P.S.: I don’t want to give off the impression that I have a deeper understanding of the math behind it, but this is a common practical problem in CAD/CAM that I happen to be aware of.
this weekend i could give a try at Salome, which as far as i know, is purely a Fem software. well, it did a better job than Moi meshing a complex shaped object (a sink). the quadrangulation algorithm recreates rounded surfaces and connects them really good. too bad it fails at generating flat surfaces. anyway, a long way better than opencascade software (freecad and some other) which seems to fill everything with “random” triangles
Zalamander you missed my point here. Rhino generates a polygon render mesh which it uses for openGL preview as well as rendering.
Renderman on the fly tessellates the NURBS surfaces - you do not deal by hand with setting tessellation values to get smooth surfaces or prevent cracks/naked edges. With REYES a polygon is smaller than the screen pixel. If that would be tessellated before rendering, you would need a computer that could handle that type of amount of data.
This is why also displacements with REYES are so fine and incredible fast - it is done on the fly working with the NURBS raw input data.
Don’t we get lost here in philosophical details? To what degree do we need the calculation to be 100% correct? Of course use computers a simplified algorithm to tackle this issue - but does the resulting surface look that much like a bad approximation?
From my experience the issue with watertight meshes / naked edges stems either from bad modeling habits and the quality of the algorithm being used by the CAD software. Rhino vs SolidWorks is a great example here.
@Zalamander - thanks for the link. Il have a look as well to be sure. @cekuhnen - either way your point is valid in both cases. My interest in Nurbs are triggered by the precise math behind it, but I have (especially now) realized that maybe it is better to use a method which produces arbitrary surface forms with more control over the underlying topology. Ie Bsurfaces addon.
As a designer as well I would like full control from start to finish. From smooth paper sketches to smooth marker drawings to smooth computer topo flow to smooth product. The important link being the two last where I need to model with nice topology and the other where I want to use the topology as basis for the assemblage of the product.
Either Nurbs or polygons can work as long as there are some good tools to work them with.
