机械英文文献翻译

英文原文

Extending Blender: Development of a Hepatic Authoring Tool

Abstract -In this paper, we present our work to extend a well known 3D graphic

modeler -Blender -to support hepatic modeling and rendering. The extension tool is

named HAMLAT (hepatic Application Markup Language Authoring Tool). We

describe the modifications and additions to the Blender source code which have been

used to create HAMLAT Furthermore, we present and discuss the design decisions

used when developing HAMLAT, and also an implementation "road map" which

describes the changes to the Blender source code. Finally, we conclude with

discussion of our future development and research avenues.

Keywords Hepatics HAML Graphic Modelers Blender Virtual Environments.

I. Introduction

A. Motivation

The increasing adoption of hepatic modality in human-computer interaction

paradigms has led to a huge demand for new tools that help novice users to author and

edit hepatic applications. Currently, the hepatic application development process is a

time consuming experience that requires programming expertise. The complexity of

hepatic applications development rises from the fact that the hepatic application

components (such as the hepatic API, the device, the hepatic rendering algorithms,

etc.) need to interact with the graphic components in order to achieve synchronicity.

Additionally, there is a lack of application portability as the application is tightly

coupled to a specific device that necessitates the use of its corresponding API.

Therefore, device and API heterogeneity lead to the fragmentation and disorientation

of both researchers and developers. In view of all these considerations, there is a clear

need for an authoring tool that can build hepatic applications while hiding

programming details from the application modeler (such as API, device, or virtual

model).

This paper describes the technical development of the hepatic Application

Markup Language Authoring Tool (HAMLAT). It is intended to explain the design

decisions used for developing HAMLAT and also provides an implementation "road

map", describing the source code of the project.

B. Blender

HAMLAT is based on the blender [1] software suite, which is an open-source 3D

modeling package with a rich feature set. It has a sophisticated user interface which is

noted for its efficiency and flexibility, as well as its supports for multiple file formats,

physics engine, modem computer graphic rendering and many other features.

Because of blender's open architecture and supportive community base, it was

selected as the platform of choice for development of HAMLAT. The open-source

nature of Blender means HAMLAT can easily leverage its existing functionality and

focus on integrating hepatic features which make it a complete hap to-visual modeling

tool, since developing a 3D modeling platform from scratch requires considerable

development time and expertise in order to reach the level of functionality of blender.

Also, we can take advantage of future improvements to blender by merging changes

from its source code into the HAMLAT source tree.

HAMLAT builds on existing Blender components, such as the user-interface and editing tools, by adding new components which focus on the representation, modification, and rendering of hepatic properties of objects in a 3D scene. By using Blender as the basis for HAMLAT, we hope to develop a 3D hepatic modeling tool which has the maturity and features of Blender combined with the novelty of hepatic rendering.

C. Project Goals

As previously stated, the overall goal for the HAMLAT project is to produce a polished software application which combines the features of a modem graphic modeling tool with hepatic rendering techniques. HAMLAT has the "look and feel" of a 3D graphical modeling package, but with the addition of features such as hepatic rendering and hepatic property descriptors. This allows artists, modelers, and developers to generate realistic 3D hippo-visual virtual environments. A high-level block diagram of HAMLAT is shown in Figure 1. It illustrates the flow of data in the hepatic modeling. HAMLAT assists the modeler, or application developer, in building hap to-visual applications which may be stored in a database for later retrieval by another hepatic application. By hippo-visual application we refer to any software which displays a 3D scene both visually and

hectically to a user in a virtual setting. An XML file format, called HAML [2], is used to describe the 3D scenes and store the hippo-visual environments built by a modeler for later playback to an end user.

Traditionally, building hippo-visual environments has required a strong technical and programming background. The task of hectically rendering a 3D scene is tedious since hepatic properties must be assigned to individual objects in the scene and currently there are few high-level tools for accomplishing this task. HAMLAT bridges this gap by integrating into the HAML framework and delivering a complete solution for development of hippo visual applications requiring no programming knowledge.

