Thyme's VRML Performance Tips

Thyme's VRML Performance Tips

Utilizing Blaxxun's BSP Tree Node to Make Big Fast Worlds

A BSP tree allows us to make a world just about as big as we want without it slowing down the computer. To use a BSP tree think in terms of having your world cut up into a grid of tiles. Each tile can be thought of as a world in it self. So long as you put all your objects in a tile and don't have them overlap into any other tile it is easy to make big fast worlds. A BSP node is not a standard VRML97 node however it will be compatible with any VRML97 browser, you just wont get any speed performance gained unless you use a browser like Blaxxun Contact. Although this BSP Node was developed by Blaxxun for contact, BSP trees have been commonly used in computer games for some time that require large areas.

Any Beginner can utilize a BSP tree easily with a minimum amount of hand coding by modifying this simple raw BSP example I have here.

bspWorld.wrl The single file referenced by the bspWorld.wrl for the 64 Inline tiles is:

tile.wrl To make your own tiles just make sub worlds 100 by 100 meters centered at 0 0 0 and change the url fields for the inlines in bspWorld.wrl file so that they reference your own 100 by 100 meter tiles. You must not have any objects overlap into other tiles or you will get objects disappear at times in your world.

You can of cause get rid of the fog in this example but bare in mind the fog is in my opinion important when using a BSP for an open world setting. This is because in a large world even when using a BSP node, it's pretty essential you use a visibilityLimit or your computer will still be to slow to be able to render all that is in view. When using visibilityLimits you get objects suddenly appear which does not look at all natural. By using fog so that objects come into view gradually this problem is solved. By having the fog's visibilityRange set to the same distance as the visibilityLimit the two work very nicely together in big worlds. In this example I have set the fog and visibilityLimit to 80 meters which seems to be a pretty good compromise for the speed of current computers. It is possible to make worlds look clear and not so fogy if you use the Blaxxun's Fog2 node. By having the Fog2 node set so that there is no fog for say the first 60 meters of viewing distance and only having the last 20 meters of the 80 meters viewing range set to dense fog you can have clear worlds with only the background fading objects out of view.

    Fog2 {
         visibilityStart 60
         visibilityRange 80
     }

It is possible to have an object overlap into another tile if you cut the object so that you have different parts of the object Inlined into different tiles but if you want to keep life easy at least to begin with try to keep all objects strictly within a tile.

The example I have here has 64 tiles each tile being 100 by 100 meters which makes for a world that is 800 by 800 meters. A BSP tree can be set up to have the tiles of a different size and or a different number of tiles. Soon I hope to have seamless3d able to generate BSP trees to other specifications.

Are Spheres Faster than IndexedFaceSets?

Because I did low level programming in DirectX 3D before i ever new about vrml It never entered my mind that there would be any difference in the speed between a Sphere node and a IndexedFaceSet node in vrml. The reason I thought this was because when I programmed in DirextX there was no such thing as a function that would render a sphere only functions to render triangles. So it seemed only natural to assume that any shape that was more complex than a triangle had to be at some stage broken down into triangles. Also your hear of video card performance being measured in triangles per second. If you press F7 in contact to see the performance info displayed at the bottom of your browser in the message bar you will see readouts of triangles regardless of what the shape is, be it a IndexedFaceSet or just a single Sphere. Later I have wondered of the possibilities of the vrml 3d engine some how being able to take advantage of triangles being arranged in special case patterns such as spheres but I thought if this was the case I did not think there would be much to be gained.
sphere.wrl is a sphere with a 1 meter radius using a standard built in Sphere node
TriangleSphere.wrl is identical but made out of only triangles, it is made with the same amount of flat faces (6 times 12 flat faces).
When I press F7 I get 164 triangles for sphere.wrl. but the odd thing is I get 137 triangles for TriangleSphere.wrl !
Amazing! more triangles in a sphere node! and the quality is exactly the same. I hoped to prove that there should be no guilt felt when using IndexedFaceSets and hoped that my findings would show there was no difference in rendering performance but I never expected IndexedFaceSet to actually have less triangles and be faster to render!!!
to test the speed further I wrote two more tests

