Jump to content

Performance comparison for .gltf vs .babylonjs


Recommended Posts

I do not use max, but some general guidelines.  The only aspect of speed really controlled by the exporter is file size.  When comparing text files verses binary, in general multiply the text file size by 0.25, since it is gzippable & binary is not.

For quality, some might think that more digits is MUCH better, or just secretly delight in making their customers wait:o!  using 4 digits to the right of the decimal, a mesh scaled in real life in meters is in micro-meter precision.  That could be lower than the matching texture.  Just how close are you really going to get, camera.minZ?  It gets worse when the mesh is scaled in inches or decimeters.  Max, I think, uses 8 digits (no trailing zero reduction).  Would that be in nano-inch precision? WTF.  When you combine that with face normals which smooth, this completely ridiculous.

I have done a lot of work on a pair of exporters for Blender, .babylon & inline .js.  Right now they output 4 decimals (dropping trailing 0's), but am thinking of adding a switch from 2 to 4 for vertex positions.  My own work is in decimeters.  Micro-decimeters (nanometers maybe?) is a waste, so 3 is fine.  Other vertex types are in fixed scale.  Thinking about going to 3 decimals for normals, UVs, vertex colors, matrix weights.  999 in both directions for each axis for normals & the others is very likely indiscernible from 9999.

You are also missing the category of what can be exported by each of the formats.  The more that can be "coded" in the UI, the less hand built code required.  An example is multiple animations between the Blender .babylon & .gltf exporters (.gltf not written by us).  .gltf can only export a single animation from Blender, but the .babylon (& .js) exporter can do multiples.

Link to comment
Share on other sites

@JCPalmer thanks for the reply!

The specific scenario for my use case is for webvr app, but I believe what you mentioned above also applies. Too much details would also impact the rendering performance inside the vr headset, so I guess a good balance is needed.

This is what I noticed: scene which may be rendered just fine in the browser may not be so inside the vr headset. The refresh rate seems to be drop inside the headset. Moving your head quickly side by side is usually a good test if the rendering if ok or not. If not you will see the lag which results in momentary black screen consistently.

The decimal precision you mentioned is a good point, I will look into it.

Well since you said that there is at least one limitation of the .gltf format, I guess it's best to save your work in the native format aka .babylonjs. This assumes there is no graphics quality diff between the two when loaded into the scene (using scene loader).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...