May 29, 2017 - Simplifying Regions

One of the many problems with displaying OpenSimulator content in a web browser is that the WebGL interface doesn’t handle lots of draw operations well.

I have been using the Army Research Lab’s Atropia region OAR files for testing as it includes meshes as well as many shopping scripted objects.

The Atropia regions consist of nine 256x256 meter regions arranged in a 3 by 3 pattern. This table summerizes the basic content of the regions.

test88 00 01 02 10 11 12 20 21 22
Simple prims 19 109 3088 10 416 9317 13 2 4063 0
Sculpties 0 1 0 0 187 1986 0 0 4175 0
Mesh assets 0 0 2 0 47 213 0 0 0 0

Of the many approaches to making the scene easier to render, I started with merging meshes that share textures. I decided that I could partition the scene into two types of objects: static and non-static. “Static” objects are those with no scripts and no physics. This should be buildings and plants in the scene. “non-static” objects are those that either have physics enables or have a script that is waiting for touch or collisions.

The initial thought is that all static objects can be merged and have their meshes rearranged in any way while the non-static objects need to be kept as separatable objects. The next table shows a simple partitioning of the regions into these static and non-static objects. In this table, “meshes” is the count of individual meshes after prims have been converted into meshes for rendering (a single prim will convert into 6 or more face meshes).

test88 00 01 02 10 11 12 20 21 22
Static meshes 166 928 15995 44 2910 55398 95 15 17499 1
Static materials/textures 93/4 520/30 8141/81 8/3 1209/80 27402/637 44/11 5/3 16256/38 1/1
nonStatic meshes 0 0 5799 20 0 4993 0 0 120 0
nonStatic materials/textures 0/0 0/0 2671/37 8/3 0/0 1618/94 0/0 0/0 53/15 0/0

So, all the static meshes were combined into a set of rebuilt meshes each of which shared similar surface materials (and thus could use the same WebGL draw command). Each of the non-static objects has any common material meshes combined and the resulting numbers were:

test88 00 01 02 10 11 12 20 21 22
Rebuilt static meshes 12 128 801 7 375 4014 32 3 211 1
Rebuilt nonStatic meshes 0 0 654 6 0 857 0 0 33 0
Total WebGL draws 12 128 1055 13 375 4868 32 3 244 1
draws before rebuild 166 928 21794 64 2910 60391 95 15 17619 1

As you can see from the last rows, the rebuilding and merging of common surface materials significantly reduced the number of potential WebGL draw commands.

Merging common materials gets the number of draws within usability, there are still some problems:

  • even at 1000 draws, atropia02 still crashes ThreeJS and BabylonJS with out of memory errors;
  • materials with transparency (most commonly the plant sculpties) cannot be merged as most 3D renderers will Z-order transparent meshes but do not depth order the individual triangles within a mesh;

The above scene rebuild is mesh-centric. That is, the meshes are merged without thought as to what they belonged to (other than static and non-static). Since these scenes have many duplicated meshes (the bushes scattered around the scenes), another approach would be to use mesh instancing to reduce draws. This technique will be explored next.

Comments

Apr 16, 2017 - Javascript and Flatbuffers

I spent a while figuring out Flatbuffers and Javascript so I figured I’d pass on what I learned in a Note that explains how I got it to work. My problem was that I didn’t understand how Flatbuffers worked internally so my first implementation failed.

Check out JavaScript and Flatbuffers.

Comments

Apr 9, 2017 - Flatbuffers tables in tables

Forgot to push publish.

Besides having some family over to the house for dinner, today’s coding was even more Flatbuffers coding.

I’m in the trough of disillusionment with FlatBuffers.

For FlatBuffers, one writes a schema description of records. The tool then generates serialization and deserialization code for the target language. The coolness comes from the the streamlined deserialization which minimizes data reformatting and copying.

But the programming interface to these serialization routines is a tad clunky. Firstly, you never know what type of serialization interface it is going to generate. Sometimes it will generate a single create call to build a structure and sometimes it generates a ‘start’ and ‘end’ function with ‘add’ functions for the fields. It took me a while to realize the interface difference comes between ‘struct’ and ‘table’ definitions. Another factoid that is not explained in the documentation.

Another thing I’m learning is that the serialization interface gets complex if one defines a protocol with ‘table’s inside ‘table’s. Using the schema, it is easy to define a record that includes several tables. The problem comes in the complexity of the record generation code – table generation code embedded in table generation code embedded in table generation code. The make-a-record subroutine becomes long and complex. Additionally, if a field is ever added to a table, code in several different places will need modification.

It would be nice if the code generator created some higher level code.

Comments

Apr 8, 2017 - Coding Flatbuffers

Not much new running code to report today.

There are those days when you just code infrastructure and new running features don’t come about. They will soon.

The previous version of the browser version of Basil had all its pieces integrated into one module. To effect the distributed Basil architecture, I need to create the messaging system that goes between the modules. That means improving the Basil protocol and coding all the Flatbuffers message construction and decoding code.

Comments

Apr 7, 2017 - FlatBuffer Documentation

Today’s work (besides wrestling with email setup) has been defining the Basil protocols using FlatBuffers. Mainly because someone in the project I’m working on has discovered them as a (in theory) faster way of serializing and de-serializing protocol messages.

FlatBuffers were created by some engineers at Google as a faster alternative to Protocol Buffers. FlatBuffers have a much simpler schema and the serialization format lays down the data in a data natural way so, at the receiving end, the program does not need to copy the data but have just be passed a pointer to the data in the message buffer. All this while still having optional fields and downward compatibility.

The largest problem I’ve found so far is a lack of documentation. For instance, there is a ‘union’ of tables definition in the schema. This defines a field that can be one of a selection of ‘tables’ (the schema defines ‘table’s and ‘struct’s with the latter being quicker and more compact but not extensible). The receiver of a message that includes a ‘union’ must know what was put in the field so it can parse the correct table contents. Well, there is an enumeration automatically generated and a special function that is generated so the receiver can know that. But where is the documentation? No where that I found.

In the next day or two I’ll post some code examples so people Google’ing will find some working definitions and code.

Comments