Ruth2.0_RC4.4Export.dae first test

[seriesumei]

[Starting a new Issue to discuss specifics on the RC4.4 export file]

I've imported Ruthie RC4.4 to both OSGrid and SL Aditi and have a few notes we can kick around:

1. After setting the description field in the links setting skin textured worked fine. And setting the link names to matching parts from the old body the alpha worked. This is expected with the right naming. The parts map in the HUD needs to be updated, along with the doll model.

2. If we plan to keep the cube inside the body how about we make that the root? As long as it is centered in X and Y directions I'd be happy. That would save me a manual renaming step in the HUD assembly later.

3. I like having the numbers in the link names, if those are reliable it would be helpful to have all of the 'upper' texture parts together and the 'lower' texture parts together. Then we can just save the number in the link name and script setting the description field of all of the links properly for texturing.

4. I used the same shape I had been using for RC3, the neck is significantly smaller and doesn't match the head mesh.

5. I used FS 6.0.2 to upload, OpenSim kept link names with numbers in them, SL named everything Object. SL also picked a part to be the root link different from OpenSim, which I believe had one of the waist links as root. I'll try FS 5.1.7 tomorrow and see if it's a problem in the new mesh uploader.

6. She is purdy! I didn't examine every triangle but I can't wait to get her fixed up!

[AdaRadius]

I don't understand 1, 2, 3 above, but maybe I don't need to - do you need me to change anything in Blender? Yes, I had intended the cube as the root. I thought it would be easier to move the doll around.

4) I'll try some things to see if I can fix that. It's possible that the armature got toinked when I was testing the bits with the pose libraries or the sliders; it's easy to do. That means I need to bring in a fresh armature, reskin everything and save retesting for inworld. I'll do it in a fresh file, in case I break new things.

5) I didn't realize a new FS was out - I'll upgrade so we're using the same version. With the version I was using, the link names were not surviving the import, so 6.02 sounds better.

6) YAY

May we keep the HUD doll in T-pose? I know it takes up more room but it's easier to get her dressed if we can see the bits on the sides of the torso.

[seriesumei]

[I edited my bullet points to numbers]

2. Neither import had the cube as the root link. No big deal as long as it is in the right place. There will be manual fix-up work on import no matter what.

3. I didn't say this well. It would be simple to write a script to set the description field on each link to 'upper' or 'lower' for mapping the skin textures if each group is together in the numeric order in the link names. i.e., all upper links are < 26 (or whatever it really is). I am just looking for ways to simplify the setup after import, this isn't critical.

4. The mesh import has been significantly re-written but there have been some bugs in it (it was very broken in the FS 6 beta release). Austin has seen some other issues too but I can't recall what exactly. http://beqsother.blogspot.com/2018/12/easing-pain-of-importing-mesh.html describes the FS 6 changes.

5. I was looking at that and I think we can make the T pose work. I'll be some changes to the HUD layout, which I have been pondering anyway. I am a little worried about having it large enough to actually click on some of those smaller areas on the doll. On my little laptop it gets really tricky to hit the right spot, I still need to think on that one.

[aiaustin]

I definitely think it will be good to have the cube as the root for the in world mesh. Isn't that how RC#1, 2 and 3 already are? Shin's versions anyway. I thought we uploaded the body mesh and the root cube separately and the linked them in world as part of the instructions for assembly? It also makes me wonder if we can address the "Not X-Forward" orientation warnings we get when the .dae files are uploaded, and the brief appearance of the mesh parts mounted at right angles to the avatar on attachment.

[aiaustin]

The issues I had with Firestorm uploads are documented along with the issue discussion https://github.com/ingen-lab/Ruth/issues/42

[aiaustin]

Image of the problem with the mesh as it is attached and before its fully loaded... sideways on to body until each part of mesh loads.

[AdaRadius]

2. I created the export dae with the cube as the last and active link. If it doesn't import correctly, and it sounds like it didn't, then we have to unlink it and reattach to make it the root. I liked exporting them together better, because I weighted the cube to make sure it stayed inside the chest without poking out in some animations and included it in my final checks. Though changing its texture inworld to make it transparent before final distribution would be a good idea, too.