The remainder of the paper is organized as follows: in Section 2, we present the proposed architecture extensions and discuss design constraints. Section 3 describes the implementation details and how hepatic properties are added and rendered within the blender framework. In section 4 we discuss related issues and future work avenues.

II. SYSTEMOVERVIEWANDARCHITECTURE

The blender design philosophy is based on three main tasks: data storage, editing, and visualization. According to the legacy documentation [3], it follows a data visualize-edit development cycle for the 3D modeling

A 3D scene is represented using data structures within the Blender architecture. The modeler views the scene, makes changes using the editing interface which directly modifies the underlying data structures, and then the cycle repeats.

To better understand this development cycle, consider the representation of a 3D object in Blender. A 3D object may be represented by an array of vertices which have been organized as a polygonal mesh. Users may choose to operate on any subset of this data set. Editing tasks may include operations to rotate, scale, and translate the

vertices, or perhaps a re-meshing algorithm to "cleanup" redundant vertices and transform from a quad to a triangle topology. The data is visualized using a graphical 3D rendered which is capable of displaying the object as a wireframe or as a shaded, solid surface. The visualization is necessary in order to see the effects of editing on the data. In a nutshell, this example defines the design philosophy behind blender's architecture.

In blender, data is organized as a series of lists and base data types are combined with links between items in each list, creating complex scenes from simple structures. This allows data elements in each list to be reused, thus reducing the overall storage requirements. For example, a mesh may be linked by multiple scene objects, but the position and orientation may change for each object and the topology of the mesh remains the same. A diagram illustrating the organization of data structures and reuse of scene elements is shown in Figure 2. A scene object links to three objects, each of which link to two polygonal meshes. The meshes also share a common material property. The entire scene is rendered on one of several screens, which visualizes the scene.

We adopt the Blender design approach for our authoring tool. The data structures which are used to represent objects in a 3D scene have been augmented to include fields for hepatic properties (e.g., stiffness, damping); user interface components (e.g., button panels) which allow the modeler to change object properties have also been updated to include support for modifying the hepatic properties of an object. Additionally, an interactive hippo-visual rendered has been implemented to display the 3D scene graphically and hectically, providing the

modeler or artist with immediate feedback about the changes they make to the scene.

A class diagram outlining the changes to the blender frame work is shown in Figure 3. Components which are pertinent to HAMLAT are shaded in gray. HAMLAT builds on existing blender sub-systems by extending them for hepatic modeling purposes. The tactile and kinesthetic cues, which are displayed due to interaction with virtual objects, are typically rendered based on the geometry of the mesh. in this data type. Other scene components such as lamps, cameras, or lines are not intuitively rendered using force feedback hepatic devices and are therefore not of current interest of chaotic rendering.

An augmented version of the mesh data structure is shown in Figure 4. It contains fields for vertex and face data, plus some special custom data fields which allow data to be stored to/retrieved from disk and memory. We have modified this data type to include a pointer to a hepatics data structure, which stores hepatic properties such as stiffness, damping, and friction for the mesh elements (Figure 5).

Similarly to the built-in graphical rendered, HAMLAT uses a custom rendered for displaying 3Ds scenes graphical and hap call, and is in end of the connectivity is given in the next section.

IMPLEMENTATION

Data Structure

Blender uses many different data structures to represent the various types of objects in a 3D scene a polygonal mesh contains the location and topology of vertices;

a lamp contains color and intensity values; and a camera object contains intrinsic viewing parameters.

The Mesh data structure is used by the blender

Blender rendered. This component is developed independently since heretical and graphical rendering must be performed simultaneously and synchronously. A simulation loop is used to update hepatic rendering forces at a rate which maintains stability and quality.

Where the force feedback vector which is displayed to the user is computed using the stiffness coefficient (variable name stiffness) for the object and x the |penetration depth (displacement) of the hepatic proxy into an object. The stiffness coefficient has a range of [0,1],where 0 represents no resistance to deformation and 1 represents the maximum stiffness which may be rendered by the hepatic device. The damping of an object defines its resistance to the rate of deformation due to some applied strut Hepatices force. It is typically rendered using the force equation:

