The export converter writes out the scene database to a 3D Studio file including mesh data, smoothing group information, material attributes, bitmap references, viewport configurations, cameras, lights, and camera plus object animation data (where appropriate). It also provides for automatic bitmap conversion during file export.

This converter outputs almost every possible 3D Studio file attribute. For materials, a partial list includes all texture maps (texture # 1, texture # 2, reflect map, bump map, shininess map and opacity map), automatic planar & cubical environment maps, transparency values, phong values and shading modes (flat to metal). Note: the converter also does shading parameter matching so that, for example, colors and textures read in from Lightwave will be rendered fairly closely when exported to 3D Studio. Other exported attributes include view port settings, atmospheric effects and background color schemes. Geometry hierarchy, geometry attributes and the first keyframe of the animation section is output.

The .3ds file format was the native file format of the old Autodesk "3D Studio R1-R4" software, which was popular up to about 1996 before its successor (3ds max, or 3D Studio MAX) replaced it. Having been around since the very late 1980's, it has grown to become an industry standard for transferring models between 3D programs, or for storing models for 3D resource catalogs (similar in status to Wavefront OBJ as a model archiving file format).

Please do not confuse the .3ds format with the 3D Studio MAX .max format. You will find throughout the 3D industry that some companies refer to .3ds as the "3DS MAX file format" but this is not true. The native file format of 3DS MAX is the .max format, whereas .3ds is just a legacy import/export file format ported over to 3DS MAX by Tom Hudson during the transition from 3D Studio R4.

Suggestion: Do not use the .3ds format to transfer data to/from 3DS MAX (especially for huge CAD datasets). There are many people who continue to do this. The best method is to use the directly integrated PolyTrans-for-MAX plug-in system.

Note that the .3ds format is no longer an ideal file format as it once was. The .3ds format has several serious shortcomings, many of which probably stem from the fact that 3D Studio R1 grew out of Tom Hudson's mid-80's "CAD-3D" on the Atari platform:

• All meshes must be triangles.
• All texture filenames are limited to 8.3 DOS character lengths.
• The number of vertices and polygons per mesh is limited to 65536.
• Accurate vertex normals cannot be stored in the .3ds file. Instead "smoothing groups" are used so that the receiving program can recreate a (hopefully good) representation of the vertex normals. This is still a hold-over legacy for many animation programs today which started in the 1980's (3DS MAX, Lightwave and trueSpace still use smoothing groups, and Maya up to v2.51).
• Object, light and camera names are limited to 10 characters. Material names are limited to 16 characters.
• Directional light sources are not supported.

Starting in 1997, with several generation of versions thereafter, Okino has developed a special native plug-in version of PolyTrans (referred to as "PolyTrans-for-MAX") which allows the 3DS MAX & VIZ programs to read and write all the 3D file formats supported by NuGraf and PolyTrans. This is the only formal method in which the .max file format can be accommodated by the NuGraf/PolyTrans software.

Please note that it is not possible to import or export .max files directly from inside the NuGraf or PolyTrans stand-alone software itself (see below for explanation); The .max file format is not a pure 3D file format (as is the .3ds file format) but rather it contains a "state snapshot" of how the various plug-in modules with 3DS MAX interact with each other to produce the final displayed mesh model.

In order to read/write .max files we must run PolyTrans directly inside 3DS MAX itself. This is because we need to have 3DS MAX evaluate its "stack" of plug-in modules that operate on the base mesh. The evaluated output mesh is then sent to PolyTrans. Vice versa, we need to gain access to the core of 3DS MAX to import data from PolyTrans and save it to the 3DS MAX internal database.

Please note that these special plug-in modules operate INSIDE 3DS MAX itself and not inside the stand-alone NuGraf or PolyTrans software. These modules are NOT to be placed in the Okino 'vcplugin' directory.

If you wish to transfer data from NuGraf, PolyTrans or Maya to 3DS MAX, execute those programs and save out an Okino ".bdf" file. Now load in the .bdf file via the PolyTrans-for-MAX plug-in system.

This export converter writes out motion capture data in the Acclaim (.amc and .asf) file format. This file format describes animated skeletons in terms of bones, hierarchy and angle constraints.

This geometry export converter writes out Alias triangle binary files which can be read into Alias Power Animator/Studio/AutoStudio/Designer. This is an old file format from the early 1990's; however, history has shown that there are still some programs which can import/export this file format.

These files basically just contain raw geometry data in triangular format with normals/colors/texture-uv coordinates per vertex. In addition the file contains the texture filename associated with each polygon and the structure of the file describes the hierarchy of the original scene.

The 3DMF file format was created by Apple Corp. in the early to mid 1990's as the standard file format for their QuickDraw-3D real time graphics library (which was competing with early versions of DirectX and the .X file format from Microsoft around that time). It was quite an amazing file format for the time, verbose and rich with primitives, attributes and other elements. It appeared that this would become the dominant file format for the 3D industry (as was .3ds and .obj up to that time). The 3DMF file format was primarily used by the Mac-based 3D programs of the time (Strata, Infini-D, RayDream Designer, etc) and waned in popularity probably due to the non-conformity of 3DMF files written and read by these programs. However, the 3DMF file format is still used today by Artifice's Design Workshop program, and used as the primary file format for the Great Buildings WEB site.

¥ = Trim curves are not output, just the NURBS patches.

This geometry export converter writes out Apple QuickDraw 3D binary and ASCII files. It exports:

• Proper translation of all forms of geometry into the 3DMF 'Mesh' primitive, complete with support for the 'VertexSetAttributeList', 'FaceSetAttributeList' and 'MeshCorners' sub-objects.
• Complete support for n-sided polygons with recursive holes and islands.
• Object hierarchy support by embedding mesh data within 'Group' nodes.
• All vertex attributes are supported, including: normals, (u,v) texture coordinates, (U,V) tangent vectors and diffuse color. All mesh output has been optimized to produce the smallest file size according to which vertex attributes are present.
• NURBS patches output as the 3DMF 'NURBPatch' primitive, or they are optionally output as polygons. No trims curves are output.
• Embedding of bitmap texture images within the 3DMF file. If a bitmap image is used more than once for multiple objects then only one copy is ever used within the file ('Reference()' keywords are used to instantiate the image).
• If more than one texture map is assigned to a single object then that object will be exploded into multiple separate meshes, each of which is assigned a single texture map (this is a complex operation!).
• Texture scale, offset and wrap-arounds (Clamp/Wrap flags) are properly handled and output.

This export converter writes out motion capture data to the Biovision .bvh file format. This file format describes animated skeletons in terms of joints, hierarchy and angle constraints.

This export converter writes out ASCII and binary DirectX (.x) formatted files. Mesh data (with vertex normals, vertex uv texture coordinates and vertex colors), materials, texture references, hierarchy and object animation are all exported. In addition, vertex weights used for mesh/skeleton deformation skinning are exported. Automatic bitmap file conversion is done to the PPM and BMP file formats.

¥ = The DirectX file format has no support for lights or cameras.

¥ = DirectX is very much associated with bones and skinning but it has no explicit "bone" primitive. Any hierarchy node in the DirectX file format can act as a bone, just as it occurs in the Softimage dotXSI file format. PolyTrans has very strong and robust support for exporting skeletons and mesh skinning information from various source 3D file formats and animation packages.

The main features include:

• It really works! Check out our customer testimonials and some ofthe notable users of the PolyTrans software. This DirectX exporter has been anindustry standard since 1997 when it was first released.
  
  
• Proper translation of all forms of geometry into the DirectX 'Mesh' primitive, complete with support for the 'MeshNormals', 'MeshMaterialList','MeshVertexColors' and 'MeshTextureCoords'.
  
  
• Export of skin weights, from select source programs, for realtime deformation of single skin meshes by their associated bound skeletons (the skeletons are represented as frame hierarchies). New for DirectX 8.
  
  
• Export of vertex duplication lists for DirectX 8. In order to output proper uv texture coordinates there are cases when vertices of a mesh have to be duplicated. The vertex duplication list allows the reader of the .X file to undo this duplication process.
  
  
• Object hierarchy support by embedding mesh data within a 'Frame' structure.
  
  
• Automatic conversion of bitmap files to .bmp or .ppm format. Also, the converter can resize the bitmaps so that they are a power-of-two and square in size.
  
  
• The converter can take any arbitrary 3D object (including those with n-sided polygons and optional holes, bicubic patches or NURBS patches) and convert them to optimized triangle meshes.

This export converter writes the scene database as either 3-point or 4-point polygons using the 3DFACE or POLYFACE MESH entities. Polygons with 5 or more vertices, concave polygons, or polygons with holes are automatically triangulated. All polygons will be assigned DXF color # 1.

If the file is written using the POLYFACE MESH option then there is no need to weld the geometry data when the DXF file is read into another program (since the data output to the DXF file will be automatically welded by this converter).

This export converter writes out raw FACT files to the Electric Image animation system (now called 'Universe'). FACT files are also a common format to move scene data in and out of the Form/Z modeling program.

Please note: if you wish to export animation data to Electric Image Universe then use the Lightwave export converter file format.

Features of the export converter:

• Exports polygonal geometry (or NURBS converted to polygons) with associated vertex normals, uv texture coordinates, vertex colors and tangent vectors,
  
  
• Export of complex FACT hierarchy, including the preservation of linkage information and child/parent transformation information. Pivot points are properly exported as linkage information.
  
  
• Complex material information is exported:
  
  
• Diffuse, specular, ambient and luminance colors.
  
  
• Diffuse, specular, ambient and luminance shading coefficients.
  
  
• Transparency, reflectivity, index of refraction and diffuse bias.
  
  
• Automatically creates a MacBinary Header for ease of use on a Macintosh.
  
  
• Converts between Electric Image's left handed coordinate system and right handed coordinate system.
  
  
• The ability to selectively export
  
  
• Vertex texture coordinates
  
  
• Object hierarchy
  
  
• Texture bitmap references
  
  
• Materials
  
  
• All inherited attributes such as position, rotation and scale are properly handled.
  
  
• Outputs texture UV coordinates as well as various forms of texture projections (where applicable). Since the size of texture projections depend upon the bitmap resolution of their associated texture maps, this exporter also locates and opens up the texture images to obtain their resolutions.
  
  
• The converter can scale and translate geometry during export

This geometry export converter writes out Game Exchange v2.0 ASCII files. Game Exchange was originally developed and maintained by IZware, and Nichimen prior to that. Game Exchange provides a mechanism for converting object, material, and animation data into a set of intermediate ASCII file formats.

Entities Exported via the GameExchange2 Exporter:

• N-sided polygonal mesh data to .gbf files. Vertex normals, uv texture coordinates and vertex colors can all optionally be output.
  
  
• Full hierarchy information for objects with the use of .gof files for instancing of existing geometry (body) data.
  
  
• Output of the "Render domain" material definition with ambient, diffuse, specular and emissive color. Color opacity (ganged with highlight opacity), the phong shading model (and associated specular exponent) are also output.
  
  
• For texture mapping, the diffuse, opacity and bump maps are output. More could be output (such as specular color map, luminous color map, highlight color map) but these types of texture maps are not defined by GameExchange v2.1. With each texture map is output the (u,v) scale and offset values (appropriately modified for the inverted uv coordinate system fo GameExchange), the bump mapping factor and the wrap around flags (STD for both wrap-arounds enabled, or CLAMP for both wrap-arounds disabled or if either wrap-around flag is disabled).
  
  
• For each texture map reference added to the .gmf material file, the actual texture map image itself can be automatically cross converted to any 2d bitmap image file format supported by PolyTrans.
  
  
• Perspective cameras with the look-from, look-at, look-up, field-of-view and the near/far clipping planes.
  
  
• Ambient light with intensity and color. Point light with intensity, color and location. Directional lights with intensity, color and direction. Spot lights with intensity, color, shine-from, shine-at, attenuation, spot-angle and fall-off angle.
  
  
• Scale, rotation and translation 'keyframe' animation data for objects. Location, orientation and field-of-view animation for cameras. Note this is the explicit 'keyframe' type of animation data and not the 'offset' form of animation data supported by Mirai. Since Mirai and GameExchange2 do not have the concept of pivot points and locally defined animation transforms, all animation is output in world-space coordinates (in such cases all hierarchy nodes above the leaf node are identity transforms).

This geometry utility saves out the database to the HOOPS Stream File (.hsf) file format. The HOOPS Stream File (HSF) file format allows highly compressed files containing 3D data and bitmap images to be streamed over Internet connections of any bandwidth. The HOOPS Stream File (HSF) format is a robust, customizable and highly compressed 2D/3D visualization format specifically tailored to the needs of displaying 3D model and scene data. Through its rapid widespread adoption and open, published nature, HSF is fast becoming a ubiquitous medium for applications to share visual data and for end users to publish and store their visual data.

Advantages of publishing to the HSF Web streaming file format:

• No charge for displaying the HSF files on your WEB site. Some other WEB streaming file formats require broadcast license fees or fees to be paid for the publishing package. Okino Computer Graphics has paid a licensing fee upfront to TechSoft America on behalf of our customers.
  
  
• Free HSF viewer control for WEB browsers. Available for Windows, UNIX and Linux platforms.
  
  
• No WEB server configuration required. HSF streaming and viewing is a client-only solution, eliminating the need to endure the considerable IT burden of server-side configuration and maintenance. Users wishing to implement real time collaborative viewing or view-dependent streaming should refer to the HOOPS Net Server.
  
  
• Multiple levels of data compression: vertex, normals, polygon and file-level.
  
  
• Level of Detail support. Streams simpler models first, then successively more complex models.

This geometry utility writes out the scene database as triangular meshes along with all material definitions and all lights present in the scene. The converter will also automatically convert all bitmaps referenced in the originating scene to a 2D bitmap format supported by Imagine. The Image file format does not, however, support vertex uv texture coordinates.

This export converter writes a Lightscape preparation file (.lp) containing all geometry, lights, and material attributes needed to render the scene within the Lightscape Visualization System. Even complicated scenes can be exported quickly and usually require only minimal adjustment from within Lightscape before they can be fully rendered.

The main features of the exporter include:

• The output of geometry includes vertex normals and texture coordinates for rendering of smooth textured surfaces.
  
  
• Support for both layers and blocks within the Lightscape preparation file. Multiple options are available for layer and block structure creation.
  
  
• Material definitions are exported including values for transparency, smoothness, index of refraction, and luminance. The exported materials also include texture map information.
  
  
• Exported lights include all point and spot light sources with directional lights being converted to point sources positioned some distance outside the extents of the scene geometry.
  
  
• Automatic conversion of bitmap files to those formats supported by the Lightscape Visualization System.

This geometry export converter writes out Lightwave compatible object (.lwo) and scene (.lws) files, complete with all geometry, mesh attributes, bones and skinning, hierarchy information, lights and cameras, materials, texture maps, automatic bitmap file conversion, object and camera animation, and material attributes. This, and the Lightwave file importer, are two of the more important core converters in Okino software since the start of their development in 1994.

The following information is output to the object and scene files:

• N-sided polygon geometry. All polygons with holes are triangulated.
• Vertex colors and vertex uv texture coordinates (Lightwave 6.5 or newer).
• All hierarchy information.
• All pivot point information for each object.
• Point, directional and spot light sources complete with proper location and Euler angle parameters for each light’s first keyframe location.
• Numerically accurate output of Lightwave’s default camera location complete with proper location and Euler angle parameters for the camera’s first keyframe location.
• Background colors types (solid or gradient), fog parameters and object attributes (shadowed, casts shadows, etc).
• Object and camera animation data.
• Bones and skinning information in the unusual method that Lightwave has chosen to implement.

The NGRAIN Export Converter for Okino's PolyTrans supports the conversion of all 3D importer formats supported by PolyTrans to the NGRAIN format (3KO). NGRAIN 3KO (3D Knowledge Object) files are used by applications such as NGRAIN Producer and NGRAIN Mobilizer. This NGRAIN Export Converter also allows you to convert 3D files one at a time or by batch conversion.

This export converter writes out the scene database as a C code program in the Open GL scene description language. The resulting program can then be compiled and used to draw the 3d database directly using OpenGL. The database is output as a series of polygons with vertex positions, normals, colors and texture coordinates. In addition, the surface definitions (materials) associated with each polygon is used to set up the OpenGL shading parameters. Please note that each object is output as a separate C code function in the resulting file.

Features of this exporter:

1. Each geometry object is output to the OpenGL C file as its own function definition (ie: "Sphere#1" is enclosed in a function like: Sphere#1()).
   
   
2. Mesh data can be output as unrolled loops or "vertex arrays" for high performance output. Vertex positions, vertex normals, uv texture coordinates and vertex colors can all be output.
   
   
3. The Okino triangle stripper algorithm is used to take any form of geometry data and turn it into optimized tri-strips for use by the OpenGL tri-strip data type. This reduces the number of vertices that have to be transformed by OpenGL.
   
   
4. Options to automatically have the scene rescaled to a user specified maximum size or some absolute size, as well as options to center the geometry at the origin and/or make the geometry sit on the Z=0 horizontal plane. This benefits OpenGL rendering quality in cases where the extents of the scene cause the OpenGL clipping planes to be spaced too far apart; scaling the scene smaller allows the clipping planes to be kept closer together and thus reduce rendering anomalies (due to limited precision in the Z buffer).
   
   
5. A Microsoft Visual C++ .dsp/.dsw project and workspace are output in addition to the frame work to an OpenGL application program. Thus, you get the base OpenGL C program to represent your 3D scene (geometry, lights, camera, textures, etc). as well as an OpenGL C program to display the 3D scene in a Microsoft Windows window.
   
   
6. Removal of redundant coordinates for optimized mesh output.
   
   
7. Control of color output by weighting of the shading coefficients which are carried over from the imported file format.
   
   
8. Automatic bitmap conversion from all supported 2D bitmap file formats into whatever you require in your OpenGL C program, with .bmp being the default.

The Okino .bdf file format is the native format used by Okino's PolyTrans and NuGraf products. It is a "snap shot" of the core Okino 3D scene graph database and in essence is a super-set of the capabilities of most 3D files formats. It is the preferred and best file format to use when converting data between 3ds max (via the PolyTrans-for-MAX native plug-in system) and Maya (via the PolyTrans-for-Maya native plug-in system).

This geometry export converter writes out the lights, cameras, materials and geometry to a Persistence of Vision Ray Tracer (POV-Ray) geometry file, version 2.0 or 3.0 file format. POV is a popular public domain ray tracer that is available on many BBSs and Internet sites.

Many attributes will be output to a POV-Ray material definition, such as the finish attributes (shininess, ambient, diffuse, specular, index-of-refraction, phong values, etc), the pigment color, and an optional 2d bitmap texture link. The resulting file should be "render ready" with no tweaking necessary to create a useable output image (in particular, the lights and camera will not have to be tweaked); however, due to the fact that POV's file format does not accept (u,v) texture coordinates you may have to adjust the default spherical texture projection output by this export filter.

This geometry export converter writes out the 3d database to an ASCII formatted 'SLP Render File' which can be read by such programs as PTC's Pro/Engineer.

This geometry export converter writes out the scene database to a RenderMan RIB v3.1 compliant ASCII file which can then be read into other programs, or more likely, be sent off to PIXAR's RenderMan renderer or the BMRT renderer. The converter exports meshed geometry (with proper segmentation so that shaders are assigned properly), trimmed NURBS, bicubic patches, cameras, lights, embedded material definitions, texture creation commands and animation of frames. Automatic bitmap conversion or filename extension renaming is also performed.

The converter writes out a full RIB specification that can be read into a RIB compliant renderer and rendered immediately. The converter primarily outputs optimized indexed polygon arrays using the "PointsPolygon" and "PointsGeneralPolygons" primitives but will also output fully trimmed NURBS patches and (non-trimmed) bicubic patch primitives directly. For your information, Renderman renders trimmed NURBS patches incredibly fast! Camera and object animation data can also be output; a Renderman 'Frame' is output for each frame in the scene, with each frame containing the cameras and geometry translated to that frame's time.

¥ = Keyframe animation will be handled by evaluating the scene at each frame and outputting multiple RIB files, or one RIB file with all frames in it.

This export converter writes out the scene database as triangle meshes along with their associated material definitions that are defined in the converter's database. The converter can also automatically convert all referenced bitmaps (in the source 3D file) to a 2D bitmap format supported by Renderware. The Renderware file written is an ASCII .rwx file containing the 3D scene as a Renderware script. These files are typically used in conjunction with real-time 3D software developed by Criterion Software Ltd. (http://www.csl.com), namely the Renderware API and related software.

Attributes exported to the Renderware file include (u,v) texture coordinates, vertex normals, surface materials and texture references. Hierarchy information in the source 3D database is preserved in the structure of the Renderware file.

This export converter saves out the database to the OpenNURBS .3dm file format. This is the main file format used by the Rhino-3D NURBS modeling package by Robert McNeel and Associates.

The following data is exported to the OpenNURBS .3dm file format:

• Trimmed NURBS surfaces (patches) with uv-space and world-space trim curves. The world-space trim curves are calculated at export time by up sampling the uv-space curves to world-space.
  
  
• Polygon meshes with vertex normals and vertex uv texture coordinates.
  
  
• Independent NURBS curves.
  
  
• Spline Shapes as equivalent NURBS surfaces or curves.
  
  
• All other geometric primitive are meshed and output as polygon meshes.
  
  
• Ambient, point, spot and directional light sources with related parameters.
  
  
• Materials with ambient, diffuse, specular and luminous surface colors, phong shininess and transparency. The first diffuse and bump map texture images will also be output.

This export converter writes out the scene database to the Shockwave-3D file format. This was a WEB Streaming fileformat developed together by Intel and Macromedia. This is not to be confused with the Shockwave or Flash "2D" vector file format. Shockwave-3D is a normal 3D geometry file format with varying levels of lossy data compression to reduce data file size.

One primary use of this export converter is to take 3D asset data into the Macromedia Director program. The .sw3d files can be imported as 3D assets. This Shockwave-3D export converter is used as one key component in the PolyTrans-for-Director native plug-in system.

This geometry export converter writes out the 3d database to an ASCII formatted or binary formatted 'StereoLithography STL' file which can be read by many CAD/CAM related software packages.

This geometry export converter writes out a Strata StudioPro v1.75 compatible object file, complete with all meshes, surfaces, 2d textures, lights, cameras, texture maps, material attributes, hierarchy and embedded bitmap images. In addition, MacBinary information can be inserted into the file to make it readily useable in MacOS.

The Strata v1.75 file format does not accept uv texture coordinates or vertex colors.

This geometry export converter writes out a trueSpace compatible object or scene file, complete with all geometry and material attributes.

The following geometry information is output to the file:

• N-sided polygon geometry with recursive holes.
• Texture (u,v) coordinate data.
• All hierarchy information.
• All pivot point information for each object.

In addition, complete trueSpace materials are output to the file including:

• Surface color, ambient shading coefficient, specular shading coefficient, opacity value, highlight size and index of refraction.
• Spherical environment maps, texture maps and bump maps (including the (u,v) offset and scaling parameters).

This export converter outputs clean files to the Viewpoint "VET" 3D streaming file format (VET = Viewpoint Experience Technology). This file format was also previously known as Metastream 3 (MTS3). Over a year of development by Okino staff has lead to a high quality and robust VET exporter with dozens of options and many built-in features which will create dependable VET models (such as auto-scaling of the scene, automatic texture map resizing for minimal .mts file size, and much more). You can use the exported VET models immediately within your WEB pages or load them into Viewpoint's "Scene Builder" application for further material editing (such as applying custom light or texture maps).

VET is a popular 3D file format used to stream 3D data across a network, in particular the Internet. A key benefit of VET is its ability to download low resolution models initially, then dynamically increase the resolution of the model over a period of time by sending more polygon vertex information. This exporter was developed over a long period of 11 months at Okino, with close developer relations with the Viewpoint VET development team; it ties in very closely to the Viewpoint VET SDK and utilizes many features/tweaks in order to convert any form of 3D data into the Viewpoint VET format (.mts data files and .mtx scene files) for proper and optimized rendering in a Viewpoint VET viewer.

This export converter outputs clean and detailed files to the VRML 1.0, VRML 2.0 (VRML 97) and a sub-set of the Open Inventor v2 file formats. VRML is an ASCII file format for describing 3d scenes which is primary used in interactive virtual reality applications.

You should be made aware that VRML 2.0 is a very good and generic format to transfer data to other 3D programs (ahead of the .3ds (3D Studio) and .obj (Wavefront OBJ) file formats) if you cannot move data in a native form.

Features of the VRML 1.0/Inventor v2 export converter include:

• Output of clean mesh data with optional vertex normals and vertex texture coordinates.
  
  
• Lights (point, spot and directional) and the perspective camera.
  
  
• Embedding of any form of texture image inside a VRML file as raw data, or just providing the reference to the texture file.
  
  
• Automatic bitmap conversion and automatic bitmap resizing to/from the most popular 2d bitmap file formats.
  
  
• Modification controls for bitmap file paths written to the VRML file.
  
  
• Material parameter output: ambient color, diffuse color, specular color, emissive color, shininess and transparency.
  
  
• Proper segmentation of a mesh into multiple mesh primitives so that diffuse texture maps can be assigned properly.

In addition the following is output when VRML2 format is selected:

• Hierarchy for geometry and folders ("null nodes" or "empty instances/objects").
  
  
• Export of Object, camera and light animation.
  
  
• Vertex colors for mesh data.
  
  
• The usage of DEF/USE of the VRML2 file specification to allow instancing of geometry. This can greatly reduce the size of an exported VRML2 file if one mesh, or a sub-set of a VRML hierarchy tree is referenced multiple times.

This geometry export converter writes out the scene database as a series of optimized indexed polygon meshes (faces and their associated indices) along with optional normal and texture data (if its exists within the database). A Wavefront material definition file (.mtl) can also be exported which supports all material and texture options (ie: Ka, Ks, Kd, map_Ka, map_Kd, map_Ks, map_Bump, etc). The export converter also features extensive automatic 2d bitmap conversion options and features (see dialog box description below).

¥ - The Wavefront OBJ file format does not have support for hierarchy, vertex colors, animation, lights, cameras, skinning or other more common scene file contents.

The Wavefront file format is quite robust and is a popular format used to transfer entire object geometries between 3D packages.

No hierarchy information is output since the .OBJ file format has no methods to describing hierarchy; each sub-object of a hierarchy will nonetheless be exported as a unique group whose name's match the original object names in the internal database hierarchy.

Okino's X3D exporter (and corresponding importer) are one of the first set of production-quality X3D and Classic VRML converters to come to market, just as Okino had provided the first industry standard set of re-purposing converters for VRML1 and VRML2 in 1996 and 1998 respectively (and which are still two of our most popular file formats today, a decade later). They were developed in full cooperation with the Web3D Consortium and the U.S. Navy.

"X3D" is the next generation standard, a superset of the VRML2 specification. It is an Open Standards XML-enabled 3D file format to enable real-time communication of 3D data across all applications and network applications. It has a rich set of features for use in engineering and scientific visualization, CAD and Architecture, Medical visualization, Training and simulation, multimedia, entertainment, educational, and more. Where VRML1 and VRML2 dominated the 3D market for the last decade, it is expected that X3D will become the successor and replacement for the next decade. More information about the X3D file format and initiative can be found at www.web3d.org.

As mentioned by Robert Lansdale, President & CEO of Okino, "I would like to impress on our Okino customer user base the importance of this new generation of X3D import/export converters. Almost every month a new 3D file format is introduced to the market, often because the developers of the file format do not believe that existing file formats are acceptable. Typically this is internally motivated by company politics or the common 'not invented here' mentality. The current 3D market is becoming glutted with an overabundance of similar 3D file formats, yet that does not need to be the case. One of the longest standing and most successful 3D file formats since 1996 has been VRML2, as it was designed to be an extensive, open and standards-based data transfer file format. VRML2, and its new X3D XML-based successor, are stable and well established file formats that will most likely outlast many of today's existing 3D formats. Okino's customers have had great success with our bi-directional VRML 1+2 conversion pipelines since the 90's and hence we decided to collaborate with the Web3D Consortium and the US Navy to extend these capabilities to include production-quality X3D and Classic VRML support. VRML2 and X3D are very verbose file formats, with many nuances, which made the implementation and testing of our second generation converters very time intensive."

This geometry export converter writes out ASCII XGL formatted files as well as their ZGL compressed equivalents. Triangular mesh data (with vertex normals and vertex uv texture coordinates), material properties, embedded texture images and object hierarchy are exported from the XML-style XGL file.

The XGL file format is most often used to convey data from several CAD packages into Okino software (such as SolidWorks, Solid Edge, Autodesk Inventor, etc). This exporter can be used to convert all of the Okino supported import file formats to the XGL format, which can then be subsequently used in RealityWave WEB-based viewing and collaboration products.

PolyTrans-for-Maya runs inside Maya as a native plug-in system (and requires a resident copy of Maya). This allows a Maya user to easily access all of the stand-alone Okino converter modules. To convert data to/from 3ds max use the Okino ".bdf" scene transfer file format and the native PolyTrans-for-MAX plug-in system on the 3ds max side. To convert data to/from Softimage|XSI use the .dotXSI file format from the Maya side. To convert data to/from Lightwave use the Lightwave import/export converters from the Maya side.

Trimmed NURBS can be exported from Maya using PolyTrans-for-Maya, but not imported. This is because there is no API provided by Maya which allows for the import of uv-space, oriented trim curves and loops.

This geometry export converter writes out OpenFlight .flt binary files, complete with all geometry, hierarchy information, material, lights, "flip book" animation and texture mapping attributes. A file exported to OpenFlight should appear almost exactly as whence the file originated (little or no tweaking should have to be done).

Okino's OpenFlight converters are unique in the fact that they can read from newer OpenFlight file formats (15.x versions) and write to the much older 14.2 file format; the 14.2 file format is still quite common in the military VizSim markets. Okino writes its own FLT exporter module and has complete control over its development and refinement. The FLT importer utilizes the MultiGen OpenFlight DLLs to do all the parsing while custom Okino code walks the database tree and converts the "node based" VizSim information to scene graph data more acceptable to the common animation programs.

¥ = OpenFlight does not have keyframe animation, but rather it uses "flipbook" animation. The Okino OpenFlight exporter samples the scene at every frame and outputs instanced copies of the geometry with the matrices in the animated state for each frame. Thus, keyframe object animation is turned into flipbook animation for OpenFlight.

The Softimage-3D converters can read/write stand-alone .hrc files (which contain geometry, hierarchy, material and texture information). They can also read/write from a full Softimage database if the converter can be pointed to the Softimage-3D "rsrc" directory.

This geometry export converter writes out Softimage .xsi files. No copy of the Softimage|XSI animation program is required. Meshes (with vertex normals, vertex colors and vertex uv texture coordinates), hierarchy, cameras, lights, materials, texture maps, object animation and envelopes (mesh skinning) are supported as a baseline.

¥ = The dotXSI file format really doesn't have a sense of a "skeleton" like in other file formats. In most other formats, except for DirectX, a grouping node can be tagged as a bone or joint; when imported into its respective animation program, such nodes are visualized as bones. In the dotXSI file format you would normally create an IK chain in order to have bones visualized in the XSI user interface. However, it is not necessary to create an IK chain in order to define a "skeleton" for mesh skinning (enveloping in XSI lingo). The dotXSI file format allows any object or any grouping node to be used as a "mesh skinning bone" (deformation object) so to speak, and this is exactly how the Okino converter handles bones & mesh skinning for the dotXSI file format.

This IGES export converter allows trimmed NURBS and polygonal data to be exported in various flavors of the IGES file format. This export converter is useful for transferring data to various brands of CAD/CAM software, many of which will be able to read the IGES data exported from this converter.

In general most CAD programs which accept IGES files require that the geometry data be "trimmed NURBS" or "BREP solids". This IGES exporter will only output "trimmed NURBS" (in IGES entities 144/142/128) when the source data is also "trimmed NURBS", such as from Softimage-3D or Maya (and only when the geometry data was modeled as NURBS and not polygons).

This IGES exporter can also output all 3D geometry items as pure polygons meshes, as IGES entity # 106 (copious data). However, as outlined in the next paragraph, this option tends to confuse users of this IGES exporter since they expect such #106 data to be read into all CAD modelers. In general there are very few CAD programs which will import and accept #106 copious data polygon meshes because they only accept NURBS and not meshes. This option to output #106 copious data was added for one customer who wanted to output a text font outline to Pro/Engineer, after which the data was imported as a 2D drafting outline, traced, and turned into a 3D model using interactive Pro/E drawing tools.

¥ Important Notice ¥ This export converter CANNOT convert polygon mesh data to an IGES file as NURBS or solids. It is a very common request that Okino customers will want to take polygon mesh data from programs such as 3DS MAX, Maya, XSI, etc. into solids modeling programs such as Pro/Engineer, SolidWorks, Solid Edge, Autodesk Inventor, etc. This is just not possible, even if you don't believe it. Solids modelers require that the IGES file only contains trimmed NURBS data, usually with additional BREP stitching data to make the trimmed NURBS into "solids". Polygon mesh data cannot be converted back to trimmed NURBS or solids simply by exporting to IGES; to do that you will need to purchase a "surface reconstruction" program which allows you to interactively reconstruct a NURBS model out of a mesh model, and only then will you be able to export a newly reconstructed NURBS surface to an IGES file. We can refer you to several companies which sell surface reconstruction software: headus, CySlice v3, inSpeck, Inc., Raindrop Geomagic, ParaForm and RapidForm.