Reading and plotting STL File

I'm trying to read a .stl file and plot its triangulated surface (from scratch).

%- Let's storage the vertices in an array.
fid     = fopen('Silla.stl','r');
regex   = '\s*vertex\s*([-]?(?:[0-9]*[.])?[0-9]+)\s*([-]?(?:[0-9]*[.])?[0-9]+)\s*([-]?(?:[0-9]*[.])?[0-9]+)';
line_ex = fgetl(fid);
i = 1;
j = 1;

while ~feof(fid)
    line_ex = fgetl(fid);
    if regexp(line_ex,regex)
        toks   = regexp(line_ex, regex, 'tokens');  

          %- Points
          p{i,1} = str2double(toks{:}{1});
          p{i,2} = str2double(toks{:}{3});
          p{i,3} = str2double(toks{:}{2});
          %p{i,4} = 1;

          %- Counter
          i = i + 1;

      end
  end
  fclose(fid);

    %- Indices.
    k = 1;
    for j = 1:(size(p,1)/3)
            t{j,1} = k;
            t{j,2} = k+1;
            t{j,3} = k+2;
            k = k + 3;
    end

what I wanna do is plot triangle by triangle.

I've already tried it with trisurf, plot3 and fill3, but I have not seen results.

Any ideas?

[Ricardo Correa]

Solved:

%- Okay. Let's graph.
t = double(cell2mat(t));
p = double(cell2mat(p));

TR = triangulation(t,p);
trisurf(TR);

[Walter Roberson]

Please do not close questions that have an answer.

[Rena Berman]

(Answers Dev) Restored edit

Answer 1

[KSSV]

You have function to read stl file in file exchange. Check this link: https://in.mathworks.com/matlabcentral/fileexchange/22409-stl-file-reader. This read all the vertices and connectivity data. On kowing this, you can use trisurf.

[Ricardo Correa]

I don't understand how to do it, because it uses 4 parameters, I tried uses the p as the first one but it doesn't work.

[Ricardo Correa]

I have to read stl file manually.

Answer 2

[DGM]

There are (and were) a number of STL reading tools available depending on the timeframe.

Basic reading and plotting:

Starting in R2018b, MATLAB comes with built-in STL tools. If you're running a newer version, this is all you need. This includes a fully-capable reader and writer, and it returns a triangulation object, which offers further conveniences.

https://www.mathworks.com/help/matlab/ref/stlread.html

https://www.mathworks.com/help/matlab/ref/stlwrite.html

(I love that neither of these docs pages include any helpful links to the other)

% this was introduced in R2018b
% the output is a triangulation object
% which holds the F,V data (T.ConnectivityList, T.Points)
% and offers other useful methods
% supports both ASCII and binary mode files
% was introduced along with stlwrite()
T = stlread('stepholecube.stl'); % you don't need to download anything

% display it using patch()
figure(3)
patch('faces',T.ConnectivityList,'vertices',T.Points, ...
    'facecolor','w','edgecolor','k');
view(3); camlight; view(10,33)
axis equal; grid on
xlabel('X'); ylabel('Y'); zlabel('Z')

Depending on your needs, you can try using trisurf() with such an object, or you can just use the FV data as before to set up a patch() object instead.

If you need an STL decoder or encoder for a legacy version, use the stlTools library. This includes a fully-capable reader and writer, along with some other convenience utilities.

https://www.mathworks.com/matlabcentral/fileexchange/51200