sphereSpeedTest.wrl generates 400 spheres made out of Sphere nodes. For it I get:

6.65 fps 457 primitives 65828 triangles

triangleSphereSpeedTest.wrl generates 400 spheres made out of IndexedFaceSet nodes. For it I get:

9.05 fps 457 primitives 54857 triangles

You can spend good amounts of money on hardware to get this sort of speed difference. Downloads may well be faster when using sphere nodes but after the download you only reap a loss in render speed if using Spheres in place of IndexedFaceSets.
Could there be more to this? maybe it depends on the hardware? or version of software? or driver? perhaps its old code in the 3d engine that use to be more efficient maybe not for rendering speed but memory efficiency. If this is the case I would think this would be now a out dated value, as now memory is so cheap.
I have all my code here open for anyone to verify my findings

What about 4 Sided Polygons?
QuadogonSphere.wrl is the same as TriangleSphere.wrl except the triangles that share two vertices and share the same plane angle are replaced with one 4 sided polygon making it look exactly the same as a Sphere node in wire frame mode. Having fewer polygons reduces the file from 1039 bytes to 983 bytes (gziped). Not much of a difference here but the difference would be greater if no normals were used and or if the 2 shapes being compared both had more polygons. This is because when we increase the number of coordinate points our coordIndex numbers increase their digit count.

quadogonSphereSpeedTest.wrl is the same as triangleSphereSpeedTest.wrl except the spheres contain 4 sided polygons. When I press F7 contact displays the same number of triangles to when the spheres were made out of 100% triangles. Its hard to be sure here if there is any speed difference between the 2 indexedFaceSet tests. I wondered if the quadogonSphereSpeedTest.wrl on average got slightly less frames per second but if there is any difference its very little.
In this test we don't see triangles gain much if anything over 4 sided polygons but it at least confirms what I thought should be the case that no render speed is gained by converting triangles to 4 sided polygons.

Speeding Things Up Using Matrices
To my understanding vrml transform nodes have to keep being set up or at least watched by the 3d engine because all transform nodes can be potentially animated. Since setting up transform nodes are expensive on CPU processing power this is wasteful for objects that never need to be animated. One theoretical solution is to make each object in an IndexedFaceSet and position the coordinates where they are wanted globally so as to avoid any need for Transformations. This would in practice probably be awkward to do and could result in huge amounts of download time because there would be no downloaded data ever reused to make other objects. The solution here is to use the vrmlscript VrmlMatrix class to transform all your objects to where they are wanted just like you would when using a Transform node but the difference is its only done once when the world initializes

triangleSphereMatrixSpeedTest.wrl is an example of using matrices to transform the each one of the 400 spheres to their targeted locations. In this example i get disappointingly no better results than i did with the triangleSphereSpeedTest.wrl example which uses conventional Transform nodes. I am not sure what the reason for this is. Perhaps the objects that share the same internal Transform node are not shared but created for each primitive by the 3d engine.

If this is the case we should see a performance increase if we make all the spheres into one single IndexedFaceSet
oneIFSSpeedTest.wrl is such an example. I get:

11.03fps 28 primitives 54857 triangles

this is a significant improvement! it also goes to show that if you use optimization techniques like in our triangleSphereMatrixSpeedTest.wrl and not test our theory we may be experiencing pain with no gain.
Comparing sphereSpeedTest.wrl to oneIFSSpeedTest.wrl demonstrates how IndexedFaceSets can well and truly out perform higher level nodes like Sphere nodes. Because spheres are on a to higher level, we can't get to their vertices to tweak them like we can with the lower level IndexedFaceSet node.

You need blaxxun Contact VRML plugin for these multi-user examples

www.web3d.org