Jump to content

Mesh LODs deformed on upload (Newb)


AcidBingo
 Share

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

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

Recommended Posts

Greetings SL people! Newbie user here with what I'm hoping is a Newbie problem!

I'm trying to make a mesh avatar for use in SL using Avastar 3.1 and Blender 3.2. Everything seems to work OK up until I reach the point of adding custom LOD's to the model via the uploader.  The high quality mesh works fine, however, all of the LODs are deformed in one way or another. There's not even a great deal of consistency in how the LOD is going to Cronenberg out when compared to the others. One thing I have noticed is each LOD mesh works if used as the high quality version and seems to animate properly in the uploader window, just not as an LOD of another mesh. Uploader does not spit out any discernible errors in either mode as far as I can tell.

High Quality Version in Uploader

Varying Degrees of Cronenberg

It should be noted that Cronenberg levels are vastly improved from what they used to be, and while *almost* imperceptible on a couple levels, it's still more than I can abide. I desire perfection... or at least close as I can get to it.

All meshes' transforms are zeroed. World units are Metric with 1 as my base unit. Mesh was built directly around the Avastar character with appearance settings set to 'male.' Applied rest pose prior to skinning (this seems to have improved results a bit). Each skin was weight copied from the Avastar character (head, upperbody, lowerbody) then weight painted to fit my character's mesh at each LOD level, and each LOD is weighted to the basic 21 bones. No zero weights, skin weights do not exceed 4 per vert. Using joint offsets in uploader window improves the pose slightly, but does not seem to have any effect on the LODs bugging out. Mesh is comprised of 3... "faces?" (sorry still acclimating to the SL lingo!) I.E. there's three materials on each LOD. Each mesh was originally three parts (head, upperbody, lowerbody) which were joined together, as exporting them separated yielded even more Cronenbergian results than what I've shown here 🤮 Uh, I tried hard-applying bounding box limits on each LOD, didn't seem to have any effect, positive or otherwise.

No doubles, uh, also noticed that the uploader window doesn't reflect my weighted normals, which is... fine, I guess. Uh, let's see here, calculated upload cost with custom LODs is twice or more what it would be if I let the PotatofierTM  (I.E. the auto LOD generator) do its thang. Hoping that'll resolve itself a little once the other issues are taken care of. If not then it's just another hurdle to jump in the future.