% this was published on the FEX in 2015-2017 (#51200)
% the output is FV data
% supports both ASCII and binary mode files
% includes tools for writing, inspecting, and modifying STL files
[V F] = stlRead('stepholecube.stl');

% display it using patch()
figure
patch('faces',F,'vertices',V,'facecolor','w','edgecolor','k');
view(3); camlight; view(10,33)
axis equal; grid on
xlabel('X'); ylabel('Y'); zlabel('Z')

... and the plot will be the same.

The tool recommended above (FEX #22409) is something posted on the File Exchange by Mathworks in 2008. It's not a fully-functional STL reader, and in modern versions, it will cause a naming conflict if you install it without renaming it. Unless your hobby is cataloging all the bugs in old FEX STL tools, you do not ever need to use FEX #22409.

See the following comment for a review of the other STL decoders available on the FEX.

Additional data:

Both stlread() and FEX #51200 will return face normals. In the first case, use faceNormal() on the triangulation object. In the second case, request the third output argument.

Files with embedded per-face color data can be read using stlread(). There are various formats for cramming things in the face attribute fields, but stlread() simply returns the entire 16b packed field and it's up to you to know what in it and how to decode it.

Assuming a VisCAM formatting, consider the following example:

%% WRITING A FILE WITH VISCAM DATA
% get some F,V data
[X Y Z] = sphere(20);
[F V] = surf2patch(X,Y,Z,'triangles');

% generate a color table for the faces
T = triangulation(F,V);
facecent = incenter(T); % face incenter
xpos = facecent(:,1); % vary color by x-position
N = 255;  CT0 = jet(N); % the base colormap
CT = interp1(linspace(min(xpos),max(xpos),N),CT0,xpos); % lookup table

% write the file
attfield = packattributes(CT); % attached
stlwrite(T,'colored.stl','attribute',attfield)

% show it
figure(1)
patch('faces',F,'vertices',V,'facevertexcdata',CT, ...
    'facecolor','flat','edgecolor','k');
view(3); axis equal; grid on
title('the original colors')

%% READING A FILE WITH VISCAM DATA
% read the file
[T,~,attfield] = stlread('colored.stl');
[CT flag] = unpackattributes(attfield); % attached

% show it again
figure(2)
patch('faces',T.ConnectivityList,'vertices',T.Points, ...
    'facevertexcdata',CT,'facecolor','flat','edgecolor','k');
view(3); axis equal; grid on
title('the recovered colors')

For VisCAM color support in legacy versions, FEX #51200 and #20922 have encoders, and #36771 has a decoder. The encoders mentioned require the color table to be given in [0 31] scale, not [0 1] scale. Likewise, #36771 will return the color table in [0 31] scale. You will need to rescale it if you want to plot with it.

Again, see the following comment for other details.

[DGM]

I decided that I had too much time, so here's a more complete overview of all (or most) STL readers on the FEX. There's no good place to put this, so I'm going to cram it here.

If you are using a modern version, just use the built-in decoder. If you need a legacy decoder, I recommend #51200. Out of all the decoders in this list, these two are the only ones which meet the following criteria I have chosen:

• supports both ASCII and binary encodings
• actually checks encoding type instead of trying things blindly and breaking
• returns data in some F,V format instead of a cumbersome mess of XYZ lists
• returns a pruned list of unique vertices, so as to maintain mesh connectivity

%% R2018b+ built-in returns a triangulation object
% + can read binary or ascii encoded files
% + can also read color or other attribute data as raw (full 16b per face)
% + returns pruned vertex list (stable)
% + triangulation object has added functionality (e.g. normals)
% - ascii files with NaN normals (degenerate faces) will cause error
T = stlread(fname);

%% FEX #51200 (stlTools) returns F,V lists
% + can also return face normals (as encoded)
% + can read binary or ascii encoded files
% +/- returns pruned vertex list (sorted by x) (easily patchable)
% ~ can't read binary files with >2.15B triangles (this bug doesn't matter in practice)
% loosely derived from #27390 and other FEX works
% duplicated in multiple places on the FEX
% supplied function name: stlRead()
[V,F] = stlRead(fname);

I don't see any reason to recommend the rest of these for general use. Some are intended for narrow use cases. Some have minor issues. Others are just half-baked or completely broken. These are listed sequentially by submission number or roughly by date. The Lohsen, Aitkenhead, and FieldTrip decoders are honorable mentions, but they're just missing some things.

For my own purposes, I've renamed all of these function names to prevent collisions and keep track of what's what. The files won't be named like this when you download them. The comments clarify what the original function names were. Note that #6678, #22409, #29906, #36771, and #132048 will shadow the built-in stlread() if you use them in a modern version without renaming them.

Of all the ones that claim to support color attribute output, #36771 is the only one which is possibly correct. I do not have a legitimate VisCAM STL file to verify it against, but it behaves as expected for the known description of the packing. All the other ones return identical jumbled nonsense because they're extracting the wrong width bitfields from the attribute bytes. No matter how you align it, you can't pack three 6b fields in 15b.

As with the VisCAM decoding bug that others inherited from #6678, several decoders inherited an integer type bug from #6678 which results in incorrect behavior for astronomically large files. I'm noting it just as a matter of record. In practice, we can ignore this bug for any file which could plausibly fit in memory. It's wrong, but there is no realistic scenario in which it would matter.

%% FEX #3642 returns no data
% - can read only ascii encoded files, but does not properly test encoding type
% - does not consolidate redundant vertices during decoding, so V (in the patch object) will be full of duplicates
% - has a bug due to changes in case sensitivity, requiring patching
% - slow to use, mostly due to plot animation (~35s/40k faces)
% reads and produces an animated plot, but does not directly return any data
% supplied function name: cad2matdemo()
stlread_riley(fname)

%% FEX #6678 returns flat XYZ data instead of consolidated FV data
% - can also return VisCAM-style color data, but the results are completely wrong
% - can read only binary encoded files, but does not properly test encoding type
% ~ can't read binary files with >2.15B triangles (this bug doesn't matter in practice)
% output consists of 3-row (transposed) lists, one each for X,Y,Z,C
% supplied function name: stlread() (will cause conflict in modern versions)
[X,Y,Z,C] = stlread_harlev(fname);

