HyperFun project and VRML language

Jiri Zara, Czech Technical University in Prague, Czech Republic

1. Introduction

Polygonal representations of geometrical models resulting from HyperFun computations typically consist of thousands of vertices and faces. This amount of data is hard to efficiently encode into VRML format for final web presentation. Although standard compression of VRML files utilizing 'gzip' decreases the file size from MBs down to hundreds of kBs, such sizes are still too big for fast transmission from a server to arbitrary users.

The optimal solution would be to incorporate the HyperFun solver (polygonizer) directly into VRML browsers and to transfer the HyperFun description only. Since the process of creating polygonal representation is time consuming, we cannot expect that VRML browsers targeted primarily for fast rendering will solve it in the near future. The expectations that VRML browsers could render HyperFun objects directly from HyperFun description seem to be too premature and excessive today.

2. External polygonizer

While the HyperFun project is strong and efficient tool for modeling, the VRML language is platform independent descriptive tool for real-time presentation of 3D data. One possibility to combine good features of both technologies is to design a HyperFun polygonizer as a Java program connected to VRML Script node and encapsulated into newly prototyped "HyperFun" VRML node. Such a node could be a part of a VRML scene and could be processed (evaluated) either in initial phase or on request during the presentation of a scene. Since Java programs (bytecodes) are platform independent, such a Script could be evaluated by arbitrary VRML browser.

If the polygonizer is designed as a script written in Java, it must be transferred from a server each time a user downloads a VRML file referencing HyperFun node. Thus the size of a bytecode for the polygonizer should be maximally about 300 kBytes. Fortunately, downloaded Java classes are stored in a cache of WWW browsers. This will eliminate further transfer of such a polygonizer when a user downloads other scenes and HyperFun objects from the same server.

3. HyperFun node for VRML

A new VRML node definition is typically based on PROTO statement. Let HyperFun be a new prototyped node. Then it should contain HyperFun description in textual form, several parameters for a polygonizer (density of samples, 3D bounding box where HyperFun object is to be located) and resulting polygonal representation. The representation can be either "exported" outside the HyperFun node using an eventOut like:

eventOut SFNode representation_changed

or the HyperFun node can be of type "geometry" or better said "special IndexedFaceSet node". The second case is used in the following specification. It means that HyperFun node holds both textual definition of HyperFun object and its polygonal representation that is rendered as soon as geometrical data are computed. The HyperFun node can be placed into a VRML scene graph where a geometry is expected. When assigned as a child of a Shape node it can be colored or even textured by appropriate Appearance node.

PROTO HyperFun [ 
  field    MFString function        []
  field    SFVec3f  bboxCenter      0 0 0
  field    SFVec3f  bboxSize        2 2 2
  field    SFInt32  density         10        # >=2
  field    SFFloat  creaseAngle     0
  field    SFBool   solid           TRUE  
  eventIn  SFInt32  set_density
  eventOut SFInt32  density_changed
] { ... }

The function field contains textual definition of a HyperFun object. It can be arranged in such a way that each single string in MFString field contains one line of source code of the description. Another possibility is to specify one HyperFun function (routine) per one string. A final arrangement will depend on a polygonizer requirements.

The density field informs a polygonizer about density of samples within 3D bounding box specified by bboxCenter and bboxSize fields. Default value 10 means that the whole bounding box will be sampled by 10 by 10 by 10 crossing lines in each direction x, y, and z. The default sampling will thus consist of 1000 samples. Minimal value of density is 2. It represents samples in bounding box corners only. Default bounding box covers area from -1 to 1 meter around the origin of the coordinate space.

A HyperFun node will create an initial visible representation immediately after it is loaded by a VRML browser. When an eventIn set_density is received by the node and the new value is different from the previous density, a new geometrical representation will be computed. The eventOut density_changed will be sent out appropriately.

Fields creaseAngle and solid have the same meaning as corresponding fields in IndexedFaceSet node definition.

4. Examples

For demonstration purposes, a simplified version of a HyperFun node has been implemented with the following limitations:

The polygonizer is implemented in JavaScript, not in Java. It leads to a slow evaluation of a function.
Instead of description of hyper function in form of

All examples below refer to the HyperFun prototype using the following VRML code:

EXTERNPROTO HyperFun [
field    MFString function
field    SFVec3f bboxCenter
field    SFVec3f bboxSize
field    SFInt32 density
field    SFFloat creaseAngle
field    SFBool   solid
eventIn SFInt32 set_density
eventOut SFInt32 density_changed
] "hyperlib.wrl#HyperFun"

Click on image to get a page with VRML world:


`HyperFun {` `function "xx+yy"` `density 30` `solid FALSE` `}`	`HyperFun {` `function "Math.abs(x*y)/3"` `density 30` `bboxSize 6 6 6` `solid FALSE` `}`	`HyperFun {` `function "Math.cos(x*y)/3"` `density 30` `bboxSize 10 10 10` `solid FALSE` `creaseAngle 1.57` `}`

One more example has been created, where a user can interactively set the density by clicking on appropriate button. The function is the same as the right function in the table above.