[AdaRadius]

3. Sounds good! So when we reduce the number of cuts - because some of them are too small to click on - keep the lower body numbering starting at 26, even if the upper body doesn't go to 25?

[AdaRadius]

5. I think I should consolidate some of the teeny bits. Groin and under the breasts. Fashionistas will not be as happy, maybe. I have to figure out what's wrong with the neck, anyway.

[aiaustin]

note my image was for Shin’s RC#3

[AdaRadius]

Ai - my apologies if you've already done all this: Are you using the most recent Avastar plugin to export from Blender? Each 3D modeling program and each gaming platform can have a different direction for x,y,z axes, and Blender's is not the same as Maya and 3dsMax. I can't remember what ZBrush does; I've never used it. Bringing a model into Blender, as Shin did from ZBrush, getting it positioned so that hitting 1 on the numpad has it facing out to the viewer, then applying location and rotations to the armature and the model, are critical steps. Then the Avastar plugin does one of its most valuable things, and that is to move the components to the correct orientation to export for SL or OS. I can never remember which way the 90 degree rot goes from Blender to OS, so I rely on Gaia to keep track of SL & OS for us with the Avastar script.

I think that when you see the sideways thing before an attachment properly loads, it's a lag issue. Unless it's still sideways when it's done loading - then it's an export error from the 3D software. Vbinnia had some blogs on this, I think? Someone did.

I'm downloading the most recent Firestorm as I type. Shin and I learned to do frequent version checks on the software and plugins when we were working together, so we wouldn't be out of sync, and I'm embarrassed that I DID IT AGAIN and didn't keep up with upgrades.

[aiaustin]

Ada... the RC#3 I was using for that image was the inworld OpenSim version uploaded by Shin Ingen and that is part of his release package. Not a mesh I uploaded.

But it does go to the correct position as each part loads... its just cross ways while loading. I had assumed that MIGHT relate to the "Mesh is not X-Forward" warning. But perhaps not?

The messages I got about that were on a trial of uploading the meshes that Shin exported.

Actually I don't have Avastar myself and have never done the export of Collada from Blender for Ruth/Roth.

[AdaRadius]

Ah, yes, that is related to the "Mesh is not X-forward" warning, I think, though I don't understand what the viewer and sim are doing with the rotations very well and haven't found a lot of documentation. I've made avatars for other platforms - rotation always a issue. It's supposed to happen so fast you don't see it.

I'm so alternative with regard to visual-spatial processing that I generally have no idea which way X is pointing, and won't ever remember. It speeds things up for me doing the actual work. Until I have to rotate something to export to another ap, ack, and then I have to find the formula and change it in a numbers field, probably more than once, to get it right. Avastar is a godsend for that, but not essential.

[AdaRadius]

Serie,

5. I've consolidated some of the teeny bits and am working out how to rearrange the colors so people can find the spots to click on more easily. Do you want me to re-number the list, or wait until we see if it works or not? They're still in numerical order. I think there is a way to setup Dropbox so we could both edit the same file, though that's probably not a great idea - you'd have too much lag from your laptop.

[AdaRadius]