%% FEX #13253 returns a cell array of X,Y,Z lists
% + can read binary or ascii encoded files, but doesn't actually check encoding.
%   it just tries both decoders hoping one works.
% - can also return VisCAM-style color data, but the results are completely wrong
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - ascii decoder is slow (~9s/40k faces)
% ~ can't read binary files with >2.15B triangles (this bug doesn't matter in practice)
% Vc is {X,Y,Z}, where (e.g.) X is a 3-row (transposed) list of the x-components of the vertices for each face
% this is part of the IGES toolbox, but does not depend on it
% supplied function name: stl2matlab()
[Vc,C,isbin] = stlread_bergstrom(fname);

%% FEX #22409 returns either an FV struct or F,V lists
% + can also return face normals (as encoded)
% - can read only binary encoded files, but does not properly test encoding type
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% this was originally laid out to include ascii encodings and type checks; lots of dead code
% duplicated in multiple places on the FEX
% supplied function name: stlread() (will cause conflict in modern versions)
[F,V] = stlread_2011(fname);

%% FEX #27390 returns a monolithic array of XYZ coordinates
% + can also return face normals (as encoded)
% + can read binary or ascii encoded files
% - does not consolidate redundant vertices during decoding
% ~ can't read binary files with >2.15B triangles (this bug doesn't matter in practice)
% output is a NFACESx3x3 array formatted as FACES,XYZ,VERTICES
% duplicated in FEX #27174 #27733 #29585
% supplied function name: READ_stl()
FV = stlread_aitkenhead(fname);

%% FEX #29906 returns F,V lists
% + can also return face normals (as encoded)
% - can also return VisCAM-style color data, but the results are completely wrong
% - can read only binary encoded files, but does not properly test encoding type
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% ~ can't read binary files with >2.15B triangles (this bug doesn't matter in practice)
% based on #6678 and an early version of #22409
% supplied function name: stlread() (will cause conflict in modern versions)
[V,F,N,C] = stlread_white(fname);

%% FEX #30923 returns F,V lists or unconsolidated sequential vertex lists
% + can also return face normals (as encoded)
% +/- returns pruned vertex list (sorted by x) (easily patchable)
% - can read only ascii encoded files, but does not properly test encoding type
% - can only read windows formatted ascii files (\r\n), and will otherwise fail
% - will delete the last face normal if the header name begins with more than one word
%   other particular formatting of the header text can cause different errors
% - has other bugs (NaNs can't be tested for equality)
% supplied function name: import_stl_fast()
[V,F,N] = stlread_trautmann(fname,1);
%[VF,N] = stlread_trautmann(fname,2); % unconsolidated vertex list

%% FEX #36771 returns F,V lists
% + can also return face normals (as encoded)
% + can also return VisCAM-style color data from the face attribute bytes
% - can read only binary encoded files, but does not properly test encoding type
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% ~ can't read binary files with >2.15B triangles (this bug doesn't matter in practice)
% based on #6678 and an early version of #22409
% supplied function name: stlread() (will cause conflict in modern versions)
[V,F,N,C] = stlread_lohsen(fname);

