Nagle said:
Silhouette protection sort of leads to impostor generation.

You may want to look into runtime impostor systems. They can be quite efficient if you have fill rate and VRAM left for textures but are running short on geometry throughput. Render depth and color and opacity to a texture, render the object as texture, update the 5% of impostors that have the worst current rendered-to-generated view distortion ratio each frame.

Also, @joej : the bunny is terrible for this kind of work, because it is nicely volumetrically conditioned. Leaves on a pot flower have no volume, but are quite important to the overall look of the mesh.

Frantic PonE said:
This looks pretty good as one of the absolute latest ones: https://github.com/mrakotosaon/diff-surface-triangulation​ Already uses some ML-ish stuff for optimization over a given domain, works with silhouette kinda.

Yes, but throwing TensorFlow at the problem is overkill, and probably slow. The basic problem here is the metric of goodness, not the optimization towards the metric. We're just talking about quartic optimization with some additional restrictions. That's a greedy algorithm - find best improvement currently available, repeat. There's not much of a local minima problem, so the heavy machinery of ML isn't needed.

JoeJ said:
So you want some kind of impostor geometry?

Kind of.

This is all for Second Life / Open Simulator. The servers are proprietary, the clients are open source, and the content is mostly made by users. Most successful content at highest LOD is quite good, but lower LODs tend to be poor.

The content uploading process has a built-in LOD creator. It's based on GLOD, and it's awful. A new LOD creator, based on “meshoptimizer”, is in test, but it's not all that much better, as the discussion at the top of this article shows. So I'm looking for solutions that work better.

It's common in this system to way overdo mesh reduction, taking something down to maybe 10-50 faces at the lowest LOD. This inherently looks awful, but it's distant, and thus tolerable. The goal here is to make it less awful. Hole free is the minimum. This isn't about reducing 50,000 vertices to 5,000 vertices. It's about reducing 500 to 50 while retaining something reasonable at distance.

We had a few of them developed in the lab as I was in grad school. David Cline got a few papers out of it.

Only lightly touched but critically important is that they are view dependent. Turn the object or move your position and they change. Building your replacement mesh and coming up with error values and weights will depend entirely on the view.

The good news is that for proxy objects you really mostly need the edge, and a scan of surface normals to find the edge is not particularly expensive relative to the other work being done.

jon1 said:
Also, @joej : the bunny is terrible for this kind of work, because it is nicely volumetrically conditioned. Leaves on a pot flower have no volume, but are quite important to the overall look of the mesh.

Yeah, that's what i meant with ‘input must be a good mesh’. To handle diffuse geometry i avoid technical problems by converting it to a volume first, but ofc. this turns a fine grained bush into some blobs of metaspheres. Can still represent foliage at distance, but for close ups it's a very bad representation.
However, i use this stuff primarily to generate a surfel hierarchy for realtime GI. I also want to use it for LOD of most static geometry like terrain and some architecture, but that's still ongoing work. For dynamic objects and human made stuff something like Nanite is better. And foliage requires it's own solutions. I think point clouds and splatting would be nice.

But i also use curvature directions in volume processing, actually to shape and upscale particle fluid simulations. So the idea to detect features using curvature also works with diffuse geometry, and i don't need ML and training data just to detect features.

Nagle said:
So I'm looking for solutions that work better.

Tried Simplygon? Seem very good, but idk about licensing.
The problem is even harder for you because you have no control over user content. But the same applies to Simplygon. They surely spent some work on supporting any kinds of input.

OK, so now we need to extract the silhouette perimeter. I found a reasonable algorithm for this: "Simple silhouettes for complex surfaces" from Harvard's CS department, back in 2003. They even use the bunny model! (Everybody likes the bunny.) They get a simple perimeter, about 20x fewer points than a previous approach. That's good, if we're going to pin points before mesh reduction.

No source code, though. And searching for that paper title doesn't turn up any later references with source code. Anybody seen code for that? This is 20 years old; someone must have done it by now.