View Full Version : 3D printing problem...overlaps

05-02-2014, 02:59 PM
I posted about this once a while back, and was hoping it would get fixed. I just installed LW 11.6.2 and ran a very simple test on overlapping objects.

The problem is that wherever two objects overlap, it creates a void.

I've been able to model, but it takes a lot of time to either extrude faces, or align faces perfectly. I've tried Retopoing the objects with programs like MeshMixer, but the files are huge, not as defined and not easy to edit.

Plus, when I want to use a model I've previously built in my archive (I've been using LW for 10 years) I almost always have to start from scratch because of all the overlaps.

Below is an example of the problem. This is two cubes with a slight overlap done in LW Modeler. Then I use Simplify 3D as my slicer software. After that is the print from my Duplicator 4.

It doesn't matter which slicer I use, RepG, Makerware...etc. The import looks fine, but it prints with a void.

Other than that, I love working with Lightwave for creating 3D models.


05-02-2014, 03:29 PM

Did you tried boolean operation in LWM so you actually fuse/weld two boxes in LW prior the export?

05-02-2014, 03:43 PM
Yep. You can't have overlapping geometry on a STL being sent to a printer. You have to get the concept that the slicer is working on. It needs to correctly identify that which is the Inside of a shape and that which is the Outside of a shape. Shapes must be "manifold", meaning water-tight. No holes that are not created by a surface. (You can have a hole but it must have walls.) With overlaps like this, you can readily see that it actually is working correctly, as far as deciding what is in and what is out. Why? Because, to one of the shapes, a portion of it is not part of it, so it truncates that portion; thinking that this is where the shape ends. To the other, the same is true. There is something here that is not connected to "me", so it must be outside of "me".

Put another way, the slicer goes along analyzing the shape by looking at its outside surfaces. It finds a wall that isn't connected to the walls that it knows about so far, so they must be "outside" this part. Then, it goes further and encounters other walls that are connected to the unexpected wall. Well, these must be "outside" too. It gets confused because it is being given conflicting information and decides that the two unexpected walls are actually "outside" as well and removes all that is bounded by them; creating the gap.

The only way to properly have a shape like this is to join the parts together with welded points; creating one outside surface. You can do it by Boolean or manually, as Bools sometimes get Borked if you are trying to join two parts of the same height, as in this case. IOW, this Bool would fail because the two shapes are the same height dimension. Bools work by cutting. You cannot cut a point. It is dimensionless. Therefore, you would increase the height of one of the shapes by a small amount, join the parts together, then weld adjacent points where the cut happened and bring the outer lying points not near the cut back to the dimension where they started before the increase was made. Then delete or weld any points that are in the interior to exterior points, in order to "remove" them entirely and retain the poly. Whew, complex description and I know it probably won't come across immediately. It would have been faster to have recorded a video. :)

05-02-2014, 04:06 PM
Lewis, yes, that's the first thing I tried. Boolean Union really never worked for me anyway.

Spherical, I completely understand what you are saying. But if you look at the 3D Printing tutorial Lightwave has, at 5 minutes they say that 'intersections should print' but they don't. So I'm considering it a bug. I do understand the work-arounds. I use them every day. This week I've been building the entire Ellis Island building and printing (floor by floor)...successfully. BUT it's taking me twice as long as it should because of this overlap thing.

So I thought I'm mention it to Lightwave as something they should try to resolve (since they said it would work) and not so much something I don't understand. But I do appreciate your input.

Bottom line is that if overlaps printed, huge archives of Lightwave Models could be 3D printable. Not just mine. That would be an advantage for LW as 3D printers become household items within the next 10 years.

And yes, they would have to be manifold first!

05-02-2014, 05:05 PM
Well, to be fair, it's not a limitation or bug in LightWave at all. That's the way things work in the slicing world. The modeler application has absolutely nothing to do with it. Further, their tutorial is wrong. Yes, you may be able to find a slicer that will happily slice the file as you intend it to be when it is constructed incorrectly, but that is due to the slicer not being smart enough to recognize that there is something wrong with the model. Additionally, if a slicer did allow an overlapped model to print, it would waste a lot of material. What's the point of having structure inside that a) has no purpose and b) cannot be seen? You may be able to say that this particular type of object should just be automatically produced the way that you intend but telling a program to make those decisions is another story entirely. Somewhere along the line, something will not be sliced/printed as the modeler intended because the slicer made the wrong assumption. It is up to you, the modeler, ensure that it does understand by making the model as clear as it can be. IOW, don't do that.

That said, there are slicers that handle multi-mesh models. However, even these should NOT overlap; they will just slice one section and apply one extruder to it and slice the other section and apply an alternate extruder to that. In this case, you can readily see that having the overlap retained would result in an extruder head crash, because the opposite extruder has already filled that path. This is one more example of why overlaps may be nice to think of, and a shortcut to get the model completed with less work, but do not work.

