tom kyler_dup1

Biplap, one features that comes to mind is "offset surface" or "extrude suface"...like a curved nurb surface extruding in the normal direction at each point on the surface

Offset surface would be a great feature. [ 06-10-2004, 11:19 AM: Message edited by: tom kyler ]

Let's say I've created a shape comprised of multiple nurbs surfaces, including some surface fillets. And then I convert the whole thing to a solid through a series of steps. When I export this Nurbs Solid Object (2-sided surface)...composed of several nurbs surfaces "stitched" into a solid (as indicatd by the OIP) and export via *.SAT format, I get seperate surfaces when I import this object into my application (Electric Image Modeler in this case.) The nurbs surfaces come in to the application beautifully, it's just that instead of having one object (like a chair seat in this case) I have a seat made up of many nurbs surfaces. The problem this creates is that when I try to begin texturing the object, I have to create textures for the multiple surfaces which is very cumbersome. Instead of having one object to texture, I have 13 surfaces. Now I know there's an export option when exporting SAT that says "export solid as trimmed surfaces" ....now when this box is unchecked, I would expect my "solid" to be imported into Electric Image as one piece but it seems that my solid has become "trimmed surfaces" I don't have this issue when importing ACIS/SAT from some other programs so I don't believe it's an issue with Electric Image, but rather a *.SAT export issue with Vectorworks...somehow, the export from VW is not maintaining continuity/connectivity between the surfaces. Soooo.....my question is this: Is this "seperation" of nurbs surfaces normal during *.SAT export or is there anything I can do (object status wise) to get these nurbs object to be one surface during export? [ 06-10-2004, 11:15 AM: Message edited by: tom kyler ]

Let's say I've created a shape comprised of multiple nurbs surfaces, including some surface fillets. And then I convert the whole thing to a solid through a series of steps. When I export this Nurbs Solid Object (2-sided surface)...composed of several nurbs surfaces "stitched" into a solid (as indicatd by the OIP) and export via *.SAT format, I get seperate surfaces when I import this object into my application (Electric Image Modeler in this case.) The nurbs surfaces come in to the application beautifully, it's just that instead of having one object (like a chair seat in this case) I have a seat made up of many nurbs surfaces. The problem this creates is that when I try to begin texturing the object, I have to create textures for the multiple surfaces which is very cumbersome. Instead of having one object to texture, I have 13 surfaces. Now I know there's an export option when exporting SAT that says "export solid as trimmed surfaces" ....now when this box is unchecked, I would expect my "solid" to be imported into Electric Image as one piece but it seems that my solid has become "trimmed surfaces" I don't have this issue when importing ACIS/SAT from some other programs so I don't believe it's an issue with Electric Image, but rather a *.SAT export issue with Vectorworks...somehow, the export from VW is not maintaining continuity/connectivity between the surfaces. Soooo.....my question is this: Is this "seperation" of nurbs surfaces normal during *.SAT export or is there anything I can do (object status wise) to get these nurbs object to be one surface during export? [ 06-10-2004, 11:15 AM: Message edited by: tom kyler ]

Raymond, I see your point about VW showing "virtual" points when re-shaping the curve. It's been a real long time since I've developed curves by hand and I'm not 100% sure the purpose behind those virtual points. I suspect those are probably the non-zero boundary points that you need to calcualte. I might be wrong, so I'll look into it a bit and maybe two heads will come up with something. Tom K [ 06-08-2004, 07:58 AM: Message edited by: tom kyler ]

bohlr, sounds like you might have never used the "extrude along path" command, so I'll include a little more information you mightneed in addition to propstuff's suggestion. You don't have to use the nurbs curve tools to define a path, you can use a regular arc or a polyline. Either way, you need to have both your path and profile selected before you can use the "Extrude along path" command. Normally, the path you draw will represent the edge of a window...a jamb maybe. When you extrude along path however, the profile is extruded along the path about the center of the profile. This is never the way it needs to be though. You can double click on your new 3D extrusion and edit either the path or the profile. If you select the "profile" you can reposition your profile relative to the path...usually by moving a corner of your profile to the center locus of the editing screen. If you play around with "editing" the extrusion, you'll figure it out quickly I'm sure.

