2
$\begingroup$

10-year Blender user here (currently 2.79b, Win 10), facing a strange problem. I'm trying to export a selected object to STL, a routine action for me. I've boiled the problem down to a simple file containing one tetrahedron. When I select this tetrahedron and do Export --> STL with Export Selected checked, the resulting STL file is empty and will not open in another viewer (NetFabb).

Simple tetrahedron file here. (Google Drive, export-broken.blend, 622 kB)

Here are some cases that should help narrow down the behavior.

If I copy (shift-D) the tetrahedron, the copy also fails to export when selected. If I move the original tetrahedron to another layer, it properly exports to STL. If I make a copy, move the copy to another layer, and select both for export, the resulting STL contains only the copied+moved tetrahedron.

Blender view of original and copied tetrahedra in two layers. Resulting STL file (viewed in Netfabb) of two tetrahedra exported to STL.

Exporting all (not just selected) works normally, even with just the original problematic tetrahedron.

Additional background: of course, I'm not trying to export tetrahedrons; I encountered this bug in the context of a much more complex file. I am preparing objects for 3D printing -- again, routine for me -- and exporting all is not an option. Anecdotally, it appears that this is not limited to STL export but also affects export to other formats. Moving an object to another layer in my more-complex file does not fix the export problem. The onset of the issue was not accompanied by any major change or issue I was aware of.

SOLVED (see answer below). The reason the object that is moved becomes exportable is that it was moved to a layer that happened to be set as visible in the second, minimized viewport.

$\endgroup$
2
$\begingroup$

I've figured out the issue. My file -- and example file -- has two 3D-view panels open. Each of these permits layers to be selected as visible or not in the usual way. The main viewport has layers visible for my object (the example tetrahedron). However, a second split window, also set to 3D View, has only other layers selected to be visible -- the layer containing the tetrahedron is NOT set to visible in this other, minimized window.

It turns out that setting the tetrahedron's layer to visible in this second window suffices to make the object export properly. So it appears that the Export code is reading the layer visibility from one viewport (the most-recently-created one?), even if this is not the main viewport.

Here is a clearer example of a situation in which the selected object will not export. Note that the lower window (now not minimized) has a layer not containing the target object selected for visibility.

Case in which selected object will not be exported.

A hint about this came from an answer to another question (STL empty on export (Python API), answer by Azukikuru) which refers to visibility. Visibility turned out to be the key here.

$\endgroup$
  • 1
    $\begingroup$ Further to this comment for an object to be a member of context.selected_objects it has to be on a selected scene layer as well as visible and selected. An exporter will iterate over this list for "export selected" option, Will iterate over all scene objects for export all. (Can test this by opening a python console and typing C.selected_objects. ( Pretty much explains issue in q. $\endgroup$ – batFINGER Aug 9 '18 at 17:56
  • $\begingroup$ If I understand correctly, it's that it needs to be on either all or the most recently created scene layer -- if it is on a selected scene layer, as in the picture, but that scene layer is only selected in a subset of viewports, then export will still not occur. $\endgroup$ – biochemist Aug 9 '18 at 18:26
  • 1
    $\begingroup$ The scene's active layers are what count. $\endgroup$ – batFINGER Aug 9 '18 at 18:44
  • $\begingroup$ What's surprising is that, in this case, there is only one scene, and the layer is active in one viewport, while inactive in another (smaller, minimized) viewport -- and the latter determines what is "visible" to the exporter. I did not appreciate until encountering this that layers are not simply active or inactive, but can have multiple activity statuses simultaneously on the same screen. $\endgroup$ – biochemist Aug 10 '18 at 0:56
0
$\begingroup$

I´m interested in this case. You have not mentioned if after the SHIFT+D you apply the translation to deltas? I´d try this on your duplicated copy. After you move -duplicate it, apply Location, then all transforms to Delta. This should zero out your coordinates, which seem to generate this problem (center of world for ZTL export).

Try that and see how it goes. Other than that I´d take a wild guess there´s an activated plugin conflict related to exporting .ztl. I´d also advice to repeat this error with all addons off, except the .ztl exporter to determine further conflicts.

Let us know how it goes. Thanks.

$\endgroup$
  • $\begingroup$ Hi -- thank you, I really appreciate the suggestion and interest. Turns out I was able to figure it out and have posted an answer. The translation/transforms turn out to not be the issue; it's multiple instances of layer visibility. Weird and probably worth addressing in the application. $\endgroup$ – biochemist Aug 9 '18 at 17:27
  • 1
    $\begingroup$ Voted up. I didn´t see a second viewport on your 1st capture. Glad this worked out. $\endgroup$ – Pierre Schiller Aug 9 '18 at 20:51
  • $\begingroup$ Yeah -- it's there and minimized; in my workflow, I use the bottom pane for Nodes and 3D View|Render, and it's the latter that led to the issue. In the original screenshot, you can see the minimized strip, but the layer visibility portion is missing -- of course, had I known that was the issue, I'd have screenshotted differently! $\endgroup$ – biochemist Aug 10 '18 at 0:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.