%% FEX #41910 returns a vector of unconsolidated vertex data
% - can read only ascii encoded files, but does not properly test encoding type
% - uncontrollably plots the file, but axis is not cleared or configured properly
% - uses random vertex color data for every patch, making visual garbage for no good reason
% - creates a separate patch object for every face, making an unmanageable laggy mess
%   which may make MATLAB unresponsive or crash for moderately large files
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - will return jumbled garbage if the header name is empty or contains more than one word
% - decoder and graphics abuse can be prohibitively slow (>200s/40k faces)
% output format is a vector containing [x; y; z] sequences for each vertex of each triangle;
% e.g. [t01v01x; t01v01y; t01v01z; t01v02x; t01v02y; t01v02z; t01v03x; ... ]
% supplied function name: readSTL()
V = stlread_rane(fname);

%% this thing from IFIT returns a struct full of various things
% https://github.com/mccode-dev/iFit/blob/master/Libraries/Loaders/read_stl.m
% the contents of the output depend on which decoder is used internally
% + can read binary or ascii encoded files, but doesn't actually check encoding.
%   it literally just has a pile of decoders and tries each one until one works.
% +/- can also return encoded face normals, but only for binary encoded files
% - can also return VisCAM-style color data, but the results are completely wrong
%   and the formatting is inconsistent.
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - ascii decoder is slow (~9s/40k faces)
% ~ can't read binary files with >2.15B triangles (this bug doesn't matter in practice)
% based on #3642, #29906, #30923
% supplied function name: read_stl()
FV = stlread_ifit(fname)

%% FEX #53736 returns F,V lists
% + could also return face normals (as encoded)
% - can read only ascii encoded files, but does not properly test encoding type
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - uncontrollably plots the file
% - requires several bugfixes before it will run with most files:
%   read_three_numbers() does not return consistent/correct output size
%   multiple preallocation/assignment issues allow subsequent problems to develop
%   it was probably written to depend on the numeric formatting used by a particular encoder
% - ascii decoder is very slow (~56s/40k faces)
% supplied function name: read_stl_file()
[F,V,N] = stlread_yime(fname);

%% FEX #55891 returns F,V lists
% + can also return face normals (as encoded)
% + can read binary or ascii encoded files
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - ascii decoder is slow (~8s/40k faces)
% this is part of the FieldTrip toolbox, but does not depend on it
% duplicated in FEX #78559
% supplied function name: read_stl()
[V,F] = stlread_oostenveld(fname);

%% FEX #56269 returns either an FV struct or F,V lists
% + can also return face normals (as encoded)
% +/- returns pruned vertex list (sorted by x) (easily patchable)
% - can read only binary encoded files, but does not properly test encoding type
% based on #22409, complete with all the dead code
% supplied function name: stlread_slim_fv()
[F,V,N] = stlread_vigni(fname);

%% FEX #62113 returns a monolithic array of XYZN data
% + can also return face normals (as encoded)
% - can read only ascii or binary encoded files, but neither file properly tests encoding type
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - ascii decoder requires the user to guess the number of header lines in the file
% - no useful documentation
% - ascii decoder is very slow (~45s/40k faces)
% output format is [X0 Y0 Z0 X1 Y1 Z1 X2 Y2 Z2 Xn Yn Zn]
% this submission contains both the ascii and binary tools
% supplied function name: read_binary_stl_file(), read_ascii_stl() (nice and inconsistent)
TR = stlread_bhandari_a(fname,1); % 1 is a good guess
%TR = stlread_bhandari_b(fname);

%% FEX #62345 returns F,V lists
% + can also return face normals (as encoded)
% - can read only binary encoded files, but does not properly test encoding type
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - never closes the file
% - no useful documentation
% this submission contains only the binary tool
% supplied function name: read_binary_stl_file()
[F,V] = stlread_bhandari_bfv(fname);

%% FEX #78589 returns a monolithic array of XYZN data
% + can also return face normals (as encoded)
% - contains code for both ascii and binary, but encoding type test fails to detect binary encoding
% - requires the explicit path to the file, otherwise it will fail
% - never closes the file
% - completely undocumented
% - ascii decoder is extremely slow and depends on R2016b+ (~90s/40k faces)
% output format is [X0 Y0 Z0 X1 Y1 Z1 X2 Y2 Z2 Xn Yn Zn]
% supplied function name: read_stl_file()
XYZN = stlread_jack(which(fname));

