How do i export an .off file

[Lee Brenton]

Hi,

I'm brand new to this software, i can't figure out how to export a model.
I'm using windows.

Thanks so much.
Lee

[Adrian Rossiter]

Hi Lee

On Wed, 8 Oct 2014, Lee Brenton wrote:
> I'm brand new to this software, i can't figure out how to export a model.
> I'm using windows.

If you just want the OFF file, then you can redirect the output to
a file like this

Make a red cube and view it
off_util cube | off_color -f red | antiview

Make a red cube and Save the file
off_util cube | off_color -f red > red_cube.off

View the saved model
antiview red_cube.off

If you already have the OFF file but want to import it into a
different program that doesn't accept OFF, if you say what
program you are using there may be a utility available to
convert the OFF to a suitable format.

Adrian
--
Adrian Rossiter
adr...@antiprism.com
http://antiprism.com/adrian

[Lee Brenton]

Hi Adrian,

Thanks for your reply, that worked to create an OFF file, i noticed you have a link to MeshLab, so i tried to import into that .. but there was an error.. ultimately i will want to convert into something standard like DXF or OBJ.
I love this software! i've been trying to model geodesics for years this makes it so much easier!

Thanks again
Lee

[Adrian Rossiter]

Hi Lee

On Thu, 9 Oct 2014, Lee Brenton wrote:
> Thanks for your reply, that worked to create an OFF file, i noticed you
> have a link to MeshLab, so i tried to import into that .. but there was an
> error.. ultimately i will want to convert into something standard like DXF
> or OBJ.

Meshlab doesn't like the vertex and edge colours that Antiprism
can write into OFF. However, these can be easily removed like
this

off_util cube | off_color -f red > red_cube.off

off_util -x ev red_cube.off > red_cube_no_e_or_v_colors.off
meshlab red_cube_no_e_or_v_colors.off

> I love this software! i've been trying to model geodesics for years this
> makes it so much easier!

Great!

Adrian.

[Lee Brenton]

That worked great! Thanks!

meshlab loved it, and exported fine,

Though there is a problem - with triangular tessellation, i'm creating a "geo_5_3_d" which has pentagons and hexagons. but each face is triangulated.. i have tried the "no_tri" command.. but i'm unsure of the syntax and i just keep getting errors.

at this stage i'm just manually deleting the extra edges.. (which is much much faster than manually creating the whole shape so i'm still happy).

[Adrian Rossiter]

Hi Lee

On Thu, 9 Oct 2014, Lee Brenton wrote:
> Though there is a problem - with triangular tessellation, i'm creating a "geo_5_3_d"
> which has pentagons and hexagons. but each face is triangulated.. i have
> tried the "no_tri" command.. but i'm unsure of the syntax and i just keep
> getting errors.
>
> at this stage i'm just manually deleting the extra edges.. (which is much
> much faster than manually creating the whole shape so i'm still happy).

The base model isn't triangulated, and off_util -t doesn't have a
no_tri argument as the default is not to triangulate. The following
OFF output contains square faces

off_util std_cube

On the other hand, off2pov automatically triangulates, as POV-Ray
will not generally display self-intersecting polygons correctly.
To suppress this

off2pov -t no_tri std_cube

The POV-Ray format will includes the original square faces. These faces
are convex and display fine, as would the faces of the geo_5_3_d model.

[Roger Kaufman]

Hi Adrian and Lee,

I wonder if Meshlab is triangulating the input? Certainly the output
from antiprism isn't triangulated or contains invisible edges.

off_util -g geo_5_3_d | antiview

And peaking into the output with an editor shows there are no triangular
faces, only 5 and 6 fold faces.

Roger

[Lee Brenton]

Hi Roger and Adrian, 

Thanks for your help - yeah it quite possibly is Meshlab's import that is triangulating the mesh.
I have found a little python script that will convert an .OFF file into an .OBJ file. This sidesteps Meshlab's import triangulation issue.
it worked perfectly for the geo_5_3_d .. i haven't tested anything else.

script can be found here:

http://www.clementcreusot.com/phd/scripts/off2obj.py
or the pastebin backup http://pastebin.com/r0BEizHV

Thanks for your help! I love this software.

Kind Regards
Lee

[Roger Kaufman]

Hi Lee,

The obj format has other features but I am wondering if this is all we
need for converting OFF files. If so I could try making an off2obj
program as part of antiprism. Edges do not transfer, but the script
seems to add some artifacts if the vertex colors are not stripped first.
Does this make a difference in the appearance in Meshlab? If what comes
into Meshlab shows the same result as without the vertices colored then
they would never be needed in the output.

An example is

off_util tet > tet.off
off2obj.py tet.off

Gives the following output with one vertex 'faces' in the bottom 4 lines.

# File type: ASCII OBJ
v 0.3535533905932738 0.3535533905932738 0.3535533905932738
v 0.3535533905932738 -0.3535533905932738 -0.3535533905932738
v -0.3535533905932738 0.3535533905932738 -0.3535533905932738
v -0.3535533905932738 -0.3535533905932738 0.3535533905932738
f 4 2 1
f 3 1 2
f 4 1 3
f 3 2 4
f 1
f 2
f 3
f 4

Roger

[Lee Brenton]

Hi Roger, 

That would be great!
I forgot to mention that i did actually strip the colors, following Adrian's steps:

off_util tet > tet.off 

off_util -x ev tet.off > tet_no_e_or_v_colors.off 

off2obj.py tet_no_e_or_v_colors.off tet_no_e_or_v_colors.obj

Lee

[Roger Kaufman]

Hi Adrian,

On 10/9/2014 11:01 AM, Roger Kaufman wrote:
> # File type: ASCII OBJ
> v 0.3535533905932738 0.3535533905932738 0.3535533905932738
> v 0.3535533905932738 -0.3535533905932738 -0.3535533905932738
> v -0.3535533905932738 0.3535533905932738 -0.3535533905932738
> v -0.3535533905932738 -0.3535533905932738 0.3535533905932738
> f 4 2 1
> f 3 1 2
> f 4 1 3
> f 3 2 4

> f 1 2
> f 1 3
> f 1 4
> f 2 3
> f 2 4
> f 3 4

> f 1
> f 2
> f 3
> f 4

I was starting to write an off2obj program but I started to duplicate a
lot of code. I was wondering if using off2crds and add an option to
output OBJ file format would be better. Then another small procecure in
off_write.cc would all that is needed.

All the procedure has to do is output the coordinates with a 'v' in
front of them. And then output any faces, edges, and/or (colored)
vertices with 'f'. At least then it would be consistent with the output
of the python script.

This would generate the least new code. Thoughts?

An alternative would be to make an off2obj program but still do the code
addition in off_write.cc

Roger

[Adrian Rossiter]

Hi Roger

On Thu, 9 Oct 2014, Roger Kaufman wrote:
> An alternative would be to make an off2obj program but still do the code
> addition in off_write.cc

That sounds like the best option for now. While the other converters
have their own executable the conversion to OBJ might be missed if
it was an off2crds option.

[Roger Kaufman]

Hi Adrian,

On 10/10/2014 4:17 AM, Adrian Rossiter wrote:
> That sounds like the best option for now. While the other converters
> have their own executable the conversion to OBJ might be missed if
> it was an off2crds option.

The other problem is the converters all have unique parameters. I just
thought this isn't the first time we've heard about OBJ conversion so I
thought maybe it was time to add it.

I have in place the code to generate the OBJ file output which matches
the script output. I started off2obj from a copy of off2crds, then it
calls a new line of functions which mirror the off2crds pathway.

In off2crds, significant digits is hard coded to 17 while the other code
has the built in definition. I used the definition in off2obj but do you
want it as 17 in off2crds or is that an oversight? If so, I can change
it to the definition when pushing everything else.