Hepatic Properties

In this section we'll briefly discuss the hepatic properties which may currently be modeled using HAMLAT. It is important for the modeler to understand these properties and their basis for use in hepatic rendering.

The stiffness of an object defines how resistant it is to deformation by some applied force. Hard objects, such as a rock or table, have very high stiffness; soft objects, such as rubber ball, have low stiffness. The hardness-softness of an object is typically rendered using the spring-force equation: range of [0,1] and may be used to model viscous behavior of a material. It also increases the stability of the hepatic rendering loop ford stiff materials.

The static friction (variable name striation) and dynamic friction (variable name direction) coefficient are used to model the frictional forces experienced while exploring the surface of a 3D object. Static friction is experienced when the proxy is not moving over the object's surface, and an initial force must be used to overcome static friction. Dynamic friction is felt when the proxy moves across the surface, rubbing against it. Frictional coefficients also have a range of /0,1], with a value of 0 making the surface of a 3D object feel "slippery" and a value of 1 making the object feel very rough.

B. Editing

Blender uses a set of non-overlapping windows called spaces to modify various aspects of the 3D scene and its objects. Each space is divided into a set of areas and panels which are context aware. That is, they provide functionality based on the selected object type. For example, if a camera is selected the panel will display components which allow the modeler to change the focal length and viewing angle of the camera, but these components will not appear if an object of another type is selected.

Figure 6 shows a screen shot of the button space which is used to edit properties for a hepatic mesh. It includes user-interface panels which allow a modeler to change the graphical shading properties of the mesh, perform simple re-meshing operations, and to modify the hepatic properties of the selected mesh.

HAMLAT follows the context-sensitive behavior of Blender by only displaying the hepatic editing panel when a polygonal mesh object is selected. In the future, this panel may be duplicated to support hepatic modeling for other object types, such as NURB surfaces.

The blender framework offers many user-interface components (e.g., buttons, sliders, pop-up menus) which may be used to edit the underlying data structures. The hepatic properties for mesh objects are editable using sliders or by entering a float value into a text box located adjacent to the slider. When the value of the slider/text box is changed, it triggers an event in the blender windowing a unique identifier indicates he first pass renders the scene graphically, and the second pass renders it hectically. The second pass is required because the Open Hepatics toolkit intercepts commands send to the OpenGL pipeline and uses them to display the scene using hepatic rendering techniques. In this pass, the hepatic properties of each mesh object are used much in the same way color and lighting are used by graphical rendering they define the type of material for each object. To save CPU cycles, the lighting and graphical material properties are excluded from the hepatic rendering pass.

Figure 7 shows source code which is used to apply the material properties during the hepatic rendering pass. The hepatic rendered is independent from the Blender framework in that it exists outside the original source code. However, it is still heavily dependent on Blender data structures and types.

D. Scripting

The Blender Python (By) wrapper exposes many of the internal data structures, giving the internal Python scripting engine may access them. Similar to the data structures used for representing mesh objects in the native Blender framework, wrappers allow user defined scripts to access and modify the elements in a 3D scene.

An import script allows 3D scenes to be read from a HAML file and reproduced in the HAMLAT application; an export script allows 3D scenes to be written to a HAML file, including hepatic properties, and used in other HAML applications.

The By wrappers also expose the Blender windowing system. Figure 9 shows a panel which appears when the user exports a 3D scene to the HAML file format. It allows the user to specify supplementary information about the application such as a description, target hardware, and system requirements. These are fields defined by the HAML specification [2] and are included with the authored scene as part of the HAML file format. User-interface components displayed on this panel are easily extended to agree with the future revisions of HAML.