Again, I'm really hoping this is a newb-newb issue, like a setting or something and not something more dire. I've tried reading as much as a could about making meshes for SL, and have a game art background to draw from on the content creation side. Unfortunately, while I'm Godzilla when it comes to Blender, SP, and the like, I'm a complete Bambi on the SL/Avastar side. It'll be cute when I learn to walk right. That said, a lot of the info I've been able to locate, either from Avastar's knowledge base, videos on YouTube, this forum, etc., are often outdated or deprecated (often I can only tell what version the tutorial/post is for by what Blender version they're using), sometimes contradictory, vague on certain details, or a combo of all 3. I understand that from a dev's standpoint that's a lot of stuff to juggle and keep updated and boy howdy am I appreciative, but it's more than a little frustrating from a new user standpoint if I'm being honest about it. I'm not sure which sources to trust on what tasks, and I'm even less sure as to what Avastar takes care of under the hood/vs what it expects me to do on my own; some tutorials I've watched had settings that aren't exposed to the user anymore (I'm guessing these fall under the 'sanity checks' label), and therefore I'm not sure what I'm supposed to set or let Avastar take the wheel on for certain stuff. Blah.

Anyway, any and all help is... er, helpful?

Thanks in advance!

 

 

Link to comment
Share on other sites

15 hours ago, AcidBingo said:

Uh, let's see here, calculated upload cost with custom LODs is twice or more what it would be if I let the PotatofierTM  (I.E. the auto LOD generator) do its thang.

LI for custom mesh (rigged or not) is based on a weighted average of your LODs, with the one that SL thinks it'll use most often having the most impact. For an avatar-sized object, that's High and Medium. Also, for rigged mesh worn on an avatar, the swap distances are much farther than normal. The rule of thumb I use for rigged mesh is to make the Medium LOD about Low-quality, make Low Lowest and make Lowest either the same as Low or actually decimate to triangles because it'll never be displayed except to residents that have set their viewer to unrealistic options.

Also, the point of an LOD is to omit details that aren't necessary at a distance. You shouldn't still have shoelaces, antennae or individual fingers at Low. Even Medium doesn't need shoe tongues, and probably not antennae (although removing them completely will alter your bounding box and cause your LOD to shift, so you might want to keep a degenerate triangle there purely to preserve avatar height). The perfection you're going for isn't necessary, and it's what's costing you so much LI.

(Your physics is too high too. Just use a cube. All mesh objects need a physics frame, but an object's frame is ignored while attached to an avatar, so go as simple as you can to keep overall bandwidth use down.)

Quote

I'm even less sure as to what Avastar takes care of under the hood

Mainly rigging-related issues. Fitted Mesh bones (the ALL_CAPS ones), previewing the effects of SL's shape sliders, and animation exporting are the biggest ones. LODs and UV mapping are still done with Blender basics.

Edited by Quarrel Kukulcan
  • Like 1
Link to comment
Share on other sites

Thank you for your reply!

Hadn't gotten to the physics yet, wasn't sure exactly how they were handled on avatars if at all. How low would you suggest going on the physics object? I tried using a cube as you mentioned, how much lower should I go?- degenerate tri or (?) On a whim I threw in a box man mesh that fit the shape of the character, mostly to give the uploader something with a full hull to work with,  that alone dropped the physics cost down by half. If I can get away with less I'd like to, just not sure what the limits are there.

2 hours ago, Quarrel Kukulcan said:

The perfection you're going for isn't necessary, and it's what's costing you so much LI.

The perfection I'm concerned with at the moment is the LOD deformation to the rig. All other issues you addressed are things I can easily take care of myself without much hassle. As mentioned in the OP each LOD mesh's weighting works fine when used separately, it's together as an LOD set that they start messing up. This is the part I'm stuck on for the most part, until this problem is addressed everything else is secondary. There's a caveat somewhere that I'm missing, which is why I posted so much info about my workflow and setup. Just in case someone who knows what they're doing comes along, skims what I've tried so far and can pipe up with, "But you forgot XYZ genius!"

3 hours ago, Quarrel Kukulcan said:
Quote

I'm even less sure as to what Avastar takes care of under the hood

Mainly rigging-related issues. Fitted Mesh bones (the ALL_CAPS ones), previewing the effects of SL's shape sliders, and animation exporting are the biggest ones. LODs and UV mapping are still done with Blender basics.

This is a far less a granular answer than I was looking for, but thanks just the same. I'm aware that it's for 'rigging-related issues,' and despite the diatribe that is to follow, I think that conversation is probably best had in more detail elsewhere; perhaps in a dedicated thread.

"Short answer:" What I'm not aware of in regards to Avastar is what settings it's changing or what operations it's performing without my knowledge. As mentioned in the OP, there are settings being used in AvaLab's own tutorials from earlier revisions of v3 (from what I can tell) of the add-on which are simply not present in the updated version. This makes it difficult to follow along as that setting they just clicked in the video...isn't there anymore!- it's either been automated, moved under the hood into the exporter under "Sanity Checks," moved to a different workflow tab, or it's been removed entirely. Certain workflows, skin weighting for example, when using the addon seem to have a preference whether you're using native tools or the addon's modified version, BUT, it may also be that simply by entering into weight paint 'native' is taking you in a roundabout way to the same operator as the addon's menu. It's hard to tell. 🤷‍♂️ These are just a couple of examples thrown out to illustrate my point (I don't necessarily need a rundown of these particular operations, Ty!)

That being said I am by no means bashing on Avastar. It does what it's supposed to and does it well if not in a slightly confoozling manner sometimes. I bought it, I'm using it, I am for the most part content with it, but that's not to say I don't think the documentation from both AvaLabs, as well as (and maybe especially) it's end users out in the wild, can't be better. Simply adding "supported version" numbers to the knowledge base articles as they're written would go leaps and bounds towards helping with that. Again, as stated in OP, it's a massive undertaking for the devs, I understand that, (to whoever they are, "I acknowledge, validate, and appreciate you and your effort!") but the version number bit wouldn't be a massive time sink and would help tear down some barriers of understanding. I also acknowledge that for the most part, Avastar is trying it's damnedest to be idiot (read: Me) proof. It's what you do with tools you intend for widespread use. Blackbox any and all stuff the end user can tweak that they shouldn't be tweaking or could burn their fingies on, provide points of entry to the stuff you do want them tweaking, and corral the end user into a space where they're supposed to be without the risk of them getting out of their playpen and into the scary parts. What I kinda balk at is the not knowing the difference part I mentioned earlier. If I know that Avastar handles X&Y but not Z, then I know that Z is my problem and therefore I don't have to rail at the gods when Z doesn't work properly. Z was my responsibility and I therefore can't blame it on the magic box. Without that distinction being made, the end user is free to blame every problem on the magic box whether the box deserves the credit or not. Make sense?

*Pant Pant*

Now, getting back to SL in particular, this part was only supposed to be the start. Once I get to the point of not having my beautiforous LOD's mangled beyond all recognition on import, I can worry about wonderful problems like LI Cost, Rendering Cost and the like.

Link to comment
Share on other sites

18 hours ago, AcidBingo said:

Greetings SL people! Newbie user here with what I'm hoping is a Newbie problem!

I'm trying to make a mesh avatar for use in SL using Avastar 3.1 and Blender 3.2. Everything seems to work OK up until I reach the point of adding custom LOD's to the model via the uploader.  The high quality mesh works fine, however, all of the LODs are deformed in one way or another. There's not even a great deal of consistency in how the LOD is going to Cronenberg out when compared to the others. One thing I have noticed is each LOD mesh works if used as the high quality version and seems to animate properly in the uploader window, just not as an LOD of another mesh. Uploader does not spit out any discernible errors in either mode as far as I can tell.

High Quality Version in Uploader

Varying Degrees of Cronenberg

It should be noted that Cronenberg levels are vastly improved from what they used to be, and while *almost* imperceptible on a couple levels, it's still more than I can abide. I desire perfection... or at least close as I can get to it.

All meshes' transforms are zeroed. World units are Metric with 1 as my base unit. Mesh was built directly around the Avastar character with appearance settings set to 'male.' Applied rest pose prior to skinning (this seems to have improved results a bit). Each skin was weight copied from the Avastar character (head, upperbody, lowerbody) then weight painted to fit my character's mesh at each LOD level, and each LOD is weighted to the basic 21 bones. No zero weights, skin weights do not exceed 4 per vert. Using joint offsets in uploader window improves the pose slightly, but does not seem to have any effect on the LODs bugging out. Mesh is comprised of 3... "faces?" (sorry still acclimating to the SL lingo!) I.E. there's three materials on each LOD. Each mesh was originally three parts (head, upperbody, lowerbody) which were joined together, as exporting them separated yielded even more Cronenbergian results than what I've shown here 🤮 Uh, I tried hard-applying bounding box limits on each LOD, didn't seem to have any effect, positive or otherwise.

No doubles, uh, also noticed that the uploader window doesn't reflect my weighted normals, which is... fine, I guess. Uh, let's see here, calculated upload cost with custom LODs is twice or more what it would be if I let the PotatofierTM  (I.E. the auto LOD generator) do its thang. Hoping that'll resolve itself a little once the other issues are taken care of. If not then it's just another hurdle to jump in the future.

Again, I'm really hoping this is a newb-newb issue, like a setting or something and not something more dire. I've tried reading as much as a could about making meshes for SL, and have a game art background to draw from on the content creation side. Unfortunately, while I'm Godzilla when it comes to Blender, SP, and the like, I'm a complete Bambi on the SL/Avastar side. It'll be cute when I learn to walk right. That said, a lot of the info I've been able to locate, either from Avastar's knowledge base, videos on YouTube, this forum, etc., are often outdated or deprecated (often I can only tell what version the tutorial/post is for by what Blender version they're using), sometimes contradictory, vague on certain details, or a combo of all 3. I understand that from a dev's standpoint that's a lot of stuff to juggle and keep updated and boy howdy am I appreciative, but it's more than a little frustrating from a new user standpoint if I'm being honest about it. I'm not sure which sources to trust on what tasks, and I'm even less sure as to what Avastar takes care of under the hood/vs what it expects me to do on my own; some tutorials I've watched had settings that aren't exposed to the user anymore (I'm guessing these fall under the 'sanity checks' label), and therefore I'm not sure what I'm supposed to set or let Avastar take the wheel on for certain stuff. Blah.

Anyway, any and all help is... er, helpful?

Thanks in advance!

 

 

It's most likely a matter of missing joints influences. I'll try to explain

Your high lod has a certain number of vertices, which have been weighted to joints and are respecting all the rules you listed. So far so good.

However, when you make lods, you reduce the number of vertices, and therefore it may happen that certain joints influences get thrown out entirely, or its weights get pruned off to zero because there aren't enough vertices to hold that value onto and get cleaned off by some tool that make the 4 influences per vertex rule.

Try this and see if it solves your issue: compare the influences number between the high lod and the others. Should you find a missing influence, add it back manually, at zero weights, and do not perform clean ups after that. Each lod should always have the same list of joints in its skin definition, and if the geometry that used to hold its weights is gone,  just leave all those weights at zero. As long as it de forms right, the excess influences guarantee that the mesh still has a skinning that is a subset of the original high lod's skin

Link to comment
Share on other sites

Thanks for the reply!

So as per your suggestion I went through and checked the bone influences in both Blender and the uploader. Unfortunately, all the LOD's have the same influence count (21). That's from using the uploader and the Avastar Mesh Inspector. If necessary I can go check the weights individually, but then it'll be a LOT longer before I reply again :D

Link to comment
Share on other sites

12 minutes ago, AcidBingo said:

Thanks for the reply!

So as per your suggestion I went through and checked the bone influences in both Blender and the uploader. Unfortunately, all the LOD's have the same influence count (21). That's from using the uploader and the Avastar Mesh Inspector. If necessary I can go check the weights individually, but then it'll be a LOT longer before I reply again :D

Alright, so let's try this: take one of the lods and run the cleanup. See if any influence disappears. (in my software it is called "remove unused influences")

If you generated the lod from the original, some weights might have been shifted to the remaining neighboring vertices, breaking the 4 influences rules and making it get more than that, and therefore upon upload the distortions would be given by the uploaded pruning of the excess influences.

As a workflow suggestion, it's recommendable to clear the skinning from each lod, binding again and copy the weights from the original skinned model, always making sure that the influences number are the same

Sorry for not being able to help with more specific wording, tools and procedures, I'm not a Blender user

Edited by OptimoMaximo
Link to comment
Share on other sites

Okidokie.

Cleaned weight maps on all LOD's, no weight maps removed or changed. Same result. As for the workflow suggestion, I agree. In fact this isn't my first rodeo when it comes to trying to skin this guy. I have tried many permutations ending up with my current which involved exporting every mesh level as an obj, reimporting them all and then binding them again from scratch... it's been a long road. Thankfully the first time doing anything is the hardest, so... yeah.

No worries on specific wording, I'm fluent in Maya, Max, and Blender, so whatever lingo you decide to use works for me!- and anything that doesn't, I have the google.

Link to comment
Share on other sites

giphy.gif

Sigh, still trying at this. Have re-skinned and re-weighted so many times in so many different ways, I could do this in my sleep. I've literally lost count of how many different angles I've tried to solve this, with different setups, different settings, none of the LOD's work together in spite of being fine as HQ models, in spite of having weights literally copied from one another onto the meshes in Blender via Avastar. Each shares same weight count. None have any issues that either Avastar or the uploader are willing to pinpoint. Can't find one tutorial on doing custom LOD's beyond how to make the meshes themselves. Not skinning, not importing and/or troubleshooting.

Methinks I'm starting to get a wee bit discouraged. Just a tad. A wee bit, so to speak.

On the plus side, tore into the lower LOD's and managed to get costs down a bit. Huzzah 😐

Link to comment
Share on other sites

BWAHAHAHAHA!!!

giphy.gif

So on a whim I decided to check something, and that something has born fruit. SUCH FRUITS!

All this time I've been trying my upload on the FS viewer. Switched to SL native viewer, and the LODs work FINE, swimmingly in fact... the import window on the other hand, not so much apparently. The SL native viewer crashes every time I try to calculate costs, Lol.

Edit:

SL viewer only seems to crash when I add a bounding box as my collider first. Without that it calculates the cost "fine?"

Edited by AcidBingo
More Infos
  • Sad 1
Link to comment
Share on other sites

17 hours ago, AcidBingo said:

BWAHAHAHAHA!!!

giphy.gif

So on a whim I decided to check something, and that something has born fruit. SUCH FRUITS!

All this time I've been trying my upload on the FS viewer. Switched to SL native viewer, and the LODs work FINE, swimmingly in fact... the import window on the other hand, not so much apparently. The SL native viewer crashes every time I try to calculate costs, Lol.

Edit:

SL viewer only seems to crash when I add a bounding box as my collider first. Without that it calculates the cost "fine?"

That's good to hear!

However, did you try to add the collision shape AFTER you've set the custom LoDs??

If you did and still crashes, maybe paging @Beq Janus might give us some insights on the FS's inner workings...

Link to comment
Share on other sites

1 minute ago, OptimoMaximo said:

However, did you try to add the collision shape AFTER you've set the custom LoDs??

Yeah, but to be clear this crashing behavior was only on the LL viewer, so I don't think it's an FS problem. FS was borking my LOD meshes and I d/l'd the LL viewer as a final Hail Mary to see if it changed anything (🎉). Doesn't explain to me why the results between LL's importer and FS were so drastically different though, so it might be a good idea to bring them in anyway? From what I've gleaned from the forums there's a difference in the FS viewer and thus the importer when compared to the LL version; at least as far as I've been able to understand things.

As for the LL viewer the LOD's imported along with the mesh right at the start of the operation (no collider included in my files since i just wanted to use the bounding box anyway). The results I got with this crashing behavior were inconsistent, too. When I first started loading the model into the uploader there it crashed to desktop pretty much every time. Then there were one or two times where this behavior didn't occur and everything behaved itself. Made some changes and tested the upload again, added cube (Bounding Box); crash city!

As an aside, thanks for your help in this, and for following up. It's much appreciated!

Link to comment
Share on other sites

32 minutes ago, AcidBingo said:

Yeah, but to be clear this crashing behavior was only on the LL viewer, so I don't think it's an FS problem. FS was borking my LOD meshes and I d/l'd the LL viewer as a final Hail Mary to see if it changed anything (🎉). Doesn't explain to me why the results between LL's importer and FS were so drastically different though, so it might be a good idea to bring them in anyway? From what I've gleaned from the forums there's a difference in the FS viewer and thus the importer when compared to the LL version; at least as far as I've been able to understand things.

As for the LL viewer the LOD's imported along with the mesh right at the start of the operation (no collider included in my files since i just wanted to use the bounding box anyway). The results I got with this crashing behavior were inconsistent, too. When I first started loading the model into the uploader there it crashed to desktop pretty much every time. Then there were one or two times where this behavior didn't occur and everything behaved itself. Made some changes and tested the upload again, added cube (Bounding Box); crash city!

As an aside, thanks for your help in this, and for following up. It's much appreciated!

oh certainly Beq will have some insights to share in regards of the mesh uploader in general, so i guess it is good to try and pull her in :) 

