Progressive Mesh Streaming: Knowledge exchange

I’m going to write some sort of paper about Progressive Mesh Streaming for WebGL. Progressive Mesh Streaming is not a new technique, it already exists for many years. But it is particular interesting for web based 3D applications because you need to transfer all data of an asset over a (possibly slow) network before you can display it. To avoid the associated latency, you can try to compress 3D data in a way that allows streaming and progressive decoding.

In other words: You do not load the entire model and then parse/display it like with common 3D formats. Instead, you stream the data, parse single chunks and progressively increase the resolution of the model to the highest level.

Progressive Mesh Streaming seems to be a very popular topic in the scientific community. But I found no references about its practicability in real products so far. Does anyone have experience in the usage of Progressive Mesh Streaming in context of WebGL? Besides, could Progressive Mesh Streaming be potentially interesting/useful for your projects?

9 Likes

Hi Michael,

Are you thinking of a progressive LOD streaming like in this example?

If so we and our partners/customers would be highly interested on that and would love to assist you where we can.

Greetings!
VisCircle Team

1 Like

@VisCIrcle As announce, I’d like to share some studies and conclusions about Progressive Mesh Streaming in the browser. The text is part of my master’s thesis which is focused on web-based 3D engine design. Have a look at chapter 3.4 Progressive Mesh Streaming. It provides some sort of evaluation of this topic in the web context.

Engine-Design für webbasierte 3D- und VR-Anwendungen (3.3 MB)

Unfortunately, the thesis is in German and I did not have the time so far to translate certain parts into English. Sorry for this! Try to do this in the future. But since you guys (@VisCIrcle) are from Germany, it should be at least no problem for you^^.

3 Likes

For Tesseract i use progressive asset streaming for the most content, the larger the scene is and the more different assets can be managed spatially, the more it becomes useful to dynamically load/unload them. Impostors (billboard stripes) are loaded first as well as proxy models (lowest possible poly representation, basically LOD geometries). The system optionally uses a websocket connection intead single HTTP requests what makes a quiet big difference for a lot files.

2 Likes

Wow Michael!
Thank you very much.
Great Master Thesis!
We will share that across our team.

1 Like

I do not know if this can help with anything… I created a progressive mesh/texture loader for SEA3D already a few months ago. All in one single file.
Example:
https://sunag.github.io/sea3d/Examples/Programmer/Three.JS/mascot.html

2 Likes

@Mugen87 please translate this to English! I’d love to read it.

@Mugen87 do we have any update on this? My projects needs it desperately as the scenes that I load generally are really heavy even after optimizing it as much as I can - rendering it in chunks can solve my problem to a great extent.

Sry, I’m not going to work at this in the next time. I’m focused on enough other topics^^

@Mugen87
On the original topic. I looked into progressive mesh streaming for my game engine. My verdict was:

  • streaming meshes are not straight-forward to use, implementations that do exist are lacking in various way when it comes to prformance
  • if you connection speed is slow, loading a huge model with DRACO compression is already fast enough for me
  • if you’re loading something super-detailed using a progressive mesh - you get a lot of popping, unless you’re a technically savvy person - it just looks dirty and buggy.
  • all of the streaming meshes I looked at require additional space, in some cases a lot of it. Those that do tricks of sorting vertices typically sacrifice performance for that - which is not a good compromise in my estimation.
  • Internet speeds are improving, and currently internet is fast enough that geometry itself is rarely the bottleneck in terms of file size, it’s usually the textures, by a long shot.

I think streaming meshes is a cool concept, and I’m sure it has a lot of great applications, but computer games are generally not it, I believe.

1 Like

Yeah, using glTF+ Draco is already a good option for large models. I don’t believe it’s worth to invest a lot of time in developing a custom solution if this approach works okay for you.

3 Likes

Secondlife and OpenSim kind of do that.

Your mesh has 4 LOD’s… and the image textures are JPEG2000, which also has LOD’s. The objects start to display when the lowest LOD is loaded, and then it progressively uses the more detailed ones as they eventually load in the background.

Honestly. I absolutely hate it! It’s ugly, and it causes more lag and problems in the end, than it is designed to be a solution for.

Maybe you will develop a more elegant solution? I am creating a world similar to Secondlife. But what I like about the current model I am working on is it just loads everything fully at startup, no ambiguity. And I will just encourage more efficient design practices and choices. That’s just my opinion. Load it fully, and be done with it. And don’t use crazy sized mesh. :slight_smile:

1 Like

Another idea, as a possible solution to reducing loading times… Secondlife has an object called “Sculptie” which is a mesh created from a simple UV image. The mesh is created by using the RGB values in the texture pixels as x,y,z verticies. It does not create a very detailed or accurate mesh, but it is wonderful for creating things like tree trunks, rocks from a very small image. That might be a nice feature for Threejs someday.
sculptExample