Jump to content

Mesh level of detail at Uber


animats
 Share

You are about to reply to a thread that has been inactive for 2151 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

On 5/4/2018 at 7:29 AM, ChinRey said:

But there is actually no conflict between good looks and good technical quality. A building like the one on the poster in Chic's picture could easily have been done with exactly the same look and exctly the same land impact and still have LoD good enough it still looked great at a moderate distance. All it would have taken, was some very basic mesh making skills and about an hour of work.

Exactly. AND it could have been WAY better even without custom LODs. Simply letting the uploader make some sort of LODs for 2 and 3 would have been a big improvement and only taken a minute. 

 

And unfortunately I want to take BACK what I said about the building in question being useful.  The SENTIMENT was certainly a good one but I went back over to look at the OP build and found that the 30 impact build was COMPLETELY LINKED. So that is 30 for all the deco as well.   The items inside fall apart from an EXTREMELY short distance and while there is a tiny bit of physics, you can  and do walk through walls in many places. I have no idea if you can sit on the bar stools. If the physics were better a 2 meter avatar (that's me) would not be able to walk through the door as the building is still scaled down too much. 

 

image.png.1a16918b90c53d61a55950d34e0a4bd4.png

 

The building itself has been retrofitted with the back and sides seemingly taken from another build and not even retextured.  The list goes on and on and I am pretty depressed right now. 

bar.jpg.0fe48230399a56a37e93ebcae1eb38ea.jpg

ONE MORE trip over and I could see the "prim physics" walls rez as I came in. So that answers that. Visiting the main store which is mostly avatar accessories (lots) I found a selection of backdrops. Oddly (or maybe no so oddly) I couldn't see a lot of congruence among the builds.  Most of my stuff (and I am a very eclectic builder) looks like mine. Same baking styles, many of the same base textures.  There are no demos of any of the buildings that I could find. 

 

So now I am going off to build something and let this go as it was not a good way to start my day (sigh). 

Go forth and BUILD SOMETHING ORIGINAL WITH GOOD LODS AND PRETTY ENOUGH TEXTURES!!!

That was a plea, not a demand LOL.

 

Edited by Chic Aeon
adding info
  • Thanks 1
Link to comment
Share on other sites

8 hours ago, ChinRey said:

I can't imagine there is anything that can be easily retrofitted into SL.

The viewer code is a mess inside. I've been in there.The sim side code is probably similar. Despite that, several projects have managed to make major changes.

Level of detail code in the mesh uploader is a few hundred lines of code in one place. It's not real time or event driven. That could be replaced. Probably easier to replace than fix; it has very few comments.

At the other extreme is the "fix" SL really needs - multithreading in the simulator. To make the sim side go fast, physics and motion control, which are real time, need to run in different threads than all the other object management the sim does. High Fidelity breaks up its sim process into six microservers. Havok supports multithreaded physics, but it's not clear that SL uses that feature. That's a huge job, but a huge win.

Fortunately, SL doesn't really have much physics. Avatars are capsules. Vehicles are single rigid bodies. Avatar interaction is very limited. Attachments are non-physical; swords are just visual bling. There's no physical combat system. The only big problem is that each sim has a high count of stationary objects.

I'm not sure what the state of Havok physics is. Since Microsoft bought them in 2015, all the public documentation disappeared. Is SL stuck with an old pre-Microsoft version?

Link to comment
Share on other sites

32 minutes ago, animats said:

I'm not sure what the state of Havok physics is. Since Microsoft bought them in 2015, all the public documentation disappeared.

Oh no. We managed to locate two manuals, one for programmers and one for developers back in this thread:

https://community.secondlife.com/forums/topic/390775-prim-bonuses-and-lods/?page=5&tab=comments#comment-1189909

Both are gone now and I was of course too stupid to download them while I could. Did anybody else?

Link to comment
Share on other sites

5 minutes ago, ChinRey said:

Oh no. We managed to locate two manuals, one for programmers and one for developers back in this thread:

https://community.secondlife.com/forums/topic/390775-prim-bonuses-and-lods/?page=5&tab=comments#comment-1189909

Both are gone now and I was of course too stupid to download them while I could. Did anybody else?

It's in archive.org:

https://web.archive.org/web/20160822121510/http://anarchy.cn/manual/12/HavokSdk_ProgrammersManual/bk03.html

That's the manual for 2012. You probably have to sign up as a Microsoft game developer to get later documentation.

  • Thanks 2
Link to comment
Share on other sites

1 hour ago, animats said:

Wow, that's absolutely fantastic! It's copyright 2014 actually, not 2012, so it's even better than you thought. Of course, all the illustrations are missing from the wayback machine copy but it's still a marvelous resource.

Here is the artist's documentation Arton found. That one is probably more useful for more SL'ers:

https://web.archive.org/web/20151230040706if_/https://community.secondlife.com/secondlife/attachments/secondlife/English_KB%40tkb/193/1/ArtistDoc.pdf

 

Edited by ChinRey
  • Thanks 1
Link to comment
Share on other sites

I've been trying out mesh reduction programs. There are a lot of them.

  • Seam Aware Decimater - new, good algorithm. Maintains the edges of UV regions as it reduces the mesh, so the same texture will work on the reduced mesh. In practice, it seems brittle. Many models make it crash. It seems to need perfect triangulated geometry with a valid texture mapping. Does a good job when it succeeds. Open source. Academic grade code, not yet ready for the real world.
  • Fast quadric mesh simplification  - Fast open-source implementation of a well known, reasonably good algorithm. Does a terrible job when a lot of triangles meet at one point. Does not preserve the texture map exactly, as the seam-aware one does. Open source.
  • MeshLab - open source program. GPL. Has a good reputation. Very good at mesh reduction for non-textured objects down to very low triangle counts. Not so good if you ask it to preserve UV coordinates for textures. Crashes a lot in mesh cleanup operations.

Some commercial products:

  • Simplygon, which is part of Unreal Engine. Haven't tried it, but it powers most of the AAA game titles.
  • Umbra, which is apparently used by Sansar. Full automated level of detail solution, including runtime components. Partly a service; you can send models to Umbra's server for optimization.

Any better ones out there?

 

Link to comment
Share on other sites

2 hours ago, animats said:

I've been trying out mesh reduction programs. There are a lot of them.

Indeed there are. There is one factor that may complicate the picture though.

There is no code in SL made from scratch to handle mesh. When mesh was added to SL, the LL developer did it as simple as possible so mesh is processed by one of eight modified versions of the prim handling code (which of them, depends on the number of faces) with some bits from the sculpt code (which is also a crude hack of the prim code) added for good measure. They even kept the prim "torturing" properties although those data bits don't do anything except waste bandwidth and processing time.

In SL, prims and sculpts are defined as curves called "NURBS". (I think they are actually Paths, not NURBS, but they borrowed it all from Maya which may be a bit confused about the terminology here), not mesh. They are only converted to mesh towards the end of the process to be digestable by OpenGL. Sculpts are actually first converted from mesh to curves at the start of the processing and then back again towards the end.

I don't know anything for sure but it's quite possible this means effective mesh based simplification methods can't be easily implemented to this copy-and-paste-coding nightmare and that may explain why we're stuck with GLODs crude butchery.

Edited by ChinRey
Link to comment
Share on other sites

2 hours ago, ChinRey said:

There is no code in SL made from scratch to handle mesh. ...

I don't know anything for sure but it's quite possible this means effective mesh based simplification methods can't be easily implemented to this copy-and-paste-coding nightmare and that may explain why we're stuck with GLODs crude butchery.

What a mess. Still, you can upload a different mesh for each level of detail. So something which creates a new mesh for each LOD is possible. Maybe this should be some Python script for Blender.

A real win would be automatic generation of simple impostors. That's possible, but it has some limitations. You'd need to upload the texture maps and meshes at the same time, so the previewer can texture the preview. Then, internal to the viewer, you'd render the preview with texture (it's not textured now) and take shots of it from the angles needed for an impostor. The viewer already knows how to do most of that. Then create a very simple impostor (two planes) and put the rendered texture on it. Instant good low level of detail.