There is good news and bad news. :( I figured out what was wrong with the neck, it was indeed a corrupted armature, which sent the wrong information with the mesh on export. After some fiddling I forced the bad armature back to the default shape, which it was never supposed to leave, and then I could see the same problem in Blender you're seeing inworld - Ruthie neck doesn't match the default meshHead neck. I don't know when that happened. It happened several times when I was actually working on the weights, but I thought I had avoided doing the stuff that causes this since then.

So I swapped out the armature and the neck looks fine now. That's the good news. The bad news is that the weights , nearly all of them, got shifted when I reskinned the cut pieces to the new armature. Everything is just a little distorted when I move the bones. Not nice at all.

The next thing I'll try, probably (I need to brood about it):

1. rejoin all the bits and redo the color UV exports to update the color map textures - I have to do that anyway.
2. remove doubles created by the cuts
3. unskin the body and feet from the armature - I might do that before the rejoin.
4. append the last body we liked before I started cutting
5. reskin, copying weights from the appended body.
6. redo the cuts, renaming the pieces from the parts list. Lotta copy-paste. If we want changes to the parts list, this is the time to do that. I've already merged 27 into 25 and 28, 29 into 28 and 30 into 31, more or less. Fixing the bra parts was easier - just a color reassignment.
7. redo the Data Transfer targets, fix snapping, yada yada.
8. Re-export.

Any ideas from the other designers who know how to do this stuff, would be entirely welcome.

Anyway, it's going to be a couple of days to get all that done, and Roth is gonna have to wait.

[seriesumei]

/me tries to catch up - busy day for everyone it seems!

Ada

2. Re-linking in-world is fine, I wasn't sure what you had selected as the root link in Blender.

3. We do not need to stick to a particular number, just knowing what is the first one for lower is enough. This is also a one-time import thing, but it can be scripted so it isn't quite so tedious to keep re-doing while testing.

4. My concern with the small sizes is just a usability problem. For example, I have a Signature body in SL where the alpha click points can be hard to find on my 13" laptop. I have not come up with a way to solve that, short of maybe making some "blow-up" panels to get a closer view if the tiny areas. Hmmm... typing that out just now actually makes it seem doable, I'll keep thinking about that.

About the neck and fixes, I wish I could help! Thank you so much for all of the work you are doing here, I can't wait to put her on and go out!

[AdaRadius]

3. 23 to start the parts number sequence for lower body, 53 to start the parts number list for feet. (two prime numbers I'll be able to remember, lol)

4. I agree, they have to be clickable targets. Some of the ones in "plan a" are so small I was having problems coloring them in to make a 1024x1024 colormap texture - no way is anyone going to enjoy finding them on any machine. I made some changes; I think it's better now. And now that we've settled on starting numbers for Upper, Lower and Feet, it shouldn't be a problem for either of us to make more changes if we think we need to.

[seriesumei]

That sounds great Ada, on both counts! I still want to explore a 'magnify' button on the HUD for those of us who are hard-of-clicking. :)

Thank you again for all of your hard work, I am soooo glad I found this project!

[AdaRadius]

I still can't get the import to fit at the neck. No idea what's going wrong, except that it's somewhere either in the cuts, or assembling them to export - Avastar is rebinding all the pieces as I go. I think. Right now it looks fine in Blender. Not fine inworld. Any ideas? I'll keep trying things.

[Outworldz]

Are all the neck weights 100% neck? I always check them by looking in the N window one vertex as a time. You can delete them there with one click.

[AdaRadius]

Yes.

[AdaRadius]

All the weights at the neckline are 100% to mNeck, the rest of the neck is weighted to NECK, graduated to CLAVICLE, CHEST. What we've been doing since RC#2. I checked against a new Avastar model before exporting, and the neck matches. Inworld, doesn't match. Something got corrupted - it was broken in Blender, so I went back the the version before that happened and re-cut. It's fine in Blender now, or seems to be. I'm rechecking everything and will re-upload. Gaia is at Discord now, and not answering tickets to any versions of Avastar for Blender 2.79, but she may take a quick question if I can catch her there.

[AdaRadius]

Thank you Fred! I'm still stumped, but less grumpy about it today. I have a list of a range of things that could have caused it: One thing I changed in this RC is that I've been using pose libraries from SL, Medhue and other sources, very very helpful except that they may be doing something to the armature that's doing something irrevocable to the mesh? Another is newer versions of Avastar and Firestorm; I can't remember if Blender had any upgrades from 2.79 since late last year. I avoided the Avastar appearance sliders this last experiment, didn't help.

Anyway. We still have RC3, we still have the last mesh body that worked. This is a teaching and learning project. If I go through the process to nail down where the bad data got in, that will at least teach us something. And then we start over when Blender 2.8 comes out of beta. mwahahaha.

Here is my current version of Export Checklist, which also doubles as "things I've ruled out". I'll upload it into our Git library when it's cleaner. Any suggestions or additions are deeply appreciated:

Export checklist for rigged clothing and bodies: Before cuts: 1 Clean up weights: Select weights for a vertex group, go to edit mode, adj to what it should be, invert selection, remove. OR Vert by vert (n panel) OR Paint unwanted verts with subtract=1.000, Weight tools: Clean. Deselect, check selection.

2 Check that all items in linkset and the armature are at location 0,0,0, rot = 0,0,0, scale = 0, in case something got moved accidentally. We want to assume that this was also checked on import or append, and applied at that time, so that during this check, changing the value to 0 is the right thing to do rather than Object>Apply.

4 UV editor: Seams from Islands. Any seams that aren't what they should be means that there are doubles in the UV map that need to be welded.

After cuts: 5 Check each object for doubles - easy to introduce while making alpha cuts. 6 Avastar's excellent tools to check weight limits, asymmetries, etc. But recheck snapping - Avatstar's Tool is useful, but sometimes the wrong edge gets selected for snapping, especially at the neck. 7 Delete unused objects images, materials, pose libraries. Use a temporary mesh, like a plane to open and delete (shift, hit x button) materials). Poses: must unclick F, then shift> x button. Close file, re-open, save again. This is to reduce file size, and because in other tasks, such as baking normals, the excess data does interfere unpredictably, so I'm assuming it can in rigging and weighting as well. Forums on this subject sound like tarot card readings, and I'm no better. We don't know everything about what Blender is doing with data, and neither does Blender. 8 If the order of material faces matters, number the materials list, same for objects list. 9 Check parenting and armature assignments 10 Check Data transfer modifier (normals matching) assignments, especially at neck 11 Check Auto smooth for all objects = 90 unless that makes bad looking normals, then try something else. 12 Clear geometry data

