SketchUp is not a NURBS modeler because...
-
this may or may not help but an example of something that's possible with rhino but isn't with sketchup is this drawing..
here's a surface that would be possible to mimic in sketchup (just a revolved spline) notice how it's mellower towards the bottom and tightening up as it nears the top..
but, in rhino, since that surface is mathematically defined and not just a collection of vertices that aren't aware of one another (my simplistic definition of a polygon surface
), i can extend that surface very easily and you'll see that it continues tightening as the existing surface was doing.
-
and the funny of the thing is at least in final on your screen Su or Rhino are bother "triangles" from the graphic card for be possible to visible render
(in my simplistic definition) -
Interesting... just last night I was revisiting my BezierPatch plugin I experimented on about a year ago...
-
It seems that every ruby extension created for Sketchup is analogous to features native to other modeling apps. That is simply because the needs are the same in Sketchup.
-
@mitcorb said:
It seems that every ruby extension created for Sketchup is analogous to features native to other modeling apps. That is simply because the needs are the same in Sketchup.
hm...
One do not always need NURBS. Some times you do, some times you don't.
Nor do one always need every feature any other modelling application has.
If it had - then we'd have a big bloating beast.But - SketchUp has a platform where you can make it fit your own specialised needs.
-
@ThomThom:
Yes. You are right about the beast. As we know the SU developers wanted to keep the app compact. -
@unknownuser said:
and the funny of the thing is at least in final on your screen Su or Rhino are bother "triangles" from the graphic card for be possible to visible render
(in my simplistic definition)yeah, in nurbs modelers we only see a representation of the surface via a render mesh and it's not accurate (well, it's 100% accurate if you take measurements from it or export to cnc production etc..). i think it's impossible to show a true nurbs surface on our current monitor technologies in the same way we can't truly see a circle on our screens.. (a bunch of square pixels can't display a true curve)
here's a closeup view of a rhino surface.. the wires are what you have to pay attention to and trust them but the surfaces will often to appear segmented (well, because they are meshes just like in SU)
the one thing i don't really like about rhino is their nurbs to mesh technique and i don't think they're nearly as clean as they could be.. i hear moi is much better at this.. hopefully, rhino v5 (which will also be the 1st official iRhino release) will change this.
-
yes in Moi you can regulate for have a "perfect fit" of the curve on the surfaces
But it's only for the screen and that can slowdown all if you have a very big file!
It's just for pleasure of the eyes
But for normal file size that is very cool
-
I've worked a lot with Nurbs in Maya and they are good for some things and polygons are better for some.
What is needed if ever someone makes a nurbs/spline patch ruby is that it keeps the editing capabilities all the time. Meaning it makes it possible to change the "subdivision" to polys even after editing and just crank it up when its time to render. -
@unknownuser said:
yeah, in nurbs modelers we only see a representation of the surface via a render mesh and it's not accurate (well, it's 100% accurate if you take measurements from it or export to cnc production etc..). i think it's impossible to show a true nurbs surface on our current monitor technologies in the same way we can't truly see a circle on our screens.. (a bunch of square pixels can't display a true curve)
mhm.. NURBS modellers will have to refine the mesh to the point where a edge segment is <= 1px
-
@pixero said:
I've worked a lot with Nurbs in Maya and they are good for some things and polygons are better for some.
What is needed if ever someone makes a nurbs/spline patch ruby is that it keeps the editing capabilities all the time. Meaning it makes it possible to change the "subdivision" to polys even after editing and just crank it up when its time to render.Something like this:
-
Wow... a picture really is worth a thousand words. I can't wait to try that plugin
Best,
Jason. -
In these moments Scripts' conceptors are out burst!
Users can't follow the flux
-
And the plus side of these patches are that they are easy to UV map.
-
UV mapping
Please go on 
-
Patches generate regular geometry which is much easier to map as you know the full structure of the mesh.
-
-
Bezier patch.
I was thinking that if you could assemble a Bezier surface of Quad and Tri patches you can shape most things.
Currently it has the 16 control points, but I kind of want a simpler one, with just the corner control points with handles. But I guess there can be use for both... -
3D Nurbs are possible in SU in theory, but requires to interface the script with a C library in order to get decent performance for preview and edition. That's of course possible, but a long work, especially for merging two nurbs surfaces.
Indeed, it would help if the SU team would fix the bug which prevents surfaces to be drawn in any other color than gray or black (as you can see in Curviloft).
Note that Nurbs would not always answer the problems of the real world when you wish to have given contours, with strict dimensions. Most 3D modelers use numerous techniques to manage this, not just Nurbs.
I may one day do something with Nurbs, but I am also exploring alternate techniques that may give acceptable results in some frequent situations. For instance, I am playing with surface generation from contours (not necessary horizontal), as shown on the picture below. This is not based on Nurbs, but I think it will give a more realistic shape when modelling a terrain.
Fredo
-
@unknownuser said:
3D Nurbs are possible in SU in theory, but requires to interface the script with a C library in order to get decent performance for preview and edition.
You mean deforming it live? Is the calculation that expensive? If it's just applying the transforming that consumes time I don't think moving to C will do much.
For Vertex Tools I wrote the soft selection code in C. What I found took a lot of time was casting the Ruby values to C data types - so much in face that doing a prepass of converting the whole 3d point data set first before processing it gained a great amount of speed.
I'm currently working on a Bezier Surface system where you add quad and tri patches together. At the moment it all in experimental stage - but as it matures I might port some of it to C if I find a lot of the calculation to be very consuming. Though often I find the bottleneck to be SU's methods of adding geometry.
And I'm also trying to get to grips with B-Splines - I've never worked much with them. But when I read about Bezier curves I often see them mentioned - that they can be more intuitive to control?
Advertisement