what about STL, VRML or IGES?
You may need to look at a helper application such as Modo or Rhino. Import into those applications and export out what Lightwave can import and vice versa.
Using the data between the two systems may not be fun. There are fundamental differences in the types of modelers Lightwave and SolidWorks are. Lightwave being polygonal/sub division and SolidWorks being NURBS.
Going from Lightwave/3dsMax/Maya/any-mesh-format, I am asked this question 3+ or more times per day for the last 17 years. As noted above, Lightwave is just a simple mesh modeller and has no relation to BREP solids modelling of SolidWorks. You can't press a button to convert from a mesh-based program into SolidWorks. At most, you can import a VRML2 file into SolidWorks as a "proxy graphic" but SolidWorks will often begin to slow down after a few thousand polygons. Also, you will not be able to edit the imported model. If you want to find out how to do reverse engineering of a mesh model to a proper BREP solids model, and not use the reverse engineering module of SolidWorks, then email me (firstname.lastname@example.org) and I'll send you my common list of third party programs (but all cost more than SW itself, $5k to $25k, such as Rapidform and Raindrop Geomagic).
As for going from SolidWorks to Lightwave, every second conversion sale we make for the last 17 years is related to SolidWorks. We pioneered both native Lightwave conversion by 1993 and SolidWorks by 1996, so our CAD to non-CAD software will do a proper and complete conversion, always error free to all. DXF output from SolidWorks has always been 2D since 1996, so it's a common question I hear.
You can use VRML or STL export from SolidWorks and convert it through Meshlab (free) to OBJ or DXF. Unfortunately any textures or materials you have applied in SolidWorks probably will not transfer by VRML. STL of course has no support for bitmap textures.
The quality of triangulated meshes out of SolidWorks can be somewhat of an issue. Some rendering applications may produce rendering artifacts with long spikey triangles, and there does not seem to be good control of this in the STL or VRML output from SolidWorks. I have broken up models into multiple section to prevent the spikey triangles, but this could be time consuming depending on the complexity of your model.
Ar Robert suggests, you may get better quality meshes by using Polytrans to convert a nurbs model. I think there is an optional SolidWorks translator available.
Please excuse this longer posting but I did want to make others aware of common topics that I write about hourly. I get 30-50 emails a day relating to CAD to non-CAD conversion, with 80% always relating to SolidWorks and ProE (those two programs completely dominate the mid-level MCAD markets).
> You can use VRML or STL export from SolidWorks and convert it through Meshlab (free) to OBJ or DXF.
Having read forums for 30 years now I've always kept away from making any postings because the average forum reader is generally looking to trade information to find free solutions. I would consider myself one of those forum readers when looking for quick and simple solutions, but for my company work I buy professional tools (compilers, editors, server software, etc.) when "time is money", or if I need reliable tools which will speed my work. That's where our conversion software comes into use. People can spend hours looking for free solutions and using university programs like MeshLab, or do it properly. I openly understand and respect all of those looking for free solutions.
With a proper SolidWorks conversion you would get a lot more happening than with MeshLab. The conversion proess we developed hooks up a direct copy of SolidWorks (or without a local copy of SW available) to convert the proper assembly, including the configurations, master/object instancing (very important and overlooked by those who don't do conversions), materials + material processing attribute matching, meta data and mesh density control. All of this would map over 1:1 into Lightwave. You just convert and start rendering. But the absolute #1 most important aspect of the conversion process, that is little appreciated or understood by non-Okino users is our hierarchy and scene optimizer - BREP solids models, from ProE/SolidWorks/etc are glutted with a lot of body/shell/face nodes, and 10x too many data nodes, so this optimizer reduces the scene complexity by 10x to 20x on average, making for efficient LW renders. Lightwave will always slow down to a crawl if you start getting more than a few thousands parts in a scene (an open issue with Newtek from me), and this was one guiding force to having started this optimizer a long time ago. So in other words, our conversions are not simple polygon to polygon operations which we could write in 2 days.
> Unfortunately any textures or materials you have applied in SolidWorks probably will not transfer by VRML. STL of course has no support for bitmap textures.
As little known, the official policy of SolidWorks Corp is not to allow any texture mapping data out of the software. We have been developing at the API/core level since 1995 and have no direct and proper access to the texture mapping data, even though our code is fully set up to do so. The U3D exporter (up to SW 2009) temporarily had texture mapping export from SolidWorks, but then someone turned that into a SW -> HSF -> U3D tripled converter, losing the texture mapping data.
> The quality of triangulated meshes out of SolidWorks can be somewhat of an issue. Some rendering applications may produce rendering artifacts with long spikey triangles
The second sentence is a common world-wide misconception that I've been trying to stamp out for decades. This is generally due to lack of historical understanding about the common 3d apps on the market. Almost all top programs (from LW to 3ds Max to Maya, etc). were written around 1985 when 'smoothing groups' were all the rage. None of these companies properly wrote their software and did not understand how to deal with proper vertex normals (only Alias started off properly with vertex normals). So, to this very day, the top animation programs are still dogged by using smoothing groups (3ds Max, LW, Maya, Cinema-4D, Softimage, etc). Smoothing groups are a 'guessed' approximation to the accurate vertex normals needed when importing CAD data. If you do the conversion properly, such as using our software (and again, not forcing this option on anyone), the proper vertex normals will always flow through to the final application. In Lightwave, proper vertex normals were only added in LW 9.6 (an extension developed by MODO, and implemented in few or no converters). I'll keep this short by saying that there's back-ended methods to getting the proper vertex normals into these aforementioned 3D animation programs, and others as well - but one must never do a SolidWorks to non-CAD conversion blindly, as that will just lead to shading anomalies and black banding.
>I have broken up models into multiple section to prevent the spikey triangles
Technically, you are correct that all CAD programs tend to output "sliver triangles", as I call them. But as I live/eat/breathe translation, such small or sliver triangles are never an issue if you can properly bring in the original CAD vertex normals to a destination program (which I can do for all 3D apps). The black banding or shading problems occur due to the use of smoothing groups, as smoothing groups drop the original vertex normals and replace them with 'guesstimates'. That will often rear its ugly head, for example, on topology similar to a "kitchen table", whereby you'll have a nice chamfer on the outer edge, and a hole in the center of the table for an umbrella - smoothing groups just can't represent such topology and lead to perceived shading problems.
And just for general information, there are alternatives to meshing from SolidWorks. 50% of my customers go with native SW import and the other 50% I educate + 'force' IGES solids on them. The one and only CAD exporter which works without error is IGES solids from SolidWorks - it outputs master/instancing, part names, part hierarchy and materials, while the other exporters each have some problems. Using IGES solids, our BREP solids importers allow the triangle aspect ratio to be set. But just to set the perspective, I only get two people a decade who are concerned about the aspect ratio of the final polygons as that really doesn't affect most people. I find that only zBrush people are (rightfully so) concerned about getting quad-like polygons into their software, as squarish polygons are more suitable to the zBrush work flow.
User control of triangle aspect ratio on export from SolidWorks would go a long way towards improving the quality/useability of the triangulated mesh output.
>User control of triangle aspect ratio on export from SolidWorks would go a long way towards improving the quality/useability of the triangulated mesh output.
Generally speaking, all of the BREP solids tessellation engines got written during the late 80's and early 90's, such as for SolidWorks, and haven't changed much or at all to date. Software companies don't like to change what isn't considered broken, but more often is the case that the original software developer has gone on to do bigger and better things in life. I'd personally like to see more control over the tessellation output of SolidWorks rather than just one chordal distance value. For example, my core ProE system has 5 user definable controls over surface tolerance, curve tolerance (holes), fillet sub-control, and U/V space subdivision to help control the "square-ness" of the resulting triangles. As my previous posting above alludes to, once the core aspect of a 3D program is written, it is rarely touched for decades thereafter because much of the original development team is no longer available or has any further interest to touch old + stable core functionality.
I believe one of the reasons they dont provide quality polys and UV out is to obstruct the use of renderers other than their own or their partners.
The collada plugin from SWlabs they made for MS Robotics Studio did export textures and although thats broken now it does show its possible.
Stl gives a nicer mesh than vrml however vrml is a handier format I think for downstream use. As you note though vrml often yields pretty substandard tesselation and it isnt easy to doctor up after the fact particularly on non planar surfaces.
Once again there probably isnt a willingness to improve it for stategic reasons especially when they have Modo lined up for stuff. Basically they would rather you spent another $1000 on that than fix/improve vrml. Unfortunately its just part of an unhelpful mindset SW have these days but we wont go there in this thread...we leave it for SW historians
I too at one time had to deal with this issue big time while I was working for IDEO. In fact the "Kill another CAD" video was accomplished using Lightwave from imported SW models back in 2002.
I have since made the move over to Modo - mainly because of our partnership with Luxology and ongoing partner products with them. I would suggest you listen to Brad's modcast for some partner products they will announce at SWW athat you might be very interested in.
When I was on LW, I used Rhino to go from SW to LW, but honestly I spent many hours repairing my models from SW especially the Aston Martin Vanquish.
So Modo could be used as an alternative to Tsplines.....