Currently, HAMLAT supports basic functionality for modeling and rendering hippo-visual applications. Scenes may be created, edited, previewed, and exported as part of a database for use in by other hap to-visual applications, such as the HAML player [6]. However, there is room for growth and in there are many more ways we can continue leveraging existing blender functionality. As per future work, we plan to extend HAMLAT to include support for other hepatic platforms and devices. Currently, only the PHANTOM series of devices is supported since the interactive rendered is dependent on the Open Hepatics toolkit [5]. In order to support other devices, a cross-platform library such as Chai3D or hatpin may be used to perform

rendering. These libraries support force rendering for a large range of hepatic hardware. Fortunately, due to the modularity of our implementation, only the interactive hepatic rendering component need be altered for these changes. In addition to support multiple hardware platforms, a user interface component which allows the selection and configuration of hepatic devices will be important. Most likely, this will be added as part of the user preferences panel in blender.

Adding support for hepatic devices as part of editing tasks is also a planned feature. This will allow the modeler to modify the shape, location, and other properties on in-scene objects. For example, the sculpting mode in Blender allows a user to manipulate the geometry of a 3D object using natural interface, similar to reshaping a piece of clay. HAMLAT will build on this technology by allowing the modeler to manipulate the virtual clay using high DOF hepatic interfaces.

中文译文

延长搅拌机：

摘要-在本文中，我们目前的工作是拓展一个众所周知的三维图形建模-搅拌机，来支持触觉建模和绘制。这种延长搅拌机命名为HAMLAT（触觉应用标记语言创作工具） 。我们描述修改和添加搅拌器的源代码，其中已使用创造HAMLAT此外，我们提出和讨论设计的决定时所用的发展中的HAMLAT， 也是一个“路线图”的实施 ，其中描述了搅拌器的源代码的改变。最后，我们的结论是讨论我们未来的发展及研究途径。

关键词-触觉，HAM，图形建模，搅拌器， 虚拟环境。

一．介绍

A. 动机

越来越多的通过触觉的方式在人类-电脑的互动方式的应用造成了对新的工具的巨大的需求，这些新的工具可以帮助新手用户写作和编辑触觉应用。目前，触觉的应用发展过程是一个耗时的经历，它需要编程知识。触觉应用的复杂性，从一个事实，即触觉应用组件（如触觉的空气污染指数，设备，该触觉描写算法等）需要互动图形组件，以实现同步。

此外，一个缺少应用可能性，因为应用是紧耦合到特定的装置必须使用其相应的空气污染指数。因此，设备和空气污染指数的异质性，导致两个研究人员和开发人员分裂和迷失方向。在检查所有需要考虑的事时，有对创作工具明确的需要，可以建立触觉的应用， 也可以隐藏在应用程序建模的编程（如空气污染指数，装置，或虚拟模型） 。

本文介绍了技术发展的触觉应用标记语言创作工具（HAMLAT）。它的用意是解释设计决定用于发展HAMLAT,还提供了执行“路线图”的一个应用，描述该项目的源代码。

B搅拌器

HAMLAT是以搅拌器[ 1 ]软件套件为基础， 这是一个开放源码的三维建模套件拥有丰富的功能集。它有一个先进的用户界面，它以它的高效率和灵活性，以及它的支援多种档案格式，物理引擎，调制解调器等功能出名。

由于搅拌器的开放式体系结构和支持共同的基础，它被选定为发展of hamlet平台的首选。搅拌器开放资源的性质，意味着HAMLAT可以轻易地利用其现有的功能和集中讨论相结合的特点，使其成为一个完整的触觉-可视化建模工具，发展为一个三维建模平台，从无到有，需要相当多的发展时间和专门技术，以便达到搅拌机水平的功能，。同时，我们可以利用由从它的源代码到HAMLAT源代码树的合并的变化改善未来的搅拌器

HAMLAT建立在现有搅拌器组件，如用户界面和编辑工具，通过加入新组建，其中侧重在一个三维场景用于代表修改和渲染触觉特性的物体。HAMLAT用搅拌器并以此为基础，我们希望建立一个三维触觉建模工具，它具有成熟等特点，并结合搅拌器与of hepatic渲染的新颖性。