%% FEX #112660 returns an FV struct
% + can read binary or ascii encoded files, though encoding type test is weak
% - does not consolidate redundant vertices during decoding, so V will be full of duplicates
% - ascii decoder is extremely slow (~80s/40k faces)
% the original was uploaded somewhere in 2018 and has since gone missing
% supplied function name: stl_read()
FV = stlread_flandin(fname);

%% FEX #132048 returns an OBJ_STL object
% + can read binary or ascii encoded files, though encoding type test is weak
% +/- does not return a pruned vertex list, but has an object method to do so (stable)
% - requires R2021a or newer (completely unnecessary; easily patched)
% - requires TKFile for ASCII file access (completely unnecessary; easily patched)
% - completely undocumented
% this is a class for reading/writing an STL and doing things with the data
% supplied function name: STL_OBJ(), stlread() (will cause conflict in modern versions)
FVobj = stlread_kuang(fname); % read file
FVobj = remove_duplicate(FVobj); % prune verts (stable pruning!)

I haven't tested any of these for one reason or another:

% 71762 (nguyen, 2019) (ascii-only, mex)
% 73094 (STLtool, 2021) (ascii/binary, outdated(?) mlapp with stl decoder hidden in p-code)

[DGM]

On the way to find all those STL decoders, I found a pile of STL encoders to review as well.

I really don't know where to put this. This thread is the highest-viewed thread for "write stl", and that's probably my fault.

Say we define various sorts of formatted example inputs:

%% generate some data
[X Y Z] = sphere(20); % gridded data
FV = surf2patch(X,Y,Z,'triangles'); % an FV struct
F = FV.faces; % F,V lists
V = FV.vertices;
T = triangulation(F,V); % a triangulation object

If you are using a modern version, just use the built-in encoder.

%% R2018b+ built-in takes a triangulation object
% + can write binary or ascii encoded files (default binary)
% + can also read color or other attribute data as raw (full 16b per face)
% output format is '%.9g' when writing ascii (9 sig figs)
stlwrite(T,'test1.stl')

If you need a legacy encoder, I'm going to be a bit less picky about my recommendations. Personally, all I want is something that meets the following criteria:

• supports both ASCII and binary encodings
• accepts data in some F,V format instead of a cumbersome mess of XYZ lists
• can actually run in a legacy environment

Three of these submissions can meet those criteria, but one has clear flaws. While Sven Holcombe's encoder (#20922) is the definitive choice, I tend to recommend #51200 for two reasons:

• #20922 can cause naming conflicts, so it's a hazard to recommend to inattentive readers
• #51200 already includes the decoder which I recommend

%% FEX #51200 takes an FV struct, F,V lists, or gridded XYZ data
% + can write binary or ascii encoded files (default binary)
% + can write VisCAM-style color attribute data (uint6-scale required)
% + can automatically triangulate gridded inputs
% output format is '%.7E' when writing ascii (8 sig figs)
% this is just a renamed early copy of #20922
% supplied function name: stlWrite()
stlWrite('test1.stl',FV)
stlWrite('test2.stl',F,V,'mode','ascii')
stlWrite('test3.stl',X,Y,Z,'triangulation','f') % gridded data

For my own purposes, I've renamed all of these function names to prevent collisions and keep track of what's what. The files won't be named like this when you download them. The comments clarify what the original function names were. Note that #20922 and #36770 will shadow the built-in stlwrite() if you use them in a modern version without renaming them.

Note that the encoders which support ASCII output use different number formatting for their output. A binary STL file encodes position in 32 bit floating point. In order to achieve comparable precision in text, we need about 9 significant digits. There's a significant incentive to keep file size under control, even if it comes at the loss of a little bit of information, so fewer digits may be acceptable.

https://www.mathworks.com/matlabcentral/answers/1976939-the-points-read-with-stlread

As far as I'm concerned, if you want to save file size, simply avoid using ASCII encoding. While the loss with 8SF or even 7SF is likely insignificant for most applications, some of these have much worse fidelity. The precision used in ASCII mode is noted where applicable.