[aiaustin]

Sorry... I must have closed that by accident, Reopening.

Sorry this is causing you so much extra work Ada. Thanks for persisting.

[AdaRadius]

Thank you Ai!

I found it, and none of us are gonna like it.

I kept tracing back, importing to OS, trying them on, until I got back to OSRuth2_CurrentRelease_Source_RC3.blend. I exported from that file, ignoring error messages from Avastar, imported to OS, and the thing had entirely wrong rotations - perpendicular to where it should be.

So I went back to the file, updated the armature, fixed the other error message (vertex weight limits in the hands, not relevant) exported successfully without error messages, and imported to OS.

Rotation errors fixed, but the neck doesn't fit. Same problem as my files, many iterations later.

Ai - I reactivated my osgrid account, and am logging in with that, so we can communicate inworld with maybe fewer hassles. I sent out friend requests, joined the group. Will you give Ada Radius @ osgrid rez rights at the RuthAndRoth world?

Another question: for RC#3 - which file was used to export from to make the inworld body?

[AdaRadius]

I am able, now, to duplicate the problem in Blender, by swapping out the armature, after I applied the default shape to the mesh - what upgrading the armature did anyway, except it was only visible inworld.

So this is fixable, by changing the size of the mesh, until, probably, when Blender 2.8 comes out of beta and Gaia releases the Avastar that will go with. She is no longer even supporting the current Avastar, too busy working on the upgrade.

I thought Ruth RC#4 would be a quick fix, then on to Roth. Wrong, lol.

Question: should we bother for now or wait until Blender 2.8 comes out of beta and Gaia catches up? The UV fixes are done for RC#4, the new alpha cuts designed, and that work should stay relevant.

[seriesumei]

Ada, Thank you again for sticking with this! I know what it is like to chase that kind of problem down and how good it can feel to figure it out, even if the result is more work in the end.

About waiting for Blender 2.8 and friends: How much of the work that you want to do next is possibly not going to be useful in 2.8? Personally I have a bit of work to do to adjust to some of the changes so far, I would be happy to have what is done so far and call it RC4.