在编写本报告的时候，HAMLAT是基于搅拌器2.43版本的源代码。

C.项目目标

如前所述，HAMLAT项目的总体目标是为了产生一个抛光应用软件，它结合了调制解调器图形建模工具的特点与触觉绘制技术。HAMLAT有三维图形建模软件包“外观与感觉”，但是还有另外的功能，例如，作为触觉渲染和触觉直观的描述。这个允许艺术家，建造家，和开发商产生逼真的三维触觉 -可视化虚拟环境。 一个HAMLAT高层次的框图结果，在图1中表明。它说明了在触觉模型的数据流，HAMLAT协助建模者，或应用开发商，在建设触觉 -视觉应用，可存储在一个数据库中供日后由另一触觉的应用检索。由触觉-视觉的应用我们参考任何在视觉上显示三维场景的软件， hectically给一个用户一个虚拟的设置。一个XML文件的格式，所谓HAML[ 2 ] ，是用来描述三维场景和储存触觉-视觉环境，通过兴建一建模后播放给最终用户。

传统上，建设触觉 -视觉环境已需要一个强有力的技术和方案的背景。 绘制三维场景的任务是繁琐的。所以在现场触觉性能必须分配给个人，为完成这项任务，目前有几个问题。HAMLAT桥梁，这个差距通过融入helm框架和提供完整的解决方案，发展触觉-视觉应用，无需编程知识。

其余的文件，组织情况如下：在第2部分中，我们目前建议的架构扩展并讨

论设计的限制。在第3部分中介绍执行的细节，以及触觉性使内部的搅拌器框架能如何补充和拓展。第4部分我们讨论工作中有关的问题和今后的工作途径。

二． System over view and architecture

搅拌器的设计理念，是基于三个主要任务：数据存储，编辑和可视化。据遗留的文件[ 3 ] ，它沿袭了开发周期为三维建模数据管道可视 - 编辑。一个三维场景代表的是在该搅拌器结构中使用数据结构。该建模者观看现场，进行更改，使用编辑界面直接修改底层的数据结构，然后循环重复。

为了更好地了解这方面的发展周期，考虑在搅拌器中一个三维物体的代表体。一个三维物体可代表一个数组的顶点，其中有举办了作为一个多边形网格。用户可以选择运作的任何数据集。编辑的任务可能包括行动，旋转，称重和翻译顶点，或者从四到三角拓扑结构，也许重新啮合算法，“清理”多余的顶点和变换，。数据可视化使用图形三维渲染这是能够显示的对象作为一个线框或作为一个阴影，固体表面可视化是必要的，就编辑整体而言便见影响，总而言之，这个例子定义设计背后是搅拌器的建筑理念。

在搅拌机，数据是作为一个有组织的一系列名单和相应的数据类型相结合，与项目之间的联系在每份名单中，从简单的结构中创造复杂的场景，这使得数据元素，在每个清单都可以重复使用，从而减少整体的存储需求。举例来说，网格可能与多个现场的物体相连接，但

位置和方向可能会改变，而每一个物件和拓扑结构的网格保持不变。说明该组织的数据结构和重用现场的要素是在如图2中所示。一个现场物件连结三个对象，其中每个链接到两个多边形网格。该网格也都有一个共同的物质财产。整个现场呈现的由数个可视化现场的屏幕到一个网络上。

我们采用搅拌器的设计方法，为我们创作工具。数据结构用来代表物体在一个三维场景已扩大到包括该领域的触觉特性（例如，刚度， 阻尼）；用户界面组件（例如，按钮面板）

允许建模者改变对象属性而得到更新，包括支持修改触觉性能的一个对象。此外，互动触觉 -视觉渲染已实施，以显示三维场景生动和hectically ，反馈现场有关情况即时提供给建模者或艺术家。

在现在的HAMLAT的版本中，搅拌机的框架的写稿包括如下：

* 数据结构代表触觉性能，

