How does stlread work?

Hi, Im not familiar with stlread but have a project at school where I want to create Gcode for 3d printers. I wanted to try to write a script of my own to understand and Matlab is the language I know the best.

I was trying to run a script I found on http://www.mathworks.com/matlabcentral/fileexchange/22409-stl-file-reader , but get "Not enough input arguments" for fid=fopen(file).

Does someone know what might be the problem, what I might do wrong?

Regards, Ernst

[Star Strider]

How are you calling the function?

What file name are you giving it?

Post the relevant parts of your code, including how you define and assign the file name you are sending to it.

[Ernst Wehtje]

This is the beginning of the code Im trying to run.

function varargout = stlread(moon)
% STLREAD imports geometry from an STL file into MATLAB.
%    FV = STLREAD(file) imports triangular faces from the ASCII or binary
%    STL file idicated by FILENAME, and returns the patch struct FV, with fields
%    'faces' and 'vertices'.
%
%    [F,V] = STLREAD(FILENAME) returns the faces F and vertices V separately.
%
%    [F,V,N] = STLREAD(FILENAME) also returns the face normal vectors.
%
%    The faces and vertices are arranged in the format used by the PATCH plot
%    object.

% Copyright 2011 The MathWorks, Inc.

      if ~exist(moon,'file')
          error(['File ''%s'' not found. If the file is not on MATLAB''s path' ...
                 ', be sure to specify the full path to the file.'], moon);
      end

      fid = fopen(moon,'r');    
      if ~isempty(ferror(fid))
          error(lasterror); %#ok
      end

      M = fread(fid,inf,'uint8=>uint8');
      fclose(fid);

      [f,v,n] = stlbinary(M);
      %if( isbinary(M) ) % This may not be a reliable test
      %    [f,v,n] = stlbinary(M);
      %else
      %    [f,v,n] = stlascii(M);
      %end

[Ernst Wehtje]

My stl file is named moon.stl and is located in the same folder as the script.

[nvmnghia]

From R2018b, it seems that the stlread() and stlwrite() is completely rewritten, leading to breaking changes. One point though, why the old stl.vertices and the new stl.Points return different number?

[DGM]

Each facet in an STL file is a direct representation of the numerical position of its vertices, not a set of indices into a global vertex list. That means that each vertex is described redundantly by each of its neighboring facets.

A decoder should remove those redundant vertices from the vertex list, but FEX #22409 does not. Instead of V being a concise list of the unique model vertices, and F being a concise descriptor of the model faces, V contains all the meaningful model information and F is a trivial linear ramp of indices from 1:size(V,1). In other words, V it is a complete description of both vertices and faces. Most of these decoders on the FEX are at least as half-baked, so it's not an inelegance unique to #22409.

If you have a decoder that doesn't do pruning, you can expect the length of V to be 3x the length of F, regardless of how many unique vertices there actually are. For most practical solid models, you should usually expect V to be shorter than F, not the other way around.

TL;DR The built-in stlread() from R2018b does properly prune the vertex list, that's why V will be so much shorter than with #22409

Answer 1

[DGM]

It looks like you edited the variable names in the function, and then you called the function with no arguments. Don't mess with the function file. Just call the function with your filename.

FV = stlread('myfile.stl'); % FEX #22409 returns a struct

That said, after R2018b, there are STL read/write tools in the base toolbox, so you don't need to mess with #22409 anymore.

T = stlread('myfile.stl'); % R2018b+ stlread() returns a triangulation object