I lean toward the maxim "release early, release often" in community projects like this so the changes are more frequent but more incremental than big-bang changes that come one or twice a year (or whatever time frame). But I also know that right now this is a lot of work on your shoulders and do not want to put unfair pressure or expectations on you.

[aiaustin]

These things are sent to try us ;-)

Ada, it really is down to you to decide if wait or go now with a RC#4 is sensible. This is volunteer effort and pressure is not something others should impose on colleagues here. We go at a sensible pace everyone can manage.

I agree with Serie though, that its good to test when we have something that works properly and does not introduce problems that means most people would simply stick with RC#3. Sith the scripting and HUD changes that Serie is introducing too... we maybe anyway have to accept that RC#4 may not be the final RC ahead of the first proper release. We do anyway need to have a few folks go through the creation from the Github resources process using the documentation to validate and refine that.

[aiaustin]

Ada, your OSGrid avatar now has creator role for RuthAndRoth group.

[AdaRadius]

Thank you Ai and Serie! I agree with "release early, release often", but we'll need more people back testing or working on stuff like fingernails. MeWe seems to have more people leaving than joining. How are we doing with people moving here from Shin's GitHub?

Before I can figure out the best thing to do next I need to understand some things better:

1. I still don't know which file was used for final import to OS - neither the DevKit_RC3 nor the Source_RC3 (under the Mesh folder) have cuts.
2. I don't understand the alpha HUD script that well. Is the same model on the avatar as is in the HUD?

I do know that I need to reduce the cuts more on RC4 - even if I get a draft working, it's too heavy, takes too long to load on import.

Meanwhile I'll work on preliminary stuff with Roth - he pretty much needs everything.

[seriesumei]

1. I don't know either, to be honest I was using Sean's RC3 Ruth mesh, partly because I found it first and partly because the same thing you are asking, I didn't know what was the correct file to import. We'll need to find out from Sean where the Blender file in his repo came from, plus he may have modified it too.

2. The principles in the original HUD script and mine are the same, mostly my improvement was to not need a specific link order of the body parts for the doll. Again, Sean has a different mesh for the doll, I'm not sure I ever used that, I just shrunk down the body. There are probably good reasons to use a different mesh for that I am unaware of though. The trick to the alpha HUD script is that it needs to have each part named to match to the body.

[ocsean]

Serie, Ada, et al,

1. The initial Blender file that I started with for RuthTooRC3 is from Shin's original repo here: https://github.com/ingen-lab/Ruth/tree/master/Mesh/Avatar%20Ruth/Current%20Release/ I used this file: OSRuth2_CurrentRelease_Source_RC3.blend This Blender file should be identical to the one in my repo here: https://github.com/ocsean/RuthToo/tree/master/BlenderSource/ Named: RuthToo_RC3_Source.blend The only modifications I made to RuthToo mesh were doing my own AlphaCuts, HUD and LSL scripts. These meshes are in my repo as different Blender files named appropriately. I did not make any changes to the weighting or UV maps of Ruth 2.0 RC3 in order to make RuthTooRC3. I also used Avastar to export to Collada; I am pretty sure I kept the same rig without updating it to my version of Avastar.

2. My HUD doll was the same as my uploaded RuthTooRC3 AlphaCut mesh except that it was not rigged, and I resized it for the HUD within SecondLife and OpenSim.

Other Blender files in my repo are essentially original meshes from Shin's repo that I separated out to various Blender files so that it seemed more organized to my eye. (I am not necessarily the most organized; so that may only be in my eyes.)

[seriesumei]

Thank you Sean, that is very helpful. Does having the doll be unrigged make much difference? I can't decide if it being linked into an attachment to the avatar complicates that or not.

[AdaRadius]

Thank you Sean and Serie!

Ya, same file I used.

[ocsean]