But you can't change the object's color or texture later and have it look right, because that's been baked into the imposter image. So this won't work for objects that come with color or texture changing tools.

I've tried generating an imposter image in-world by putting an object in front of a full-bright green screen. That's a uniform color, so you can remove it easily. Then you have to get it out of world, into Blender, paste it on the impostor surfaces, and re-upload the mesh object. That can work, but needs automation.

Link to comment
Share on other sites

20 hours ago, ChinRey said:

Indeed there are. There is one factor that may complicate the picture though.

There is no code in SL made from scratch to handle mesh. When mesh was added to SL, the LL developer did it as simple as possible so mesh is processed by one of eight modified versions of the prim handling code (which of them, depends on the number of faces) with some bits from the sculpt code (which is also a crude hack of the prim code) added for good measure. They even kept the prim "torturing" properties although those data bits don't do anything except waste bandwidth and processing time.

 

When mesh was introduced, well over half - probably closer to 75% - of Second Life residents were not only using third-party viewers, but third party viewers built on the old Version 1 software base. It was an open guess as to whether they would ever support mesh that would look correct - using the prim handling code was a way of keeping those viewers from crashing. It was months after mesh introduction before Phoenix (well over half the market on its own) was able to display it.

Of course, perhaps you would have volunteered to tell all the Phoenix users to move to a Version 2 based viewer. Ohhh, that would have been fun to watch...

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2151 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...