Raymond, I would suggest doing some searches on "cubic splines" which are a series of of third-order polynomials where each point is a cubic vertex. Your particular problem is going to be developing boundary conditions on either sides of adjacent cubic verticies. Most of the mathematical developments of cubic splines develop "natural" splines by setting their boundary conditions to zero (very general description), you'll have to have non-zero boundary conditions when combining verticies of different types. Try this as a real general start: http://mathworld.wolfram.com/CubicSpline.htm Click on the first search result, it discusses the math behind cubic splines and should get you going in the right direction And maybe take a look as this technical paper in PDF www.library.cornell.edu/nr/bookfpdf/f3-3.pdf You can also use the terms "numerical methods" to help you in your online search. [ 06-07-2004, 05:53 PM: Message edited by: tom kyler ]

Shadi, you might try going to your Vectorworks preferences and go to the "3D" tab. There you can set your 3D conversion res to "very high" and then re-render your model. Another thing you might try is to to: VIEW>RENDERING>OPENGL options, set the detail to "HIGH" and check the "Use NURBS" box. Then when you render with opengl, you'll usually get a finer mesh. Biplab is correct. I wouldn't call is a display problem as much as a display preference. A nurbs surface can be displayed at many levels of detail...and is referred to as "tesselation" and depending on the CAM software you use, it just might cause a problem. If your CAM software doesn't support nurbs or import nurbs or *.SAT format and you have to export from Vectorworks with IGES, then the 3D conversion setting on Vectorworks might dictate how "smooth" your model is when you take it into you CAM software. At least that's my current understanding. Does any of that sound right Biplab?

in VW11, when i use the text tool, I am unable to paste data into the text field using keyboard shortcuts. I use VW 11, and VW 10.5 and I can have both programs open and successfully paste into 10.5, but click over VW11 and try and paste and nothing. Using "copy" and "paste" in the edit menu works fine, so it appears to be a keyboard shortcut issue. Anybody else confirm this issue? It's happening on all versions of VW11 in our office (3 machines) [ 05-13-2004, 10:15 AM: Message edited by: tom kyler ]

I know that lightworks, which licenses it's rendering routines to vectorworks and form-Z comes with different levels of rendering routines. I might guess that even though Rhino and VW uses the same kernel, it could be that Vectorworks doesn't license the complete set of modeling routines that Rhino does. Since VW incorporates so much more functionality though, that would explain it's higher price currently. Also, each developer is responsible for programming it's own "front-end" for the modeling routines. I would hope that VW is incorporating more of the features from SMlib in the future. I know Rhino has some NURBS tools I would love to have in VW. Time will tell.

Ron, you probably won't like this answer. If you begin with a solid, and then use the "cut 3D section" you'll end up with a "group" of 3D polygons with an open side where you cut. You have to "ungroup", then "add solids", then "convert to nurbs", then "ungroup" again, then "add solids" again, then "create planar caps" and finally "add solids" a last time. and that will turn your hollow model into a solid and cover up that open side, at least for most geometry Fun huh? This has to do with the way Vectorworks keeps track of an objects creation history. By ungrouping and using the "add solids" command, you essentially loose some ability to go back and change parameters you used to create your part initially. But since the "3D section" creates a copy of the section, then this isn't usually a problem. If you use the "cut line" you'll cut your model, but will still be able to go back and edit it. If you go this route, then you won't be able to cut multiple sections without making copies of your model. The mathematical model a computer uses to classify something as a solid, nurbs surface, or polygon is different, and each time you do that "ungroup" and "add solids" you're essentially converting your model from one type to another finally getting to a type (nurbs in this case) where you have the ability to cover up that "hole" (with the "add planar caps" command). It's a "by-product" of the method Vectorworks chooses for their design process and still be economically viable. [ 05-06-2004, 10:39 AM: Message edited by: tom kyler ]

Bolldo, Charlene is right, VW11 has *.SAT export and it does work nice, I've exported a few parts for CNC already; however, check your CAM software, many packages will import IGES and can construct nurbs (smooth) machinable surfaces from IGES files that aren't "faceted" or made from flat triangles. I haven't had good luck with IGES export from Vectorworks though. If you can afford the upgrade to VW11, the SAT export works great and will solve a lot of headaches and time (worth the upgrade price alone). But if you're just doing a few parts, the evalation of Rhino 3D mentioned above is a great choice. File translation through multiple programs is risky in my CNC experience, but SAT has always been reliable for me. [ 05-05-2004, 12:26 PM: Message edited by: tom kyler ]