* 编辑界面为了修改触觉性能，

* 外部转译为展示及预览启用的场面，

* 脚本让场面拟进口/出口以HAMLAT的档案格式。

概述了搅拌器框架的变化，在图3中所示。与HAMLAT有关的组建是灰色的阴影。HAMLAT建立在现有搅拌器子系统上，延长他们是为了为触觉建模。触觉和动觉线索， 显示由于与虚拟物体互动，在通常提供的基础上，几何的网格，无损检测存储在此数据类型。现场的其他部件，如灯光，照相机，或线条不能直观地提供使用力反馈触觉设备，但并不是现在触觉设计的兴趣所在。

增强版的网格数据结构如图4所示。它包含的领域顶点和面对数据，再加上一些特殊的自定义数据领域，允许数据被储存到/来自磁盘和内存。我们已修改这个数据类型，包括一个指针，以mastics数据结构，储存触觉性能如刚度，阻尼和摩擦，为网格元素（图5 ） 。

A2.编辑网络数据类型

值得注意的是网络数据类型由一个固定的数据类型，名字叫编辑网络，它在编辑网络时使用，它包含了定点，边缘，和全局网络的面对数据的复件。当用户转到编辑代码时，搅拌机把数据从一个网络复制到一个编辑网络，当编辑结束，那么数据就复制回去。

必须注意确保触觉数据结构在复制的过程中保持完整，编辑网络没有转变成包含触觉数据的复件，但是这个可以在未来的版本中改变（如果这个功能被要求的话），这个编辑方式主要应用在修改地质学和地理学网络，不是触觉和图像的拓展的特征。

A3.触觉特性

在这个部分中，我们简要的讨论触觉特性，这个可能用HAMLAT来进行模型化。建模者在应用触觉渲染了解这些特性和他们分布是重要的。

一个坚硬的物体，决定了坚固程度。，例如一块岩石或者一个桌子，都有非常高的坚硬度。软物体，例如橡胶球，是有非常低的硬度。一个物体的这种硬度和软度用在弹跳力公式：

当反作用力f呈现在用户面前，计算是用物体的硬度系数Ks(变量名为硬度)和x渗透深度（转移）。硬度系数的范围是在0和1之间。0表示畸变没有抵抗力。而1是最大值，它可以被触觉设备测量到一个物体的抑制力，代表了它对畸变的抵抗力。它通常用公式：

Kid是抑制系数（变量名是抑制），并且dx/dy是速度。这个抑制系数范围也是在0和1之间。一系列的[ 0,1 ] ，并可能被用来模拟粘性行为的物质。它还增加了稳定性静摩擦（变数名称striation ）和动态摩擦（变数名称direction ）系数是用来摩擦力量的模型，在有经验的情况下， 探索表面的三维对象。

静摩擦力在运行时，代理是不能移动超过物体表面的，初步的力量必须用来

克服静摩擦。动态摩擦是感觉的举动，在整个表面，与摩擦相反。 摩擦系数也有一个范围【 0,1 】 ，值为0时，表面上的一个三维物体觉得“滑” ，值为1时，感到非常粗糙的。摩擦力通常呈现在一方向上，切向碰撞点的触觉在物体表面。

B 编辑搅拌器使用一组非重叠的窗口，也即是所谓的空间来修改各方面的三维场景和对象。每个空间分成了一套领域和背景。也就是，他们提供功能在选定对象的类型的基础上。例如，如果一个相机选定的嵌板即将展出组件，允许建模者改变摄像机的焦距长度和视角，但如果对象的另一种类型是选定的，这些组件将不会出现。

图6显示屏幕发射按钮 ，它是用来编辑触觉网格的属性的。它包括用户界面面板允许建模改变图形遮光性能的网格，进行简单的重新啮合行为，并修改触觉性能而选择网格。

HAMLAT沿袭了脉络的敏感行为，当搅拌器只显示触觉编辑小组时， 多边形网格对象被选中。在未来的日子，这个小组可能会重复支持触觉建模的其他物体类型 ， 例如NURB表面。