%% FEX #4512 takes gridded XYZ data
% + can write binary or ascii encoded files (default binary)
% + can automatically triangulate gridded inputs
% output format is '%.7E' when writing ascii (8 sig figs)
% supplied function name: surf2stl()
surf2stl('test1.stl',X,Y,Z) % gridded data

%% FEX #20922 takes an FV struct, F,V lists, or gridded XYZ data
% + can write binary or ascii encoded files (default binary)
% + can write VisCAM-style color attribute data (uint6-scale required)
% + can automatically triangulate gridded inputs
% output format is '%.7E' when writing ascii (8 sig figs)
% compared to #51200, this adds only a minor facet length check
% supplied function name: stlwrite() (will cause conflict in modern versions)
stlwrite_holcombe('test1.stl',FV)
stlwrite_holcombe('test2.stl',F,V,'mode','ascii')
stlwrite_holcombe('test3.stl',X,Y,Z,'triangulation','f') % gridded data

%% FEX #24400 takes F,V lists
% + returns face normals as an output
% - only supports ascii encoding
% - fails with an indexing error if NFACES < 3 
% - will return (and encode) wrong normals if NFACES == 3
% output format is '%14e' when writing ascii (7 sig figs)
% supplied function name: STL_export()
N = stlwrite_richter(V,F,'test1.stl','myobjectname');

%% FEX #27733 takes a monolithic array of XYZ coordinates and a face normal list
% + can write binary or ascii encoded files (default ascii)
% - user must externally calculate all the face normals
% output is a NFACESx3x3 array formatted as FACES,XYZ,VERTICES
% output format is '%e' when writing ascii (7 sig figs)
% duplicated in FEX #29585
% supplied function name: WRITE_stl()
FVXYZ = cat(3,V(F(:,1),:),V(F(:,2),:),V(F(:,3),:));
N = faceNormal(T);
stlwrite_aitkenhead('test1.stl',FVXYZ,N)

%% FEX #36770 takes an FV struct, F,V lists, or gridded XYZ data
% + can write binary or ascii encoded files (default binary)
% + can write VisCAM-style color attribute data (uint6-scale required)
% + can automatically triangulate gridded inputs
% - gridded triangulation depends on but does not include mesh2tri() (FEX #28327)
% - has a bug which requires patching(line 127, see FEX comments)
%   unless patched, this tool will not work without a specified facecolor list
% output format is '%.7E' when writing ascii (8 sig figs)
% based on #20922
% supplied function name: stlwrite() (will cause conflict in modern versions)
stlwrite_lohsen('test1.stl',FV)
stlwrite_lohsen('test2.stl',F,V,'mode','ascii')
stlwrite_lohsen('test3.stl',X,Y,Z,'triangulation','f') % gridded data

%% FEX #55891 takes a F,V lists and a face normal list
% - only supports ascii encoding
% - uses narrow fixed-point notation, potentially reducing precision significantly
% - user must externally calculate all the face normals
% - depends on FieldTrip toolbox (line 40) (easily patchable)
% output format is '%f' when writing ascii (0 or more sig figs)
% this is part of the FieldTrip toolbox
% supplied function name: write_stl()
N = faceNormal(T);
stlwrite_oostenveld('test1.stl',V,F,N)

%% FEX #62406 takes F,V lists
% - only supports binary encoding
% - face normals are incorrectly normalized (N.*n instead of N./n)
% supplied function name: saveSTLbin()
stlwrite_weijs('test1.stl',V,F)

%% FEX #117400 takes a surf plot handle
% + can write binary or ascii encoded files (default binary)
% - uses narrow exponential notation in ascii mode, reducing precision significantly
% - requires filename to be specified without an extension
% - winding order is correct, but all the calculated normals are backwards
% output format is '%12.4e' when writing ascii (5 sig figs)
% supplied function name: surf2stl()
hs = surf(X,Y,Z);
surf2stl_kareem(hs,'test1','ascii') % no extension

%% FEX #132048 takes F,V lists
% - only supports binary encoding
% - completely undocumented
% this is a class for reading/writing an STL and doing things with the data
% supplied function name: STL_OBJ()
obj = STL_OBJ(V,F);
write(obj,'test1.stl')

I haven't tested any of these for one reason or another:

%% untested
% 41597 (arso, 2013) MEX, ascii-only ('%f' number format (bad))