I'm sorry that my suggestions did not work for you though. That looked a lot like the problems i was having when i decided to create an automated lod generator for skinned meshes. The problematic part was the exact match of influences listed in the skinCluster, which was the heavy lifting task of making it work without LoDs being distorted (if not exploded sometimes). That solved my problem at the time, was just hoping you were stumbling upon that same behavior. It's good to see that someone is trying to do things the proper way :) 

Link to comment
Share on other sites

Thanks, and no worries. :D

I was pretty sure you were going down the right road as far as skin weights getting culled went (and it's possible that you were still right and that was happening under the hood in the importer)- which made the problem more frustrating for me because that's the one part of the process (at least in Blender) that I don't have much control over (importers are another thing entirely). There's a part of me that really...REALLY didn't want to use Avastar, not because it's paid or I don't like third party stuff, etc., but because I'm a control freak and like to know what's going on with my stuff at all times. Lacking that control in a situation like that makes me act a bit... off. Since Blender was my main point of entry to the problem, I basically was skinning and reskinning that damn mesh over and over again with no forward movement. Finally I just changed the one element I had the least control over, the importer (and therefore the viewer) itself.

I'm really hoping Beq can shed some light on this. My most optimistic thought about it is that the FS importer may have more stringent rules as to what can be imported as LODsand how they work together, but I am the dumb when it comes to all that kinda stuff so I'm probably way off base in that assumption.

Link to comment
Share on other sites

Hi all

Very quick reply as it is stupidly late/early and anything I write will probably be turned to gibberish by my fingers.

1) Physics crashing on SL (and FS). I have recently fixed this bug. It turns out that the code in the uploader has always assumed that the physics shape has weights on it (even though that makes no sense at all in SL), it does not check for this and as a result if you pick the cube shape or the "bounding box" option in the LL viewer, then the viewer will explode spectacularly when you calculate the costs. This is fixed in the latest FS preview (join the FS preview group to get access) and should be released soon-ish. 

2) rigging of LODS, I'm not entirely sure what we are aiming for here, first thing I will note, from the images above we can see that the joint offsets were not being displayed in the preview for some of the LOD images. That could well just be a mistake while documenting the issue however. As for rigging of LODs, I can't recall right now the exact nature, I'll review it when the christmas visitation of relatives cease and normality returns. IIRC (and I may well not do so) we have just one set of weights that we abide by, and these are loaded with the high lod; all lower lod models are assigned weights using an algorithm that finds the nearest vertex in the lower lod models. I am casting doubt on my own recollections here though as I cannot with any certainty say if it does this for custom LODs that have weights with them or only for generated LODs. Given the ridiculous bug-ridden state of LOD switching with rigged mesh most people only ever use auto lods because the other LODs are highly unlikely to be seen. I applaud anyone trying to do the job properly, but it would not surprise me to find that things are not quite as you'd like/expect but that nobody has noticed!

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 486 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...