EDIT: Just looked at the Siggraph video. When taking ALL of the other concepts into account, where things won't print correctly, that should give you a clue. However, in the specific case that she shows an intersection, that may actually print because the intersected part is within the combined shape, so will be truncated anyway. Risky, at best. In your model, the intersection is inside the combined shape in two dimensions but not in the third; thereby exposing the truncated portion as a void.

05-02-2014, 05:51 PM
Yup, completely understand. BUT...if they COULD make overlapping objects print without voids...that would be a GOOD THING. Here's my Confederate Submarine the CSS Hunley. I had to build it from scratch even though I had already built it for an illustration previously. If it wasn't for the void thing, it would have been a walk in the park. Even building from scratch is a pain because of the intersection thing. I'm not saying it's not possible to build models because of it...obviously it's possible. Here's an example.

But if they could make the void thing go away, they could have a powerful tool in the 3D printing world.


Build for the Hunley


05-02-2014, 07:18 PM
You're still not getting it. The modeler has nothing to do with how the slicer understands the model that is created in it. LightWave doesn't slice the model. LigtWave doesn't send the sliced model to the printer.

There is nothing for LW3DG to fix. It's out of their purview.

All the "3D Printing Support" is, is a converter that writes STL files and offers to "fix" them if it finds something that a printer probably won't understand. I have found that it is always best to create the model correctly, whether I am going to 3D print or not. I usually don't use the STL exporter, as I have found that a dedicated format converter is more robust. I manually triangulate polys and save a version, because there re different tri methods that work better in some cases. The STL converter defaults to one type only.

In your example, there are partially coincident polys. This is why the slice fails. There is no automatic way to fix this type of situation. Entirely coincident is a different story. Unify Polys will take care of that if there are enough of one type for the function to decide what is out of whack. Usually, it fails, too.

I know this isn't the answer you wanted to hear but, the best way to consider this is to follow physics. Two objects cannot occupy the same space at the same time. In the 3D world it is possible. When moving from out of the 3D world into physical space, which is what 3D printing is doing, you'd best be observing science.

05-02-2014, 09:06 PM
Yup. I completely get it. Bottom line...I have to process my models through ANOTHER product...one made by AutoDesk to make my model printable. I don't want to.

I don't mean to be disrespectful, you obviously know your stuff. I'll give you an IQ of 140-150 and I'm only a 127. I'm just saying that they need to find a way to keep it tight, and keep it in-house. It is a problem. They can come up with the solution. If they come up with that solution, they will have a powerful tool for 3D printing. I want them to come up with that solution so I don't have to start modeling in another one that does.

I get the fact (I have experienced it) that the slicer will deal with this information as it is presented. I am saying that I would like the Lightwave STL export, in addition to handling all the things they already have done on their first two versions handling STL files (11.6.1 and 11.6.2) in finding holes and non-manifold edges...should ALSO find a solution for these voids...BEFORE a slicer is ever involved.

Am I being lazy? Absolutely. I have been spending 8 to 12 hours a day building models for 3D printing. I use the thicken tool, the supershift tool, the bevel tool, the face extrude tool like I have NEVER used them before...all to build acceptable geometry for 3D prints. I line up points so they are flat, I weld and I merge left and right. Ten months ago I never cared about hardly any of this stuff, I just made cool looking art that I rendered for 2D for a living. I just threw stuff around. It looked good. I got away with murder.

But give me some credit for being honest about it. I would love to call up a model I built 5 years ago. Assemble it to print properly on a bed and print it. But I can't. I never thought about overlaps back then. So EVERYTHING overlaps. And after 10 years of modeling in Lightwave...I'd like to keep it that way. Lazy, yes. Maybe. I have paid my dues in some regard.

And when I saw the video tutorial on the overlaps on 3D printing, I upgraded. I shelled out the bucks to upgrade.

Does it work like they said?

Nope, it doesn't really work.

Yes, I get the enclosed overlap idea...and it works...sometimes. It is paper-thin. It can be an excuse, but it does NOT make a sound construction. So I decided to call it a bug.

So, once again...if Lightwave makes overlaps possible...and just put in in like the rest of there STL export fixes....they will have a hit. Otherwise I have to export my Lightwave model to (ick) an AutoDesk free program to fix it.

And that just doesn't seem right.

Spherical, (nice cat, by the way) I understand where you are coming from.

I'm just saying...let's fix it on the STL export so when the slicer gets it....we're all good.

Noid the void. I don't think that's too much to ask. Win Win.



05-02-2014, 10:00 PM
I'm not getting why you have to process models through another product. I generate some pretty darn complex models and, inevitably, along the way something gets Borked; and I endeavor to model cleanly. It's just better all around, as renders come out better. The slicer I use is very strict. It tells me where errors are. I use that display to go back in, locate the offending item and manually fix it. Every time, it is something that an automated system would never be able to figure out and come up with a fix that didn't break something else. Sometimes, they are extremely difficult for me to find; when I'm being shown right where they are. In every one of these cases, it always takes a "fixer" having a pulse to make the correct decisions on what and how to effect the repair. Once the slicer no longer complains, I go to print. Never used anything else in these cases than Modeler if the model originated there.