Serie, If the HUD model is rigged, as soon as you attach your HUD, (even to a HUD location), the HUD model will attach to your avatar body, just like the regular mesh body does, and disappear from the HUD. I know this from the experience of doing it and wondering where the heck did the model go? LOL

[AdaRadius]

(I also posted this, more or less, to MeWe, a few people are not in both) UPDATE: Problems. I may as well upgrade to Blender 2.8beta now, and work on the rebuild with a stripped down (non-Avastar) armature, if I can find one (SL link is dead) and wait for the 2.8 Blender release (July?) and Avastar to go with. UV mapping - tweaks - are done, I think, though I need to upload Roth's new UV map for testing - I'll try to get to it tomorrow. @Kayaker Magic and I worked on this last week, trying to export from the Ruth RC#3 and Roth RC#1 dev files at GitHub. The exports taken months ago are working inworld, but new exports are not. Kayaker tried without the Avastar plugin and got major distortions. With the plugin, something goes wrong with the mesh so that either the neck no longer matches, in size, with the default avatar head, and/or the arms and hands no longer fit the inworld armature so that animations look very very strange indeed. Amusing if I weren't banging my head on the monitor. . .

[seriesumei]

Oh Ada! That sounds so frustrating! I wish I could help. One thing I have noticed when chasing down sources for some of the files we use is how many dead links there are out there. I think we should figure out how to mirror the things we can legally to have those available. So if you do get a copy of that armature from the dead link, and think it is useful, let's see if we can help reserve that somehow.

[AdaRadius]

@seriesumei That's a great idea! I'm looking through my folders, and see that my collection dates back to 2004, so maybe we can put a set together that will be useful. I'll start uploading to my folder.

[Deledrius]

Thanks for the update (I don't use MeWe -- not interested in community platforms I can't view without an account). I'm sorry to hear you're running into so much difficulty. I'm really hoping for something stable so that I can (re)start my work on making clothing and other items for this body. I had made some against the RC2, but the weighting changed enough in RC3 that I'd need to make adjustments and I would rather not keep doing that if I can help it.

I noticed some distortions in custom animations I've made that appear in Blender 2.8, but they also occur in 2.79 if I enable the New Dependency Graph option (which I believe is on by default in 2.8). I'm not sure if that's related to your issue, but I thought I'd mention it in case it helps your investigation.

What other files are you still missing that you need?

Anyway, thanks again for the work you are all doing on this. It is a deeply-appreciated project!

[AdaRadius]

Thank you @Deledrius - I haven't done any custom animations for R&R, except for static foot poses, so I can't comment on the dependency graph option - I've been reading the posts on it at BlenderArtists but that's about it. I'm not sure what I need at this point. Exports from the RC3 dev file via Avastar are not working inworld, nor are exports without the Avastar plugin, because the RC3 dev file is using the Avastar armature. As Gaia wrote (I think at the Discord server she had up for a while) - she's focusing her attention on the Avastar plugin for Blender 2.8, so she's not taking tickets on the current version.

SO, even though switching software midstream in a project is something I would normally avoid, in this case I think it's time for me to switch to Blender2.8 on this and wait for the new Avastar plugin. Plan B: maybe rebuild the project with the SL/OS armatures I have. I've been collecting them since I joined SL a thousand years ago and I uploaded the important ones to this GitHub so we all have access to whatever I have. If that doesn't work, Plan C would be to use the armatures that Gaia provides at Machinimatrix - similar to what SL has distributed, but possibly closer to what's inworld - she's done a lot of testing. I'm not sure how different viewers influence this - when we were testing recently, it didn't seem to matter which viewer.

Yes on weighting changes. Quite a few of us worked on RC3 and some work doesn't match with other work. What's left to do is fix the snakiness in the torso - no one wants rubber-hose animating for this. Fix the morphing at the shoulders and underarm, and fix the thigh-to-hip weights so that a cross-legged sit looks better. I don't like the way the sliders are working on the hands, and that's an easy fix, so I'll probably do that too. I can probably get the belly sliders working to around 60%, probably not more, because of the way they're built inworld - they affect too many volume bones.