3D files

for testing viewers and converters
- on Linux

Formats such as 3ds, dxf,
iv, obj, ply, stl, vrml-1, vrml-2, vtk


'glc_player' screenshot

Home > RefInfo menu > Computer topics menu > Linux Notes/Guides by 'Blaze' menu >
3D tools (viewers & converters) Introduction/Menu page >
This 3D test/demo files (local-access) notes page

!Preliminary! A few more 3D file types, with test file links, may be added.
And a few more test file links may be added for the types shown now.

Someday I may put some small image files beside the 3D file links.
And I may add some info like number of points or faces (polygons) beside ALL the links.
And I may replace some of the cruder sample files with better ones.

Furthermore, there are some 'remote view' issues, with web browsers.
I am documenting those issues, for each 3D file type,
on a separate 3D-files-remote-access web page.

< Go to web browser 3D-Helper-App Setup description, below. >
(in the Introduction)

< Go to Table of Contents, below. >
(Skip Introduction)

Introduction :

This is a page of links to 3D files --- files that can be used to test 3D viewer programs and 3D converter programs.

The file links are grouped into 3D file formats such as :

It was pointed out on the parent page of this page (an intro to 3D viewers and converters) that, on Linux (Ubuntu), we were able to quite easily install the following programs for viewing these types of files --- thanks to the Ubuntu Software Center, apt-get, and Gdebi.

  • glc_player which reads-and-shows '.3ds', '.obj', '.stl' files

  • ivview which reads-and-shows '.iv' and VRML1 files

  • paraview which reads-and-shows '.ply' and '.vt*' files

  • whitedune which reads-and-shows (and edits) VRML2 files

  • varicad-view which reads-and-shows '.dwg', '.dxf' (2D only?), '.igs' (maybe), '.stp' (3D) files

  • g3Dviewer which is said to read-and-show the many 3D file formats supported by the LibG3D library, which includes '.3ds', '.lwo', '.obj', '.dxf', '.md2', '.md3', '.wrl', '.vrml', '.dae' (COLLADA), '.ase' (ASCII Scene Exporter), '.ac' (AC3D) --- but I have not tried 'g3dviewer' on all of these formats yet. The viewer capabilities seem to be rather minimal compared to 'glc_player' or 'paraview'.

  • The mm3d modeller loads quickly and is said to read-and-show '.obj' and '.dxf' (3D) files as well as about 7 others including '.md2', '.md3', and '.lwo'.

  • The wings3D modeller will read-and-show '.obj' and '.3ds' files.

  • The K3D modeller will read '.obj' and '.off' files.

  • The Blender modeller will read '.obj' and '.3ds' files via scripts developed by the Blender community.

  • geomview will read-and-show the OFF file format.


3D screen shots :

A few images on this page (above and below) show these 3D viewers with a 3D test file being shown. These are actually images from the 3D viewers running on my Ubuntu 9.10 Linux desktop computer.


'ivview' screenshot


'paraview' screenshot


Viewing 3D files via your web browser :

The test 3D files at the links (far) below can be downloaded to your computer by right-clicking on the links and choosing an option like 'Save Link Target As ...' (in the pop-up menu that appears) to save the 3D file to a local directory. Then you can view a downloaded 3D file with an appropriate 3D viewer running on your machine --- that is, WITHOUT a web browser.

OR, if you have established 'Helper Applications' for viewing these 3D file types, via your web browser, you can simply click on these links to view them via your web browser and the helper applications. (I have provided detailed help on setting up the 'helper apps' for many 3D file types below --- including some screenshots.)

Well, I should say, local-viewing-of-these-3D-files-via-web-browser can be made to work, BUT ... remote-access-via-the-web-browser works for SOME of the 3D files, when they are on the remote server rather than downloaded to your local file storage. HERE'S THE PROBLEM.