I guess it comes down to determining what percentage of users usually model with a lot of overlapping geometry if they will consider it worth the effort to try to develop a tool that will correct them all. It'd be nice if it existed but the range of possible errors to be identified, and hopefully fixed correctly, is enormous. You have a fairly simple situation in your example. Might be possible to write a function to correct that. Some other stuff... not so sure it would be successful, if it were attempted. IOW, you can easily test whether all points are on polys and within a given range are welded, edges only share two polys, etc., but trying to come up with an algorithm that correctly examines anything possible and deciding whether it is logical, then determining a path to making it logical if it isn't would certainly be the Holy Grail of 3d Modeling.

Meshlab most often doesn't do it. Netfabb more often than not introduces more errors than it fixes—if it identifies that errors exist at all. The Mesh Repair tool that LW has is just a collection of existing functions rolled into one panel, but don't always get the job done. What I'm saying is that it isn't a trivial task; as evidenced by dedicated "fixers" that fail on an ongoing basis.

The cat. That's Larry, one of our Maine Coon rescues. Came with a family of 4 that were abandoned. Later, we rescued a family of 5 Bengals who wouldn't have survived on this mountain had we not taken them in. Don't know where they come from but they find us. Mountain Lions, Bobcats, Kit Fox and Great Horned Owls live here. We've lost 4 in the past year to predators. We have radio transmitters on them but sometimes that doesn't help when they're headstrong and won't come in. In the worst situations, the transmitter just leads us to the collar. We like letting them have their freedom but it's a struggle between that and keeping them alive. So, we're developing a large enclosure with plenty of space to roam in. Problem is, the Bengals are very smart. They show us the error of our thinking right quick and escape through means we had not thought possible. Then, the design gets modified and the testing begins anew.

05-02-2014, 10:31 PM
Didn't I mention that I was trying to be lazy?

I don't want to process my models through another program.

I want LW to deal with it, and thus be a leader.

And on the cat front....

My adopted rescued maine coon kitty agrees.

Well played sir...well played.


05-02-2014, 11:13 PM
Boone looks like a great friend.

Here's Rubeus:
Big & exceedingly furry. What else could we have named him?

05-03-2014, 04:45 PM
Well, isn't synchronicity weird. A slicer that I have been assisting in developing may be able to ignore intersecting separate meshes. The caveat is, that this isn't the same as overlapping/coincident polys within a mesh, so don't confuse the two. It is part of the multi-mesh capability used to print multi-color parts. Identifying and dealing with intersecting meshes definitely requires that the meshes be very clean and sound or the whole thing goes kablooey. It's another magnitude of complexity on top of an already very complex process. It may not work out to be reliable but there is work going on in this area.

On modelers: This perhaps doesn't help your wish to take old models that aren't sound and toss them at a printer without fixing them, but there are solid modelers that would handle your example and do the combination at export to one mesh. But, you may be able to get one of those and import your LWOs and see if it gets you closer by letting it redefine the shape according to its internal method, do some manual fixes if necessary and then export to STL directly or go back into LW and export from there.

05-05-2014, 08:02 AM
If I remember correctly from the LW3D video they were sending models to Shapeways for printing. Shapeways software DOES correctly process and print intersecting geometry. So from that standpoint, I would say it works exactly as they say it does.

It's home printer software that can't solve for intersecting geometry. I run into the same issues with my printer. This was one of my reasons for purchasing the BooleanTool plug-in from 3rdPowers when I have complex intersecting geometry to solve. I have spent a fair amount of time in Modeler doing booleans, then fixing the small holes it left behind. I never had success with MeshLab getting meshes watertight.

I understand trying to be lazy getting simple things to just work. I've not been able to really have that mindset with 3D printing, unfortunately. I (usually) keep Grid Snap on and measure everything really precisely as I model. I've had failed prints that usually result from trying to cut corners.

05-06-2014, 01:51 PM
Exactly right. I have seen people become better modelers after encountering the requirements of 3D printing. The OP is one of them. It just makes everything better when you do it well.

Shapeways and the like also invest time manually fixing models sent to them when the auto tools fail. It's in their best interest to appear that it "just works". You can send them nearly anything, up to obvious points of absurdity, and a great looking print will be sent back. The ones that take staff extra time to work on are offset by the many that come in ready to go.

05-08-2014, 08:37 PM
Not sure where you are getting your models printed, or if you are in need of color?

I send exported .obj files to Shapeways and have no issues with overlap. It doesn't care. So long as each object is a closed space, they can overlap all they want, and Shapeways uploader seems to like them just fine.

Build your object to proper scale in LW, export .obj, upload to Shapeways in Meter scale, bam!