Thanks Katie, looks like I got it about the same time. As a clarification, whatever is put into the "annotations" section of a viewport has fixed visibility and can't be turned on or off using classes, am I correct in that assumption?

Ok, I've come across the "advanced properties" button on the object info palette that lets me adjust text scale from design layers. This would still require calculations for different scales though, not a big problem, but a "concession" to using viewports I'm guessing. Annotation strategies using viewports is still welcome though.

BaRa, since your essentially exporting polygons, you could export STL from vectorworks...there is a tesslation setting there. I've imported stuff into form_Z this way with reasonable success. I see a lot of confusion regarding form_Z, Rhino,and VW. Here's my 1 cent. Personally, I use all 3. Vectorworks primarily for drawing creation (it's a CAD program), but am using it more for 3D as the 3D power pack develops. Rhino I use for organic modeling (ps. it is a nurbs surface modeler, but mathematically, a solid is a volume enclosed by surfaces, so Rhino can export SAT solids all day long). VW can't touch Rhino nurbs at this point. Form_Z is a little complicated to learn at first, but once you learn it's tool set, it is really a powerful modeler. Vectorworks is the tool of choice if you have to produce drawings. If you're doing 3D visualization and producing renderings, then Rhino or Form_Z, and if you're doing visualization on a Mac, then form_Z is the 3D modeler with the best tools (at this point). I'd have to disagree with BaRa about form_Z nurbs tools though, they work great for me. Check out the respective galleries for form_Z and Vectorworks to get an idea of what's getting modeled on each platform. [ 05-05-2004, 01:26 PM: Message edited by: tom kyler ]

I've just started playing with viewports in VW11. Having used AutoCAD, I'm familiar with the sheet layer/paper space idea, but believe the saved sheets setup in VW is a superior method of controlling print layout. It seems that Nemetschek's incorporation of viewports is a strategy to convert AutoCAD users, and a good one I might add, but it seems that "save sheets" and viewports overlap a bit in their functionality causing some confusion to me as to the best drawing setup (for architectural anyway). So the real question here is what is the best way to set up a drawing for dimensioning, particulary to deal with consistent font sizes. Putting dimensions in design layers that are full scale results in small fonts in reduced scale sheet layers. Not only that, switching from a sheet layer at say 1/4" scale back to a full scale design layer means having to zoom out and in a lot. Putting dimensions in sheet layer annotations won't let me custom select dimensions if I want to change the dimension font sizes (a big issue if I have 100 dimensions) . My biggest annoyance with AutoCAD was dealing with dimension scale and font sizes when dealing in paper space. If I decide to put multiple viewports at different scales on the same printed sheet, as I understand it, I'd have to calculate the font sizes if I wanted all dimension fonts on the sheet to be the same size (assume dimensions were on design layers), a huge turn-off with AutoCAD. It seems the only way to get consistent font sizes (for dimensions) in different scale viewports is to put them in the "annotations" section of the viewport. But if I do that, I can't turn them off in the viewport by turning off the dimensions class, nor can I select them globally as mentioned above. An input as to an organizational strategy would be welcome.

DOH! Thanks! That's happened to me before....Maybe I'll learn my lesson this time.

I have a script as follows that will not compile: PROCEDURE Scale; VAR xfactor: REAL; BEGIN xfactor:=realdialog('Scale Factor = ','1'); scale(xfactor,xfactor); END; run(scale); The error message given is as follows: Line #8: scale(xfactor,xfactor); | { Error: Did not expect this after end of statement - missing ;? } When line #8 is the only line in the script, it complies successfully. Somehow, having the scale function in the body of the script causes it to not compile. Also, if I use the scale function with no arguments (i.e. Scale; ) then that will compile successfully. If I substitute any procedure in place of the scale function, the script will compile successfully. Any input???

could you please post a screenshot of what you're talking about, I don't understand your description.

I have a script that makes a custom selection and I would like to automatically zoom to the selected objects...just like the "fit to objects", but can find no function or procedure for that. Any ideas on how to use the "Zoom" class of procedures to accomplish the feat. I figure I could probably calculate the view based on the bounding boxes of the selected objects as well as the zoom factor, but am looking for an easier solution first.