搅拌器框架提供了许多用户界面元件（例如，按钮，滑块，弹出式菜单），在可用于编辑的基本数据结构。那个触觉性能的网格对象是编辑的使用滑块，或进入一个浮动值到一个文本框位于毗邻的滑竿。当价值滑块/方块值改变时，触发一个事件，在搅拌器窗口会显示一个独特的识别标志，表明窗分制度。 这项活动是为触觉和HAMLAT代码应称为更新触觉用于当前选定的主题词。

C .触觉视觉渲染

搅拌器目前支持的图形绘制场景使用内部渲染或外部渲染（例如， [ 4 ] ） 。本着这一精神，触觉渲染所使用的HAMLAT已发展为一个外部渲染。它使用OpenGL和open hepatics工具箱[ 5 ]分别执行图形和触觉的渲染。

三维场景，正在建模的渲染应用在两个阶段：第一个是图像场景，第二个是触觉。第二个是要求的，因为open hepatics工具包拦截命令传送给OpenGL的管道和使用它们，以显示现场用触觉渲染技术。在此通过触觉性能，使每个网格对象使用得多，在通过同样的方式和颜色，照明所使用的图形呈现给他们，界定这类材料为每个对象节省CPU周期， 照明及图形材料从触觉绘制通过时被排除。图7显示的源代码是用来适用材料性能在触觉绘制通过。那个触觉渲染是独立的从搅拌机框架在它的存在以外的原始源代码。然而，它仍然严重依赖于搅拌器的数据结构和类型。

D脚本

搅拌器包装，暴露了许多内部数据结构，使内部的Python 脚本引擎可能访问它们类似的数据结构，用于代表网格物体在这个搅拌器的框架内包装，一个三维场景让用户定义的脚本访问和修改的内容。

一个网格物体的触觉特性可以通过网络包装来达到已添加到每个这些阶段和通过访问的Python脚本系统。图8 显示原码来读取触觉性能，从网格对象和出口到一个文件。类似的代码是用来进口/ 出口HAML场景从到档案。

在HAMLAT的应用,脚本允许从helm文件中读和转载进口的三维场景， 出口脚本，允许三维场景要写入到一个HAML文件中，并且应用在另一个HAML应用中

该bay封套也揭露搅拌器窗制度。图9显示了小组时，会出现用户出口三维场景向helm档案格式。它允许用户指定的补充资料关于应用程序，如描述，目标硬件和系统需求。这些都是领域所定的helm规格[ 2 ] ，并已列入与执笔的现场，作为部分的helm档案格式。 用户界面组件上显示的这个小组很容易扩展到未来修改的HAML。

目前，HAMLAT支持基本功能建模和绘制触觉 -视觉应用。场景可以创建，编辑，预览，和出口的部分一个数据库，以便使用在其他触觉-视觉应用。不过，还有很多方法，能够让我们继续利用现有的搅拌器的功能。 作为今后的工作中，我们的扩展计划，以HAMLAT包括支持其他触觉平台和设备。

目前，HAMLAT一系列的设备是支持自互动渲染，是依赖于该openhaptics工具箱[ 5 ] 。为了支持其他设备，跨平台的图书馆，如chai3d或haptik可能被用来执行渲染。这些图书馆支持绘制大范围的触觉硬件。所幸的是，由于我们执行中模块化，只有互动触觉渲染需要改变。 此外，支持多种硬件平台， 用户界面组件，使选拔和配置触觉设备将是重要的。多数的可能，这将是，增加一条，作为用户使用部分编好程序在搅拌器中。 加入支持触觉设备的一部分，编辑任务也是有计划的功能。这将方便建模修改形状，位置。和其他在现场的对象。举例来说，多选择方式在搅拌允许用户操纵地理的三维物体用自然的界面，类似重塑一块粘土。HAMLAT将在此基础上让建模操纵接口。

本文来源：https://www.bwwdw.com/article/ki1m.html