In off_write in off_polys_write you have an offset. This appears to be
if you want to start indexing faces from something other than zero (I
used an offset in the code for OBJ since indexes start from 1). But for
colored vertices it doesn't add the offset. Looking at the code closer I
am not sure what this offset was for so I didn't change it.

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 10 Oct 2014, Roger Kaufman wrote:
> In off2crds, significant digits is hard coded to 17 while the other code has
> the built in definition. I used the definition in off2obj but do you want it
> as 17 in off2crds or is that an oversight? If so, I can change it to the
> definition when pushing everything else.

If you could change it to the common value, that would be better.

> In off_write in off_polys_write you have an offset. This appears to be if you
> want to start indexing faces from something other than zero (I used an offset
> in the code for OBJ since indexes start from 1). But for colored vertices it
> doesn't add the offset. Looking at the code closer I am not sure what this
> offset was for so I didn't change it.

The base function for writing a file will write a number of
geometries to the file without combining them first. The offset
is for renumbering the face vertices of geometries that follow
the first.

However, from a quick look, there is currently no code that writes
more than a single geometry at a time, which is probably why the
issue with coloured vertices hasn't been noticed. The fix should
just be to add the offset, as with the other elements, if you
want to change it, e.g.

fprintf(ofile, "1 %d %s\n", mi->first+offset, off_col(col_str, mi->second));

[Roger Kaufman]

Hi Adrian,

On 10/10/2014 1:38 PM, Adrian Rossiter wrote:
>
> (off2crds) If you could change it to the common value, that would be
> better.
>
>

> fprintf(ofile, "1 %d %s\n", mi->first+offset, off_col(col_str,
> mi->second));
>
>

I made these changes.

I added off2obj and its supporting code. I didn't know what to add for
the supporting help page but this could be a copy of what we have for
off2crds with a bit of text change.

I see we still have off2m and m2off. I haven't put up a web page in
quite a while but I am wondering what the state of the art is for
similar web graphics. The m files were for livegraphics3d as I remember.
Since I still have pages using it so support for m files is still
convenient.

Roger

[Adrian Rossiter]

Hi Roger

On Friday, 10 October 2014 23:06:23 UTC+2, Roger Kaufman wrote:

I added off2obj and its supporting code. I didn't know what to add for
the supporting help page but this could be a copy of what we have for
off2crds with a bit of text change.

I have just had a look at this and noticed that Meshlab won't read
converted OFF files that include coloured edge or vertices.

This is reasonable if they want to insist on valid files, as according to
the specification

     http://www.martinreddy.net/gfx/3d/OBJ.spec

Faces specified with 'f' with must have at least three vertices.

However, vertices and edges can still be included, and specified with
'p' and 'l'. Meshlab will ignore these elements, but they will be available
for any other program that can use them.

Example OFF:
OFF
3 3 0
1 1 0
1 0 0
0 1 0
3 0 1 2 1.00000 0.00000 0.00000
2 0 1 0.00000 1.00000 0.00000
1 0 0.00000 0.00000 1.00000

Current conversion:

# File type: ASCII OBJ

v 1 1 0
v 1 0 0
v 0 1 0
f 1 2 3

f 1 2
f 1

Suggested conversion:

# File type: ASCII OBJ

v 1 1 0
v 1 0 0
v 0 1 0
f 1 2 3
l 1 2
p 1


I also let Meshlab know about the problem importing valid OFF files which
have face elements with less than three vertices

   http://sourceforge.net/p/meshlab/bugs/413/

Adrian.

[Roger Kaufman]

Hi Adrian,

On 10/31/2014 8:13 AM, Adrian Rossiter wrote:
> Suggested conversion:
> # File type: ASCII OBJ
> v 1 1 0
> v 1 0 0
> v 0 1 0
> f 1 2 3
> l 1 2
> p 1

Putting 'f' in front of every line seemed odd. I originally looked at
the format here

http://en.wikipedia.org/wiki/Wavefront_.obj_file

I pushed the change for edge and vertex lines to the above format

Roger

[Adrian Rossiter]

Hi Roger

On Fri, 31 Oct 2014, Roger Kaufman wrote:
> http://en.wikipedia.org/wiki/Wavefront_.obj_file
>
> I pushed the change for edge and vertex lines to the above format

I added in the extra documentation and pushed all the changes.