The SAD STATE of the web-server-AND-web-browser brain-damaged 'dance' :
(Who's leading who?)

    Basically, there are four different types of responses when you click on a 3D file link (after you have set up the helper applications for each 3D file type, as described below) :

    1. the 3D file is shown in the helper application

        This is what we want!

    2. the 3D file is shown as alphanumeric characters and other characters, in a new (cleared) web browser window

        If the file is 'ascii', the text is readable. If the file is 'binary', the characters look like a bunch of gobbledy-gook. If we wanted to look at the characters/bytes in the file, we could have downloaded the file and looked at it with a text editor like 'gedit' or a binary editor like 'bless'.

        We want the file to be passed to the helper app we set up. The natural response of the user is 'What the fah? How do I get the file to show up in my helper app?'

        The web browser developers blame the web server administrators. This is a bunch of BS. Getting a web server admin to change a 'mime-type' definition in some web server config file is not a proper solution. The admins have more important things to do than maintain a config file of more than a thousand file types --- and more file-types being added every month, sometimes with a suffix already used for another file type (not just 3D file types).

        The web browser (and the web server) should be paying attention to the 'type=' statement in the web page developer's web page link --- BEFORE deciding on the file type according to some web server config file that cannot know the file type better than the web page developer.

        And the web server should be passing the file to the web browser as a data stream that preserves all the data in the file --- without deciding to change the data according to the type the web server THINKS the file is. For example, a web developer should not have to try to fool the web server into sending a file as binary data to work around the fact that the web server thinks that the file contains ascii-only data. I have encountered this situation, in a couple of different file-type cases.

        If this IS a problem that requires protocol changes by BOTH the web browser developers (e.g. Mozilla) and the web server developers (e.g. Apache), then someone needs to clarify or change the protocol specifications that they are following in their development processes.

        Another way of looking at it: The current system was designed to support web developers who are developing pages to be 'pushed down' from the web server --- especially 'active' pages that use CGI and PHP scripts that have control on what happens on the server side. The specifications writers have not done a good job of thinking about the web developers who upload their web pages and other files to the web server --- web page developers whose pages work almost totally from the client side.

    3. the web browser pops open a 'Save file' dialog window

        We could have done that by rightclicking on the link and choosing 'Save Link Target As ...' from the popup window. So that's no help at all.

        Again, the user response is 'How the f**k do I get the file passed to my helper app?' I don't have an answer for you, yet --- other than download the file onto your local file storage and use the appropriate viewer. I.e. fagedabout putting the web browser or the (remote) web server in the mix. It's just too frustrating. And it should not be that way.

    4. the web browser pops open an 'Open-with-OR-Save-file' dialog window

        That's a heck of a lot better than response 2 or 3. In fact, it's as good or better than response 1. In fact, I would be glad if the web browser that I use, Mozilla Seamonkey, would always respond this way, when I click on ANY media file link other than '.html', '.htm', '.php', ... and several other file types in 'anchor' statement href's that the browser should render automatically, ordinarily, in its own window.

        Then I could decide which of many possible Helper-Apps I want to use to process the media file --- OR, I could choose to save the file locally.

    It turns out that if you download this web page and its 3D files to your computer, you could see all these 3D files with no problem (in most GUI web browsers), simply by clicking on their links in the web page --- if you set up the helper applications as I describe below.

    That is, you would get response 1 or 4 above.

    BUT, it turns out that if you try to view some of these 3D files via this web page, as the 3D files and this web page are (i.e. by accessing the 3D files remotely, on this remote web server), many of these files will not be passed into your helper apps.

    That is, you would get response 2 or 3 above.

    I have started a 3D-files-remote-access notes web page. On that web page, I plan to collect notes on all the brain-damaged things (especially cases 2 and 3 above) that occur with various 3D file types. I will collect notes on various experiments with different HTML link statements --- file suffixes and 'type=' statements --- experiments done with the Seamonkey2 or Firefox (or other) web browsers.

    Perhaps I can find a 'work-around' so that most (or all) of the 3D file types can be displayed in helper apps of the user's choosing --- from almost any web server --- or, at least, from this web server.

    'Kiosk' mode :

    It turns out you CAN get the helper apps working just fine --- IF you resign yourself to working in a 'kiosk' mode. That is, let us say that you want to 'publish' your 3D files on a machine that you install at a store or a conference exhibition hall or wherever. Then you can install your 3D files --- and the web page(s) and web browser and 3D viewers for viewing those files --- on a stand-alone machine.

    In other words, we take the remote web server and its typically brain-damaged config files and its bad logic out of the picture. Following is a description of how to set up that 'kiosk'.


Defining web browser 'Helper Applications' for these 3D files :

I installed applications on Ubuntu Linux (9.10) that work as viewers for most of the 3D file types listed above.

I was able to define viewers for many of these file types in the Seamonkey 2.x web browser that I use. Here are notes on how I did that. This will probably work in other Mozilla-type web browsers, like Firefox.

When I first made links to the 3D files on this web page, I did not put a 'type=' specifier in the HTML 'anchor' statements. They looked like

 <a href="... file-path-and-name-here ..."> ... filename-here ...</a>

When I clicked on '.obj' and '.ply' file links, their text contents were simply shown in the web browser window --- instead of the browser offering me the 'Open-with' window to setup a 'helper app' for these file types --- such as 'glc_player' for '.obj' files and 'paraview' for '.ply' files. (More on defining the 'glc_player' helper app for '.obj' files below, complete with screenshots.)

To try to deal with this 'text-display' problem, I added 'MIME' qualifiers like

 type="application/wobj"
and
 type="application/ply"

to the 'anchor-href' statements for the '.obj' and '.ply' files.

Example:

<a href="./obj/archer.obj" type="application/wobj">archer.obj</a>

(See the section below for info on 'mime-types'.)

Then, when I clicked on the file link to a local '.obj' file, instead of getting text-display, I got the Seamonkey 'Open-with-OR-Save-as' prompting popup window.

I chose 'Open-with', and I was able to set 'glc_player' as the viewer (helper) for ALL the '.obj' files --- referred to in the HTML 'anchor' link statements on the web page.

I just needed to click a check-box on that prompting window. The checkbox was labelled 'Do this automatically for files like this from now on'.

You need to get to that 'Open-with' prompting popup window in order to define helper applications for files referenced in web pages. At least, that's how it is done in the Mozilla Seamonkey2 web browser.


An aside on 3D MIME types :

    See the list, below, of some 'mime types' that are said to be useful for some 3D file types --- according to sites like htmlquick.com/reference/mime-types.html.

    MIME = Multipurpose Internet Mail Extensions --- a messaging standard that allows Internet users to exchange e-mail messages enhanced with graphics, video, and voice as attachments to the body of the text.

    Paraphrasing some text at htmlquick.com :
    "MIME is a standard that classifies resources and provides information to programs about how to handle them. It is recommended to provide MIME type information everywhere possible --- for example, with the 'type=' attribute in HTML link tags --- in HTML documents. This may help with browser compatibility and facilitate the correct functionality of the document."

    (A natural question is 'What does mail have to do with web pages?' Apparently, when HTML came along, the MIME standard was applied to web pages. Note: I use the word 'standard' loosely here. It's not so much a standard as a cobbled-up mess, when you get away from some commonly used media types.)

    Published mime indicators for 3D files :

    • .3ds  - ?
    • .blend - ?
    • .dwf  - drawing/x-dwf  -OR-  model/vnd.dwf
    • .dwg  - application/acad  -OR-  image/x-dwg  -OR-  image/vnd.dwg
    • .dxf  - application/dxf  -OR-  image/x-dwg  -OR-  image/vnd.dwg
    • .igs  - application/iges  -OR-  model/iges
    • .iv   - application/x-inventor
    • .md2  - ?
    • .md3  - ?
    • .off  - ?
    • .obj  - ?
    • .ply  - ?
    • .pov  - model/x-pov
    • .stl  - application/sla
    • .stp  - application/step
    • .vrml - application/x-vrml  -OR-  model/vrml  -OR-  x-world/x-vrml
    • .vtk  - ?
    • .wrl  - application/x-world  -OR-  model/vrml  -OR-  x-world/x-vrml
    • .wrz  - x-world/x-vrml OR model/vrml

    You could do a search for other pages listing 3D mime types via a Google search on keywords such as mime type dwg dxf igs iv stl stp wrl.

    Note that even though there do not seem to be sanctioned mime-type indicators for '.obj' and '.ply' files, my attempt at using 'application/wobj' and 'application/ply' proved to be successful (at least when the files were stored locally; NOT when on a remote web server, as I found out later). See my example, below, of setting a 'helper app' for the '.obj' suffix --- with screenshots for the several steps.

    With respect to VRML file formats (and the suffixes '.wrl', '.vrml', '.vrm'), there seems to be a lot of confusion (and resulting complications) within the systems in web browsers that set 'helper applications' for the VRML1 and VRML2 file types.

    As a consequence, in this web page,

    • for VRML1 files, I have used the suffix '.vr1' in their filenames and, in the HTML 'anchor' statement for these files, I have used type="application/vr1".

    • for VRML2 files, I have used the suffix '.vr2' in their filenames and, in the HTML 'anchor' statement for these files, I have used type="application/vr2".

    (There's more on the '.wrl', '.vrml', '.vrm' confusion, at the 'Choose Helper Application' screenshot below.)


      A further aside on the sad state of helper application management in web browsers :

      The web browser developers do not seem to want to give the users better control (and better flexibility) over setting the 'helper applications' for various file suffixes.

      They could solve most of the problems we encounter with setting helper apps, if they would devise a system for 'opening' files like the system used in GUI file managers, like Gnome-Nautilus.

      In Gnome Nautilus, if you double-click on a file, it is 'opened' in a default application. BUT, IF YOU WANT TO OPEN THE FILE IN ANOTHER APPLICATION, you can right-click on the file and there is an 'Open-with' option.

      Here is a screenshot of a Nautilus 'right-click Open-with' popup window.

      Note that Firefox is the default open-with application for the '.fonts.conf' file on which I right-clicked. That is a rather heavy-handed default app, but note that I can use a different app by using the Nautilus 'Open with' option.

      Similarly, web browsers should allow for a 'right-click Open-with' option, for web page links. Then we users could specify one (or more) apps per file suffix --- and per file type in the 'type=' statement of the web page, if the 'type=' parameter is there.

        In fact, we should even be able to right-click on a link to a '.html' or '.htm' or '.php' file and choose to open it in a web browser other than the one we are currently using. This is the kind of freedom we should have, and there is no technical reason why that cannot be done.

      For example, the user should be able to specify a default open-with app for file suffix '.obj' --- and for file suffix '.obj' and type='application/wobj' or type='model/obj' or whatever one might encounter as a 'type=' parameter in a web page (or from a web server) on any given day.

        In fact, the use of the slash ( / ) in the 'type=' statement is rather lame. I should be able to use almost any string, of reasonable length, such as 'Wavefront-obj'.

      Even if a default app has been defined for a file type, the web browser should allow the user to select which of several apps to use when the user right-clicks on a media file 'anchor-href' link. That is, the web browser should always offer an 'Open-with' dialog as an option.

      In fact, here is a screenshot showing that 21 apps (and more) are being offered by Nautilus, to open the '.fonts.conf' file. That's a bit of overkill --- but it's certainly better than not being able to view the file in an appropriate viewer at all.

      Of course, in addition to the very flexible Open-with dialog, the web browser developers should allow the users an option to reset the default 'open-with' app.

      Basically, we Seamonkey2 users need an 'Open-with' option added to this right-click-on-a-link popup menu.

      We can specify where to 'Save' the file, with 'Save Link Target As ...', but we have no option to specify how to 'Open' the file. The Open options that are there now are lame. They open the file in the 'New Window' or 'New Tab' according to the currently screwed-up 'dance' between web server and web browser. Those Open options do not allow the user to override a stupid 'Open-with' choice made by the brain-damaged 'partnership' of the web-server and the web-browser.

      One other case of web-browser inflexibility: Once you have defined a new suffix and helper app, you cannot delete that suffix and helper definition from the 'Helper Applications' window. (Not in Seamonkey2 anyway. And probably not in Firefox.) You presumably would have to resort to editing the underlying 'mimeTypes.rdf' file.

      The developers (and testers) seem to have sadly neglected the Helper Application area of web browsers --- except to hard-code in the helpers they want to provide.

      If you want to get an idea of the confusing state of things in the 'helper application' area, and if you use the Firefox or Seamonkey web browsers, look at the file named 'mimeTypes.rdf', in the directory $HOME/.mozilla/firefox/random8chars.default or $HOME/.mozilla/seamonkey/random8chars.default .

      For example, they put 'vrm' suffixes in the file, in addition to 'wrl' and 'vrml', whether we want them or not --- and essentially made them all equivalent, with respect to which viewer to use for those file suffixes.

         <RDF:Description RDF:about="urn:mimetype:x-world/x-vrml" 
                          NC:description="" 
                          NC:value="x-world/x-vrml" 
                          NC:editable="true"> 
           <NC:fileExtensions>wrl</NC:fileExtensions> 
           <NC:fileExtensions>vrm</NC:fileExtensions> 
           <NC:fileExtensions>vrml</NC:fileExtensions> 
           <NC:handlerProp RDF:resource="urn:mimetype:handler:x-world/x-vrml"/> 
         </RDF:Description>
      ...
      ...
         <RDF:Description RDF:about="urn:mimetype:model/vrml" 
                          NC:description="" 
                          NC:value="model/vrml" 
                          NC:editable="true"> 
           <NC:fileExtensions>wrl</NC:fileExtensions> 
           <NC:fileExtensions>vrml</NC:fileExtensions> 
           <NC:fileExtensions>vrm</NC:fileExtensions> 
           <NC:handlerProp RDF:resource="urn:mimetype:handler:model/vrml"/> 
         </RDF:Description> 
      

      In a more perfect world, we wouldn't have any of those three suffixes in our mime types file(s). We would be providing those suffixes if we were going to use them --- and we would be using suffixes that clearly indicate whether the file is a VRML1 or a VRML2 file --- such as '.vr1' or '.vr2'.

      After seeing this kind of confusion in browser config file statements, I can see why VRML (either 1 or 2) was doomed.

      See a couple of rants on VRML1, VRML2, and X3D in my VRML1 and VRML2 (and X3D) Notes page.


An example of setting a Helper App (in Seamonkey) :

Here are some images that show the process of setting a Helper App (glc_player) for Wavefront '.obj' files --- for the Seamonkey 2.x web browser.

In this first image, I clicked on a '.obj' file link, in an early version of this web page (before my rants above were added), and the 'Opening' popup window appeared --- with a 'Browse...' button next to the 'Open with' radio-button.

In this next image, I have clicked on the 'Browse...' button and I am using the 'Choose Helper Application' window that popped up to choose a program to use to 'play' (view) the '.obj' file --- by navigating to the '/usr/bin' directory.

    Unfortunately, the web browser developers do not trust us to key in a string like '/usr/bin/glc_player'. They require us to navigate to the /usr/bin directory.

In this next image (further below), I have clicked on the 'Open' button of the 'Choose Helper Application' window, and I have been returned to the 'Opening' window, which now shows that I have chosen 'glc_player' for the 'Open with' option. At this point, I click on the 'OK' button --- after clicking on the little checkbox.

By clicking on the 'OK' button, TWO things happen. The '.obj' file is shown in the viewer that I chose --- but ALSO the viewer that I chose is 'registered' as the app to use whenever I click on a '.obj' file link --- because I checked the box labelled 'Do this automatically for files like this from now on' in the 'Opening' window.

    (This 'registration' works if web pages and/or web sites have been set up to define the '.obj' file type appropriately --- whatever that may mean in various environments. That means to say that I am not sure of all the if's, and's, and but's to make the viewer chosen take effect in all cases/situations.

    For example, I ended up renaming VRML1 and VRML2 files with '.vr1' and '.vr2' suffixes because of some pre-definitions for '.vrml', '.vrm', and '.wrl' files in the Mozilla 'mimeTypes.rdf' file. Those 'pre-set' RDF declarations seemed to cause confusion in picking the Helper Apps that I set up for '.vrml' and '.wrl' files. I was getting the helper app (ivview) that I set up for VRML1 files (.vrml), when I clicked on a '.wrl' VRML2 file, for which I set 'whitedune' as the helper app.

    For your convenience, here is a sample Mozilla 'mimeTypes.rdf' file for your perusal. Amazingly, Seamonkey does not make backups of this file as it is changed. A few backups --- or a copy of the original --- would be nice. If that file ever gets screwed up, I might have to do surgery with a text editor --- even though I am sure the developers would say that this file should only be changed by the logic in the browser. By the way, I made a backup of that file today, with today's date in the backup filename.)




The following images show the results of setting up Helper Apps for various types of 3D files.

We are looking at the results of our 'Choose Helper Application' actions --- by using the 'Edit > Preferences > Helper Applications' panel in Seamonkey.

We are looking to see what helper applications have been set up for '.3ds', '.dwg', '.iv', '.stl', '.wrl', and other 3D files.

In the next image, I have clicked on the 'Edit' toolbar option in Seamonkey, and the popdown Edit options window has appeared, with 'Preferences...' at the bottom.

In the next image, I have clicked on the 'Preferences...' line in the 'Edit' popdown menu, and the 'Preferences' panel came up. I clicked on the 'Browser' category in the 'Category' list on the left of the 'Preferences' panel. That caused the 'Browser' sub-categories to be shown --- which includes the 'Helper Applications' sub-category.

In the next image, I have clicked on the 'Helper Applications' sub-category and the 'Helper Applications' sub-panel has appeared on the right of the 'Preferences' panel.

In the list on the right, you can see that

  • for '3DS file', the 'Action' is 'Use glc_player'
  • for 'DWG file', the 'Action' is 'Use varicad-view'
  • for 'DXF file', the 'Action' is 'Use varicad-view'
  • for 'IV file', the 'Action' is 'Use ivview'

In the next image, I have selected the '3DS file' line and the 'Helper Applications' list has spread out into a double-spaced format. (I do not know if this is a minor bug or a 'feature'.)

In the next image, I have moved down the 'Helper Applications' list in the Seamonkey 'Preferences' panel, and I have clicked on the 'DWG file' line.

Note that a 'popdown' indicator has appeared at the 'Use varicad-view' field of the 'Action' column.

I could use this popdown to change the 'helper application' = 'player' = 'viewer' of DWG files.

In the next image, I have moved further down the 'Helper Applications' list in the Seamonkey 'Preferences' panel, and you can see that, similarly, I could change the viewer/player of IV files.

In the next image, I have scrolled down the 'Helper Applications' list in the Seamonkey 'Preferences' panel, and you can see that

  • for 'PLY file', the 'Action' is 'Use paraview'
  • for 'STL file', the 'Action' is 'Use glc_player'

In the next image, I have scrolled down to the bottom of the 'Helper Applications' list in the Seamonkey 'Preferences' panel, and you can see that

  • for 'VRM file', the 'Action' is 'Use ivview'
  • for 'WRL file', the 'Action' is 'Use whitedune'

Actually, the 'VRM file' seems to refer to either '.vrml'-suffixed files or '.vrm'-suffixed files --- I am not sure which one, or both.

Many people use the same suffix --- '.wrl' --- for VRML1 and VRML2 files. For this web page, to allow for using separate viewers for the two file formats, I first used a '.vrml' suffix for VRML1 files, and '.wrl' for VRML2 files. But that led to viewer-association problems that I mentioned above.

After I changed the '.vrml' suffixes to '.vr1' and '.wrl' to '.vr2', and after I set up the 'ivview' and 'whitedune' programs to be their viewers, respectively, two new lines appeared in the Helper Apps list (not shown in the image below) :

  • for 'VR1 file', the 'Action' is 'Use ivview'
  • for 'VR2 file', the 'Action' is 'Use whitedune'

In the next image, on the 'WRL file' line, I have actually clicked on the popdown-indicator at 'Use whitedune'. You can see that the popdown shows options such as 'Always ask', 'Save File', and 'Use other ...'.

With 'Use other...', I could specify a different or additional viewer for 'WRL file' --- such as a text editor, like 'gedit'.

And with 'Application Details ...', I could remove 'whitedune' as a viewer option.

    You can remove a helper application for a file type (suffix, mime-type, whatever), but the developers did not provide a way to remove an entire 'content type' definition. (At least, not in Seamonkey --- and probably not in Firefox.) I believe I have seen a Remove (content-type) option in some old web browser --- perhaps in an old version of Netscape. As indicated above, you might have to edit the 'mimeTypes.rdf' file to remove a content-type definition and 'start fresh'.




Quick guide to using the 3D viewers :

Each of the 3D viewers has a different way of doing the 3 basic viewing operations --- rotate, pan, and zoom --- and different ways (if any) of quickly restoring the model to the center of the viewport, filling the viewport.

Someday, I may put a link to a page of those view methods, for each 3D viewer, here.

For now, there are some brief descriptions below, for 'glc_player', 'varicad-view', 'paraview', 'ivview', and 'whitedune'. Search for the keyword 'rotate'.


And now, on to the test/demo files :

I made this page so that I can access these files (and these notes) on any of my computers --- whether at home or away. But others may find these files (and notes) useful.

You can use the Table of Contents, below, to jump to a particular group of files. Or simply scroll down this page.

Table of Contents :

(These links take you to groups of 3D file links, further down this page.)

< Go to Top of Page, above. >

  • '.3ds' sample files (3D Studio)

  • '.blend' sample files (Blender)

  • '.csv' sample files (comma separated values)

  • '.dwg' sample files (Autodesk)

  • '.dxf' sample files (Autodesk)

  • '.igs' sample files (IGES, 2D CAD)

  • '.iv' sample files (SGI Inventor)

  • '.md2' sample files (MD2 Quake)

  • '.obj' sample files (Alias/Wavefront OBJ format)

  • '.off' sample files (Object File Format)

  • '.ply' sample files

  • '.pov' sample files

  • '.stl' sample files (STereoLithography)

  • '.stp' sample files (STEP)

  • '.vtk' sample files (Kitware's Virtual Tool Kit)

  • '.vr1' sample files (VRML1 - a subset of the SGI Inventor 2 format)

  • '.vr2' sample files (VRML2, a.k.a. VRML97)

  • '.x3d' sample files (essentially VRML2 wrapped in XML)

End of Table of Contents. Links to 3D files are below.


'whitedune' screenshot

Start of the Links to 3D files :

GROUP - 3ds : (3D Studio files)

< Return to Table of Contents, above. >

These '.3ds' files are showable by 'glc_player'.

In the following 'anchor' link statements for sample '.3ds' files, I have used application/3ds for the 'type=' parameter value.

After setting up the 'helper application' for these '.3ds' files, using the 'Open-with' dialog of the Seamonkey2 web browser, I had the following 3ds-related statements in my 'mimeTypes.rdf' file :

  <RDF:Description RDF:about="urn:mimetype:externalApplication:application/3ds"
                   NC:path="/usr/bin/glc_player"
                   NC:prettyName="glc_player" />
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/3ds" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/3ds"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:application/3ds" 
                    NC:value="application/3ds" 
                    NC:editable="true" 
                    NC:fileExtensions="3ds" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/3ds"/> 
   </RDF:Description> 

When I click on one of these '.3ds' file links, in local 'kiosk' mode, the 'glc_player' program starts up and shows the '.3ds' file.

At the top right of the 'glc_player' viewing window are three icons for pan, rotate, and zoom. Click on any one of these icons and then click in the viewing window and drag the mouse around, to perform the chosen function.


geom_box.3ds
(0.6 KB)

geom_sphere.3ds
(4.3 KB)

geom_cone.3ds
(5.4 KB)

teapot.3ds
(28 KB)

sink.3ds
(30 KB)

knot.3ds
(52 KB)

iron.3ds
(124 KB)


    NOTE: The following fish and flower '.3ds' files (and their accompanying '.bmp' texture files), were found at toucan.co.jp. Many more such files can be found there.

    I found that running 'glc_player' in my web browser (Seamonkey) caused the texture files to be ignored (not found?) --- when I access the '.3ds' files remotely. Instead of a colored image, like the glc_player screenshot at the top of this page, I ended up with silver (or light gray) fish and flowers. This is no doubt happening because only the '.3ds' file is copied locally (in /tmp) for viewing --- but not the associated '.bmp' file.

    When I start my Seamonkey web browser on the locally stored web page and click on the link to '.3ds' files (stored locally, with the '.bmp' files in the same directory), the 'glc_player' helper application DOES show the texture-mapped model.

    Also, when I run 'glc_player' on these files without the web browser (for example, by using Nautilus to navigate to the directory containing the files, and right-clicking on the '.3ds' file to open the file with 'glc_player'), the '.bmp' texture file IS 'mapped' onto the 3D model. The only requirement is that the '.bmp' file has to be in the same directory with the (binary) '.3ds' file.

    If your web browser downloads the '.3ds' file to the '/tmp' directory before starting up the helper app to view the file, you could probably see the texture mapping if you would download the associated '.bmp' file into your '/tmp' directory.


fish_Kumanomi0.3ds
(151 KB)

KumanoT.bmp (colored BMP file that goes with the fish file above)
(384 KB)


fish_Rantyu0.3ds
(152 KB)

RantyuT.bmp (colored BMP file that goes with the fish file above)
(192 KB)


fish_BlueTang0.3ds
(156 KB)

BlueTaT.bmp (colored BMP file that goes with the fish file above)
(384 KB)


flower_YukiTubaki0.3ds
(312 KB)

YukiTuT.bmp (colored BMP file that goes with the flower file above)
(192 KB)


flower_HimawariS.3ds
(341 KB)

HimawaT.bmp (colored BMP file that goes with the flower file above)
(192 KB)


GROUP - blend :

< Return to Table of Contents, above. >

The following '.blend' files are showable by 'blender'.

In the following 'anchor' link statements for sample '.blend' files, I did not use a 'type=' parameter value.

The following blender-related statements are in my 'mimeTypes.rdf' file :

  <RDF:Description RDF:about="urn:mimetype:application/x-blender"
                   NC:value="application/x-blender"
                   NC:editable="true"
                   NC:description="Blender scene">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-blender"/>
  </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/x-blender" 
                    NC:alwaysAsk="false" 
                    NC:useSystemDefault="true">
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/x-blender"/>
   </RDF:Description>

In spite of no 'type=' qualifier in the '.blend' anchor-link statements of this web page and no 'NC:path=' statement for 'application/x-blender' in the 'mimeTypes.rdf' file, when I click on these '.blend' links, in local 'kiosk' mode, the Blender program is started and the model is displayed.

What the .... ? Is Seamonkey2 using the default 'player' for '.blend' files as defined in the Nautilus file manager on my development computer? I will have to try more experiments, perhaps on some of my other computers, to experiment with this web page and these '.blend' files.

At least the files are being 'played'. So this situation is not a problem. It's a mystery.


armature_elbow_cap.blend
(112 KB)

Combatknife2uv19.blend
(113 KB)

parametric_stairway3.blend
(132 KB)

parametric_objects_1.blend
(145 KB)

playboard.blend
(187 KB)

sitters_faces.blend
(554 KB)


GROUP - csv : (comma separated values)

< Return to Table of Contents, above. >

CSV [ Comma Separated Values ] files are showable by 'paraview --data=', if the file contents are formatted properly --- like the example below.

In the following 'anchor' link statements for sample '.csv' files, I did not use a 'type=' parameter value.

When I click on a '.csv' link, in local 'kiosk' mode, I get the Seamonkey2 'Open-with' dialog.

I will try setting up 'paraview --data=' as the viewer and see what gets put in the 'mimeTypes.rdf' file.

There are no csv-related statements in my 'mimeTypes.rdf' file. This is not really surprising, since I did not set up a viewer for '.csv' files using the Seamonkey2 'Open-with' dialog.

Check back later --- or perform your own experiments.


xyz_3lines.csv


GROUP - dwg :

< Return to Table of Contents, above. >

These '.dwg' files (2D) are showable by 'varicad-view'.

In the following 'anchor' link statements for sample '.dwg' files, I have used application/acad for the 'type=' parameter value.

After setting the 'helper application' for these '.dwg' files to be 'varicad-view', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following dwg-related and acad-related statements in my 'mimeTypes.rdf' file :

  <RDF:Description RDF:about="urn:mimetype:application/acad"
                   NC:fileExtensions="dwg"
                   NC:description=""
                   NC:value="application/acad"
                   NC:editable="true">
    <NC:handlerProp RDF:resource="urn:mimetype:handler:application/acad"/>
  </RDF:Description>
...
...
  <RDF:Description RDF:about="urn:mimetype:externalApplication:application/acad"
                   NC:path="/usr/bin/varicad-view"
                   NC:prettyName="varicad-view" />
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/acad" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/acad"/> 
   </RDF:Description> 

When I click on one of these '.dwg' file links, in local 'kiosk' mode, the 'varicad-view' program starts up and shows the '.dwg' file.


harley_logo.dwg
(29 KB)

pr-4000d.dwg
(104 KB)

pr20ed.dwg
(164 KB)


GROUP - dxf :

< Return to Table of Contents, above. >

These '.dxf' files (2D) are showable with 'varicad-view'.

In the following 'anchor' link statements for sample '.dxf' files, I have used application/dxf for the 'type=' parameter value.

After setting the 'helper application' for these '.dxf' files to be 'varicad-view', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following dxf-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:application/dxf" 
                    NC:value="application/dxf" 
                    NC:editable="true" 
                    NC:fileExtensions="dxf" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/dxf"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/dxf" 
                    NC:prettyName="varicad-view" 
                    NC:path="/usr/bin/varicad-view" /> 
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/dxf" 
                    NC:alwaysAsk="false"> 
     <NC:possibleApplication RDF:resource="urn:handler:local:/usr/bin/varicad-view"/> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/dxf"/> 
   </RDF:Description>

When I click on one of these '.dxf' file links, in local 'kiosk' mode, the 'varicad-view' program starts up and shows the '.dxf' file.


teeth_021_2Dsketch.dxf
(44 KB)

barchetta-logo_2Dsketch.dxf
(44 KB)

campus_2DmanINscene.dxf
(100 KB)

Lshape-1_2Ddemo.dxf
(162 KB)

harley_logo_2Dsketch.dxf
(195 KB)

scd430_2Ddetail.dxf
(263 KB)

fox_mx_2Dsketch.dxf
(361 KB)

inner_assemble_Sheet_1_2Ddetail.dxf
(615 KB)

comm-7_2Drooms-bldgs.dxf
(1,200 KB)

inner_assemble_Sheet_2_2Ddetail.dxf
(1,300 KB)

w-2512_2DdetailGerman.dxf
(1,700 KB)


GROUP - igs :

< Return to Table of Contents, above. >

IGES files are said to be showable by 'varicad-view', but I was not able to show the following IGES files with version 3.03 of 'varicad-view' that I installed on Ubuntu 9.10 using a '.deb' file from 'ftp.varicad.com' --- even if I tried using 'varicad-view' without going through this web page.

I get a 'Translation from IGES failed' popup window from 'varicad-view', when trying to read any of these '.igs' files.

The files look like typical IGES files when I look at them in a text file viewer.

In any case, I set up 'varicad-view' as the Seamonkey2 viewer for '.igs' files, as follows.

In the following 'anchor' link statements for sample '.igs' files, I have used application/iges for the 'type=' parameter value.

After setting the 'helper application' for these '.igs' files to be 'varicad-view', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following igs-related and iges-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:handler:application/iges" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/iges"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:application/iges" 
                    NC:value="application/iges" 
                    NC:editable="true" 
                    NC:fileExtensions="igs" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/iges"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/iges" 
                    NC:path="/usr/bin/varicad-view" 
                    NC:prettyName="varicad-view" /> 

If I find a viewer that works on these IGES files, I will try re-setting the Seamonkey2 viewer for these files. Clicking on these '.igs' file links, I DO startup the 'varicad-view' program, but it shows the 'Translation from IGES failed' popup message window, on each file.


adjust_part1_mir_050106.igs
(40 KB)

harley_logo.igs
(123 KB)

dragon_3.igs
(172 KB)

yamaha.igs
(195 KB)

space_shuttle.igs
(700 KB)

innerslab_050926.igs
(1,000 KB)

aircraft.igs
(1,300 KB)

inner_vessel_end_flange_mod.igs
(1,400 KB)

inner_vessel_040819.igs
(7,500 KB)

support_assembly.igs
(19,700 KB)

vessel_support_assembly.igs
(30,600 KB)


GROUP - iv :

< Return to Table of Contents, above. >

The following '.iv' files are showable with 'ivview'.

In the following 'anchor' link statements for sample '.iv' files, I have used application/iv for the 'type=' parameter value.

After setting the 'helper application' for these '.iv' files to be 'ivview', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following iv/ivview/inventor-related statements in my 'mimeTypes.rdf' file :

  <RDF:Description RDF:about="urn:handler:local:/usr/bin/ivview"
                   NC:prettyName="ivview"
                   NC:path="/usr/bin/ivview" />
...
...
   <RDF:Description RDF:about="urn:mimetype:application/x-inventor" 
                    NC:fileExtensions="iv" 
                    NC:description="" 
                    NC:value="application/x-inventor" 
                    NC:editable="true"> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/x-inventor"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/x-inventor" 
                    NC:path="/usr/bin/ivview" 
                    NC:prettyName="ivview" />
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/x-inventor" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/x-inventor"/> 
     <NC:possibleApplication RDF:resource="urn:handler:local:/usr/bin/ivview"/> 
   </RDF:Description>

When I click on one of these '.iv' file links, in local 'kiosk' mode, the 'ivview' program starts up and shows the '.iv' file.

    For some reason unbeknownst to me, even though the type 'application/iv' does not appear in the 'mimeTypes.rdf' file, the following '.iv' files are shown successfully with 'ivview'.

    The file extension 'iv' IS registered --- but under 'application/x-inventor'.

    I may try this setup on a different computer someday, to make sure of the steps that I went through to use type 'application/iv' to setup 'ivview' as the viewer of the '.iv' files. I will check the contents of the 'mimeTypes.rdf' file on that computer.

    Since the '.iv' files are shown successfully, this is not really a problem. But it IS a mystery, to me. The 'helper application' logic in web browsers should be documented. It might force the developers to take more care in the implementation of the 'helper application' logic.


diamond.iv
(1.7 KB)

windmill.iv
(2.2 KB)

cube_texture.iv
(3.0 KB)

dodec.iv
(3.7 KB)

dumbHead.iv
(4.5 KB)

bridge.iv
(8.8 KB)

human.iv
(9.2 KB)

tiler_3d.iv
(15 KB)

banana_binary.iv
(18 KB)

birdfeeder.iv
(24 KB)

jackInTheBox_binary.iv
(34 KB)

polyfish.iv
(34 KB)

sgilogo_binary.iv
(46 KB)

pear_binary.iv
(60 KB)

top_binary.iv
(65 KB)

dulcimer.iv
(116 KB)

chair_binary.iv
(131 KB)

pavilion_binary.iv
(224 KB)

z1_1.iv
(597 KB)

z2_1.iv
(597 KB)

z3_1.iv
(597 KB)

1923_inventor2.iv
(1,000 KB)

cd_1.iv
(1,700 KB)

clt_1.iv
(1,700 KB)

ctt_1.iv
(1,700 KB)


GROUP - md2 :

< Return to Table of Contents, above. >

The following '.md2' Quake game files can be shown with 'mm3d'.

In the following 'anchor' link statements for sample '.md2' files, I have used application/md2 for the 'type=' parameter value.

After setting the 'helper application' for these '.md2' files to be 'mm3d', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following md2-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:handler:application/md2" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/md2"/> 
   </RDF:Description> 
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/md2" 
                    NC:path="/usr/bin/mm3d" 
                    NC:prettyName="mm3d" />
...
...
   <RDF:Description RDF:about="urn:mimetype:application/md2" 
                    NC:value="application/md2" 
                    NC:editable="true" 
                    NC:fileExtensions="md2" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/md2"/> 
   </RDF:Description>

When I click on one of these '.md2' file links, in local 'kiosk' mode, the 'mm3d' program starts up and shows the '.md2' file.


MedicFemLacFace.md2
(13 KB)

MedicFemLacBody.md2
(61 KB)

power_female.md2
(103 KB)

power_male.md2
(103 KB)

knife.md2
(105 KB)


GROUP - obj :

< Return to Table of Contents, above. >

The following Wavefront '.obj' files are showable with 'glc_player'.

In the following 'anchor' link statements for sample '.obj' files, I have used application/wobj for the 'type=' parameter value.

After setting the 'helper application' for these '.obj' files to be 'glc_player', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following obj/wobj-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:application/wobj" 
                    NC:value="application/wobj" 
                    NC:editable="true" 
                    NC:fileExtensions="obj" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/wobj"/> 
   </RDF:Description> 
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/wobj" 
                    NC:alwaysAsk="false"> 
     <NC:possibleApplication RDF:resource="urn:handler:local:/usr/bin/glc_player"/> 
     <NC:possibleApplication RDF:resource="urn:handler:local:/usr/bin/gedit"/> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/wobj"/> 
   </RDF:Description> 
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/wobj" 
                    NC:prettyName="glc_player" 
                    NC:path="/usr/bin/glc_player" /> 

When I click on one of the following '.obj' file links, in local 'kiosk' mode, the 'glc_player' program starts up and shows the '.obj' file.

    Note that I also set up 'gedit' as an alternate helper application for 'application/wobj' files, as seen in one of the statements, above, in the 'mimeTypes.rdf' file. I can use the 'Edit > Preferences > Helper Applications' window of Seamonkey2 to access and execute this alternate helper app --- AND I can also specify 'Always ask' there, instead of defaulting to opening with 'glc_player'.


dodecahedron.obj
(1.0 KB)

spike.obj
(1.4 KB)

cube.obj
(1.5 KB)

dumbHead.obj
(6.8 KB)

female_head1a.obj
(22 KB)

shapee.obj
(28 KB)

pawn.obj
(48 KB)

slot_machine.obj
(99 KB)

drop_firebird.obj
(139 KB)

teapot.obj
(257 KB)

shape_irreal.obj
(259 KB)

ufo_condor.obj
(393 KB)

archer.obj
(406 KB)

berserker.obj
(433 KB)

dino.obj
(586 KB)

ducky.obj
(662 KB)

spaceship.obj
(787 KB)

cow.obj
(889 KB)

city.obj
(962 KB)

face.obj
(1,000 KB)

const.obj
(1,300 KB)

skeleton.obj
(1,500 KB)

bunker.obj
(1,500 KB)

car.obj
(2,100 KB)

duckyt.obj
(2,200 KB)

venusm.obj
(3,100 KB - more than 100 thousand polygons)

bunny.obj
(5,000 KB)

vcg_david_500k.obj
(17,600 KB - more than 500 thousand polygons - big)


GROUP - off : (Geomview Object File Format)

< Return to Table of Contents, above. >

The following '.off' files are showable with 'geomview'.

In the following 'anchor' link statements for sample '.off' files, I have used application/goff for the 'type=' parameter value.

After setting the 'helper application' for these '.off' files to be 'geomview', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following off/goff-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/goff" 
                    NC:path="/usr/bin/geomview" 
                    NC:prettyName="geomview" /> 
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/goff" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/goff"/> 
   </RDF:Description> 
...
...
   <RDF:Description RDF:about="urn:mimetype:application/goff" 
                    NC:fileExtensions="off" 
                    NC:description="" 
                    NC:value="application/goff" 
                    NC:editable="true"> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/goff"/> 
   </RDF:Description> 

When I click on one of these '.off' file links, in local 'kiosk' mode, the 'geomview' program starts up and shows the '.off' file.


octa_GLCplayerCrashesSegfault.off
(0.3 KB)

tetra_GLCplayerCrashesBacktrace.off
(0.4 KB)

icosa_GLCplayerCrashesBacktrace.off
(0.9 KB)

dodec2_GLCplayerCrashesBacktrace.off
(1.0 KB)

cone.off
(1.1 KB)

abstr.off
(1.5 KB)

mushroom_GLCplayerCrashesSegfault.off
(16.2 KB)


GROUP - ply :

< Return to Table of Contents, above. >

The following '.ply' files are showable with 'paraview --data='.

In the following 'anchor' link statements for sample '.ply' files, I have used application/ply for the 'type=' parameter value.

After setting the 'helper application' for these '.ply' files to be a wrapper-script for 'paraview --data=', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following ply-related statements in my 'mimeTypes.rdf' file :

  <RDF:Description RDF:about="urn:mimetype:handler:application/ply"
                   NC:alwaysAsk="false">
    <NC:possibleApplication RDF:resource="urn:handler:local:/home/userid/apps/paraview/paraview_wrapper.sh"/>
    <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/ply"/>
  </RDF:Description>
...
...
  <RDF:Description RDF:about="urn:mimetype:externalApplication:application/ply"
                   NC:prettyName="paraview_wrapper.sh"
                   NC:path="/home/userid/apps/paraview/paraview_wrapper.sh" />
...
...
   <RDF:Description RDF:about="urn:mimetype:application/ply" 
                    NC:value="application/ply" 
                    NC:editable="true" 
                    NC:fileExtensions="ply" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/ply"/> 
   </RDF:Description> 

The wrapper script, paraview_wrapper.sh, that I put in a directory called $HOME/apps/paraview, simply calls the command

    /usr/bin/paraview --data="$1"

When I click on one of these '.ply' file links, in local 'kiosk' mode, the 'paraview_wrapper.sh' script starts the 'paraview' program, which shows the '.ply' file --- after I click on the 'Apply' button to apply the loaded file whose name shows in the paraview 'Pipeline browser' window.


sphere.ply
(8.3 KB)

mobius.ply
(84 KB)

cow.ply
(169 KB)

x-wing.ply
(179 KB)

car.ply
(316 KB)

bun.ply
(379 KB)

holy-blob.ply
(436 KB)

cat.ply
(615 KB)

2handle.ply
(881 KB)

bunny.ply
(2,900 KB)

horse.ply
(3,100 KB)

hand.ply
(3,500 KB)

phone.ply
(5,400 KB)

dragon.ply
(7,000 KB)

venus.ply
(10,500 KB - more than 100 thousand polygons)

balljoint.ply
(10,900 KB)

vcg_david_500k.ply
(12,000 KB - more than 500 thousand polygons)

female.ply
(24,200 KB - big)

male.ply
(25,700 KB - big)


GROUP - pov :

< Return to Table of Contents, above. >

The following '.pov' files are renderable to high-quality 2D images, with shadows and reflections, using the 'povray' program.

In the following 'anchor' link statements for sample '.pov' files, I have used application/pov for the 'type=' parameter value.

After setting up the 'helper application' for these '.pov' files to be a wrapper-script for 'povray', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following pov-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:handler:application/pov" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/pov"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/pov" 
                    NC:path="/home/userid/apps/povray/povray_wrapper.sh" 
                    NC:prettyName="povray_wrapper.sh" /> 
...
...
   <RDF:Description RDF:about="urn:mimetype:application/pov" 
                    NC:value="application/pov" 
                    NC:editable="true" 
                    NC:fileExtensions="pov" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/pov"/> 
   </RDF:Description> 

The wrapper script, povray_wrapper.sh, that I put in a directory called $HOME/apps/povray, calls the following commands

    FILENAME="$1"
    FILEMIDNAME=`echo "$FILENAME" | cut -d'.' -f1`

    /usr/bin/povray "$FILENAME"

    /usr/bin/eog "${FILEMIDNAME}.png"
in order to make and show a 2D '.png' file.

    We are depending here on povray to make a png file, by default, using the midname of the input file to build the name of the png file.

    Of course, we could change this script to use the many command line parameters available with povray.

When I click on one of the '.pov' file links, below, in local 'kiosk' mode, the 'povray_wrapper.sh' script starts the 'povray' program, and shows the resulting '.png' file --- with the 'eog' (Eye of Gnome) viewer program.


polygon.pov
(0.8 KB)

trimesh1.pov
(1.6 KB)

cube.pov
(2.8 KB)


GROUP - stl : (STereoLithography - ascii and binary)

< Return to Table of Contents, above. >

The following '.stl' files are showable with 'glc_player'.

In the following 'anchor' link statements for sample '.stl' files, I have used application/stl for the 'type=' parameter value.

After setting up the 'helper application' for these '.stl' files, using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following stl-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:application/vnd.ms-pki.stl" 
                    NC:fileExtensions="stl" 
                    NC:description="" 
                    NC:value="application/vnd.ms-pki.stl" 
                    NC:editable="true"> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/vnd.ms-pki.stl"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/vnd.ms-pki.stl" 
                    NC:path="/usr/bin/glc_player" 
                    NC:prettyName="glc_player" />
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/vnd.ms-pki.stl" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/vnd.ms-pki.stl"/> 
     <NC:possibleApplication RDF:resource="urn:handler:local:/usr/bin/whitedune"/> 
     <NC:possibleApplication RDF:resource="urn:handler:local:/usr/bin/glc_player"/> 
   </RDF:Description>

When I click on one of the '.stl' file links, below, in local 'kiosk' mode, the 'glc_player' program, shows the '.stl' file.


cube_binary.stl
(0.7 KB)

cube.stl
(2.0 KB)

tiler_3d.stl
(27 KB)

sphere.stl
(53 KB)

bat_cover_binary.stl
(95 KB)

bottle.stl
(288 KB)

magnolia.stl
(321 KB)

teapot.stl
(468 KB)


GROUP - stp : (STEP files)

< Return to Table of Contents, above. >

STEP files (3D) are showable by 'varicad-view'.

In the following 'anchor' link statements for sample '.stp' files, I have used application/step for the 'type=' parameter value.

After setting up 'varicad-view' as the 'helper application' for these '.stp' files, using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following stp/step-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:handler:application/step" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/step"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:application/step" 
                    NC:value="application/step" 
                    NC:editable="true" 
                    NC:fileExtensions="stp" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/step"/> 
   </RDF:Description> 
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/step" 
                    NC:path="/usr/bin/varicad-view" 
                    NC:prettyName="varicad-view" /> 

When I click on one of the '.stp' file links, below, in local 'kiosk' mode, the 'varicad-view' program, shows the '.stp' file.

In 'varicad-view', in 3D mode, you can move the model with the mouse as follows

  • rotate - with Ctl-and-Shift keys pressed
  • pan - with Ctl key pressed
  • zoom - with Shift key pressed


adjust_part1_MIR_050106.stp
(0.03 MB)

innerslab_050926.stp
(0.9 MB)

inner_vessel_end_flange_mod.stp
(0.9 MB)

inner_vessel_040819.stp
(4.9 MB)

Vessel_Support_Assembly_040819.stp
(22 MB - big)

Vessel_Support_Assembly.stp
(27 MB - big)


GROUP - vtk : (Visual Tool Kit)

< Return to Table of Contents, above. >

VTK files are showable by 'paraview --data='.

In the following 'anchor' link statements for sample '.vtk' files, I have used application/vtk for the 'type=' parameter value.

After setting up the 'helper application' for these '.vtk' files to be a wrapper-script for 'paraview --data=', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following vtk-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:handler:application/vtk" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/vtk"/> 
   </RDF:Description> 
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/vtk" 
                    NC:path="/home/userid/apps/paraview/paraview_wrapper.sh" 
                    NC:prettyName="paraview_wrapper.sh" /> 
...
...
   <RDF:Description RDF:about="urn:mimetype:application/vtk" 
                    NC:value="application/vtk" 
                    NC:editable="true" 
                    NC:fileExtensions="vtk" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/vtk"/> 
   </RDF:Description> 

The wrapper script, paraview_wrapper.sh, that I put in a directory called $HOME/apps/paraview, simply calls the command

    /usr/bin/paraview --data="$1"

When I click on one of these '.vtk' file links, in local 'kiosk' mode, the 'paraview_wrapper.sh' script starts the 'paraview' program, which shows the '.vtk' file --- after I click on the 'Apply' button to apply the loaded file whose name shows in the paraview 'Pipeline browser' window.

In 'paraview', in 3D mode, you can move the model with the mouse as follows

  • rotate - click the LEFT (#1) mouse button and drag
  • pan - click the MIDDLE (#2) mouse button and drag
  • zoom - click the RIGHT (#3) mouse button and drag


hello.vtk
(0.5 KB - 22 points)

polyex.vtk
(0.5 KB - 8 points)

triangle_mesh_linear.vtk
(0.6 KB - 8 points)

ugridex.vtk
(1.0 KB - 27 points)

v.vtk
(4.7 KB - 100 points - letter V, serif)

rbc_001.vtk
(32.4 KB - 500 points - jelly donut)

mesh_smag_0040.vtk
(6,300 KB - 53,713 points - simple rectangular bar)


GROUP - vr1 :
(VRML1 files - a subset of the SGI Inventor 2 format)

< Return to Table of Contents, above. >

VRML1 files are showable with 'ivview'.

In the following 'anchor' link statements for sample '.vr1' files, I have used application/vr1 for the 'type=' parameter value.

After setting up the 'helper application' for these '.vr1' files to be 'ivview', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following vr1-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/vr1" 
                    NC:path="/usr/bin/ivview" 
                    NC:prettyName="ivview" /> 
...
...
   <RDF:Description RDF:about="urn:mimetype:application/vr1" 
                    NC:fileExtensions="vr1" 
                    NC:description="" 
                    NC:value="application/vr1" 
                    NC:editable="true"> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/vr1"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:handler:application/vr1" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/vr1"/> 
   </RDF:Description>

When I click on one of these '.vr1' file links, in local 'kiosk' mode, the 'ivview' program starts up and shows the '.vr1' file.

In 'ivview', you can move the model with the mouse as follows

  • rotate - click the LEFT (#1) mouse button and drag
  • pan - click the MIDDLE (#2) mouse button and drag
  • zoom - use the 'Dolly' dial on the right of the GUI

For more help, click on the '?' button on the right of the GUI.


apple_vrml1.vr1
(0.1 MB)

z1_1_vrml1.vr1
(0.6 MB - slightly squashed sphere)

1923_inventor2_to_vrml1.vr1
(1.0 MB - roughly sculpted head)

1853_vrml1.vr1
(1.8 MB - bearded head)

1864_vrml1.vr1
(2.5 MB - rough sculpture)


GROUP - vr2 :
(VRML2, a.k.a. VRML97, files)

< Return to Table of Contents, above. >

VRML2 files are showable with 'whitedune'.

In the following 'anchor' link statements for sample '.vr2' files, I have used application/vr2 for the 'type=' parameter value.

After setting up the 'helper application' for these '.vr2' files to be 'whitedune', using the 'Open-with' dialog of the Seamonkey2 web browser, I ended up with the following vr2-related statements in my 'mimeTypes.rdf' file :

   <RDF:Description RDF:about="urn:mimetype:handler:application/vr2" 
                    NC:alwaysAsk="false" 
                    NC:saveToDisk="false" 
                    NC:useSystemDefault="false" 
                    NC:handleInternal="false"> 
     <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:application/vr2"/> 
   </RDF:Description>
...
...
   <RDF:Description RDF:about="urn:mimetype:application/vr2" 
                    NC:value="application/vr2" 
                    NC:editable="true" 
                    NC:fileExtensions="vr2" 
                    NC:description=""> 
     <NC:handlerProp RDF:resource="urn:mimetype:handler:application/vr2"/> 
   </RDF:Description> 
...
...
   <RDF:Description RDF:about="urn:mimetype:externalApplication:application/vr2" 
                    NC:path="/usr/bin/whitedune" 
                    NC:prettyName="whitedune" /> 

When I click on one of these '.vr2' file links, in local 'kiosk' mode, the 'whitedune' program starts up and shows the '.vr2' file.

In 'whitedune', you can move the model with the mouse as follows

  • rotate - hold down the LEFT (#1) mouse button and drag
  • pan - ?
  • zoom - hold down the MIDDLE (#2) mouse button and drag
  • reset the model to the middle of the viewing window - ?


geom_ball_vrml2.vr2
(0.3 KB)

geom_cone_vrml2.vr2
(0.3 KB)

colors_tree_green-red_vrml2.vr2
(0.4 KB)

geom_anchor_cube-sphere-cone_vrml2.vr2
(1.0 KB)

furn_lamp_crude_vrml2.vr2
(1.1 KB)

astro_solar_sun-earth-moon_vrml2.vr2
(1.5 KB)

furn_desk_vrml2.vr2
(1.6 KB)

geom_trumpet_shape_vrml2.vr2
(1.7 KB)

geom_egg2_vrml2.vr2
(1.8 KB)

geom_extrusions_vrml2.vr2
(1.8 KB)

astro_inter-tour-guide_sun-earth-moon_vrml2.vr2
(1.9 KB)

geom_scene_cube-sphere-cone-cylinder_vrml2.vr2
(2.6 KB)

furn_table_vrml2.vr2
(2.8 KB)

transparency_12-spheres-varied_vrml2.vr2
(2.8 KB)

anima_headgz_vrml2.vr2
(2.9 KB)

geom_lift_infiLine_vrml2.vr2
(3.0 KB)

colorshades_rotation_toy_vrml2.vr2
(3.3 KB)

geom_engines_2spheres-2cubes_vrml2.vr2
(3.4 KB)

geom_cube2_vrml2.vr2
(4.0 KB)

furn_teapot_vrml2.vr2
(4.5 KB)

anima_snoman_vrml2.vr2
(4.7 KB)

anima_skiman_vrml2.vr2
(5.2 KB)

construct_hall_columns_vrml2.vr2
(5.3 KB)

dyna_trees_moving-planes_vrml2.vr2
(5.6 KB)

astro_cassini2_vrml2.vr2
(6.3 KB)

colorshades_color_toy_vrml2.vr2
(6.6 KB)

construct_hud_vrml2.vr2
(7.2 KB)

chem_tricloroethylene_BallandStick_vrml2.vr2
(7.7 KB)

construct_stairway_vrml2.vr2
(10.9 KB)

astro_issv2d_vrml2.vr2
(18.4 KB)

viewpoints_happyBus_vrml2.vr2
(18.8 KB)

anima_buzz_vrml2.vr2
(26.4 KB)

construc_hellpit_vrml2.vr2
(28.2 KB)

anima_dolphin_vrml2.vr2
(30.8 KB)

anima_dancer_vrml2.vr2
(42.9 KB)

anima_skull_vrml2.vr2
(51.5 KB)

astro_talon2_vrml2.vr2
(67.3 KB)

anima_robot_vrml2.vr2
(90.5 KB)

anima_testman_vrml2.vr2
(111 KB)

anima_shark_vrml2.vr2
(115 KB)

astro_issv2a_vrml2.vr2
(160 KB)

astro_hugo2_vrml2.vr2
(170 KB)

chem_tricloroethylene_tot_density_transparency_vrml2.vr2
(300 KB)

chem_m-xylene_HOMO-1_vrml2.vr2
(473 KB)

anima_crabshell_vrml2.vr2
(560 KB)

chem_tricloroethylene_HOMO-1_vrml2.vr2
(573 KB)


GROUP - x3d :
(basically XML wrapped around VRML2)

< Return to Table of Contents, above. >

X3D files are showable with ???.

Ask the Web3D Consortium. They've had 10 years to come up with a good viewer --- easily installable on Ubuntu Linux, or any other OS. They have pissed away the good foundation that SGI laid for them. Disgusting.

They don't seem to understand that the PDF document format became ubiquitous because Adobe provided a free reader, cross-platform.

For 10 years now, the x3d format has been languishing. It is actually easier to find old VRML files than X3D files.

It is time the consortium made the 'Xj3D' Java-based X3D reader available across major platforms and easily installable and functional --- or devise a C++-based reader. Or go back to VRML2, and provide a cross-platform reader for that format --- and its enhancements.

I guess this is what happens when a decent format is put in the hands of a committee of strict, anally-retentive XML enthusiasts, who have more interest in syntax than in graphical viewers.


basics-2.x3d
(2.1 KB)

basics-1.x3d
(2.4 KB)

basics-shapes-5V.x3d
(2.4 KB)

basics-text-2.x3d
(2.5 KB)

basics-anchors-1.x3d
(2.5 KB)

x-y-z-coordinates.x3d
(2.6 KB)

x-y-z-coordinates-ball.x3d
(2.9 KB)

x-y-z-coordinates-illustrated.x3d
(5.1 KB)



NOTE :
There is a 'RDF:Seq' 'mimetypes:root' section of the Seamonkey2 'mimeTypes.rdf' file. It apparently gets updated when I add new mime-types via the Seamonkey2 'Open-with' dialog.

I know this because new mime-types like 'application/ply', 'application/wobj', 'application/vr1', and 'application/vr2' showed up at the bottom of the list.

  <RDF:Seq RDF:about="urn:mimetypes:root">
    <RDF:li RDF:resource="urn:mimetype:application/zip"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-mpg"/>
    <RDF:li RDF:resource="urn:mimetype:image/x-jpg"/>
    <RDF:li RDF:resource="urn:mimetype:application/octet-stream"/>
    <RDF:li RDF:resource="urn:mimetype:application/msword"/>
    <RDF:li RDF:resource="urn:mimetype:application/rtf"/>
    <RDF:li RDF:resource="urn:mimetype:application/vnd.ms-excel"/>
    <RDF:li RDF:resource="urn:mimetype:application/vnd.ms-powerpoint"/>
    <RDF:li RDF:resource="urn:mimetype:application/pdf"/>
    <RDF:li RDF:resource="urn:mimetype:image/x-ms-bmp"/>
    <RDF:li RDF:resource="urn:mimetype:image/x-vcard"/>
    <RDF:li RDF:resource="urn:mimetype:audio/mpeg"/>
    <RDF:li RDF:resource="urn:mimetype:audio/mp3"/>
    <RDF:li RDF:resource="urn:mimetype:audio/x-mpeg-url"/>
    <RDF:li RDF:resource="urn:mimetype:audio/x-mpeg"/>
    <RDF:li RDF:resource="urn:mimetype:audio/mpeg-url"/>
    <RDF:li RDF:resource="urn:mimetype:audio/wav"/>
    <RDF:li RDF:resource="urn:mimetype:audio/x-wav"/>
    <RDF:li RDF:resource="urn:mimetype:video/mpeg"/>
    <RDF:li RDF:resource="urn:mimetype:audio/mpeg3"/>
    <RDF:li RDF:resource="urn:mimetype:audio/x-mpeg3"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-iso9660-image"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-httpd-php"/>
    <RDF:li RDF:resource="urn:mimetype:video/3gpp"/>
    <RDF:li RDF:resource="urn:mimetype:application/futuresplash"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-shockwave-flash"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-gzip"/>
    <RDF:li RDF:resource="urn:mimetype:x-world/x-vrml"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-bzip2"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-compress"/>
    <RDF:li RDF:resource="urn:mimetype:model/vrml"/>
    <RDF:li RDF:resource="urn:mimetype:application/java-archive"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-deb"/>
    <RDF:li RDF:resource="urn:mimetype:image/tiff"/>
    <RDF:li RDF:resource="urn:mimetype:application/vnd.ms-pki.stl"/>
    <RDF:li RDF:resource="urn:mimetype:application/dxf"/>
    <RDF:li RDF:resource="urn:mimetype:application/acad"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-inventor"/>
    <RDF:li RDF:resource="urn:mimetype:application/ply"/>
    <RDF:li RDF:resource="urn:mimetype:application/3ds"/>
    <RDF:li RDF:resource="urn:mimetype:application/wobj"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-tcl"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-debian-package"/>
    <RDF:li RDF:resource="urn:mimetype:application/goff"/>
    <RDF:li RDF:resource="urn:mimetype:application/vr1"/>
    <RDF:li RDF:resource="urn:mimetype:application/vr2"/>
    <RDF:li RDF:resource="urn:mimetype:application/x-blender"/>
  </RDF:Seq>

You can look for more 3D test/demo files via globalfilesearch.net.
Enter a files suffix such as .3ds or .wrl .

OR, try Google with filepath:wrl or some other suffix.


'varicad-view' screenshot - in 3D mode - on a STEP file

Bottom of 3D files - for testing viewers & converters - on Linux page.

To return to a previously visited web page location, click on the
Back button of your web browser, a sufficient number of times.
OR, use the History-list option of your web browser.
OR ...

< Go to start of 3D File Links, above. >
< Go to start of Table of Contents, above. >
< Go to Top of Page, above. >

Page created 2011 Jan 11. Changed 2011 Apr 25.