Jump to content

Mel Vanbeeck

  • Content Count

  • Joined

  • Last visited

Everything posted by Mel Vanbeeck

  1. This is the worst news I've seen in a while. This means the applier marketplace will be further fragmented, inventories will be filled with unusable items, and people will have a lot of extra work to do to figure out how to find content that works for their chosen mesh body parts. Considering the main consideration for all LL's feature updates has been to avoid breaking any content, this is basically breaking the entire market that it affects, since it's not really possible to utilize the technology as intended (eliminating onion skins) while maintaining compatibility with any existing applier
  2. The question of how difficult it is to do, or what is the simplest/best way to handle it has yet to be answered, as far as I am aware. I'm not as ignorant on the subject as you imply, but it's not my role to answer those questions. In this context, my role is just to say what I think is necessary, and why.
  3. I do my work, Lindens do theirs. You say this as if a feature request is invalid unless you're able to program the feature yourself being intimately familiar with the entire system. I would be happy if the Lindens were so in tune with the SL market that they didn't need to ask for feedback on feature development, but lacking that, it's good that they do. All mesh body systems will wind up updating for bake on mesh one way or another, and customers as well as skin/clothing designers will have to grapple with whatever that winds up being. Customers could wind up being cornered or just confu
  4. Why not instead just release all the relevant features together, then people's stuff all continues working normally, and everyone can decide what to do for future product with all the options on the table? Does that just sound too orderly? You understand that there will be a bit of a grid-wide panic among designers and customers alike if appliers are rendered obsolete, right? This is no way to do things. Designers having to scramble to get usable products on the shelves, customers trying to figure out how to navigate body part updates, etc. How many appliers people have and use regularly
  5. I came a bit late to today's meeting catching what seemed to be the second half of a debate over the subject of whether it would be worth the energy for the Lindens to create the script functions to support baked mesh from appliers. The people who seemed to be against script support seemed to be saying that it's normal for the entire grid to have their entire inventory become obsolete when a new technology hits the grid, and that this effort is to be expected of SL businesses. The issue of the appliers that people have already purchased did not seem to enter into the consideration at all.
  6. Klytyna's analysis (while *****ly) is absolutely correct on this. This project will not really be finished until materials are supported. If it gets released without materials support, it will certainly get implemented and used by most (if not all), but there will still be a need for legacy onion skinned layers on any mesh body that intends to put clothing over skin, and they will still be in the mess of having to sort out alpha cuts since it won't be able to inherit the body alpha from the baked skin layer. I will say that in the current generation of mesh bodies, materials are very impo
  7. I have not done any testing other than uploading a pair of eyes (on unscaled bones) with one of the eye meshes scaled up by 7.777%. I was expecting to see the scale of the eyes change at a different rate compared to the default eyes, but throughout the slider range the small eye stayed small, and the big eye always matched the default mesh as far as scale, though it seemed to be set back about 1mm or so. I used the mesh eyes that are part of the MayaStar kit; I don't know where this slight difference in position is coming from. https://i.gyazo.com/cd961628ec43d0ede68511ed14aca41d.gif All I c
  8. Matrice Laville wrote: The scaling of the system eyes is controlled by morphs and the slider definition uses multiple overlapping ranges which result in a not exactly linear dependency. For the Alt Eyes we decided to use the slider setting for 0 and 100 as reference markers and then make a linear interpolation. This results in some deviation between system eyes and alt eyes in the slider mid range. The differing scale value value_max="0.56" was necessary to map the eye scaling of the alt eyes to the scaling of the system eyes. We could use the slider midpoint (50) as third reference mark
  9. There appears to be a problem concerning the neutral position for the eye and alt eye bones. When the eye size slider is set at 50, the eye bones are scaled to approximately 93%, but the eyelid bones are all scaled to about 100%. If the eye size slider is set to 64, the eye bones are scaled to 100%, but the eyelids are scaled to <"1.002000 1.086000 1.198000">. This lack of a neutral position for all involved bones results in a discrepancy between what you see in modeling tools and what you see after importing. Perhaps I could scale the eye bones to ~93% in Maya to match what's in-world?
  10. Ah yes of course, I had completely forgotten about the hair base and its eyebrow shape sliders. Simple answers are good, thanks Gaia!
  11. We've been working on our heads a bit and we're now seeing some strangeness in how the bones are positioned in the in-world skeleton vs. what is defined in the avatar_skeleton.xml file and the 7/18 .dae export.  This is using the default shape, no animations, no custom joint positions. The left and right center eyebrow bone is clearly positioned higher than it should be. I went and verified that the avatar_skeleton.xml values match the values we have in Maya. I don't know what's causing that one bone to be out of place, or whether it's just that one bone that's out of place (other bones m
  12. It's beyond my level of expertise to opine strongly on the question of .fbx or .dae, honestly. There is a discussion of this topic that I found at http://forum.unity3d.com/threads/pros-and-cons-of-different-3d-model-formats-fbx-dae-ect.344009/ which seems to support my general impression of the issue, though, which was the top google result of "fbx vs collada". My original idea was that the .fbx exporter in Blender worked pretty well for crossing platforms, but if you're already neck deep in doing custom .dae exports perhaps effort is better invested there. I really couldn't say.
  13. The bones shown in this list follow the joints in the outliner in reverse order, so the top layer contains mHindLimb4right, and you can see the second selected, and so on. The layer ending in 03228 (with no _ncl1_x extension) corresponds to the mGroin bone, keeping with the pattern. As far as these layers go, a bone can only be part of one layer. I suspect that in the long run, the .dae file in the wiki will not be used for anything other than importing the skeleton to various programs to bind custom meshes to, and possibly copy weights from. Other than just a basic test, I don't see why
  14. Hi Gaia, thanks for taking a look at these Maya import problems. The 7/18 file is much better. I still receive the errors regarding the bind pose and transforms, but the errors concerning the blender profile and the one layer per bone are gone. For curiosity's sake, the 7/15 file created bone layers that looked like ths:  To reiterate, though, this is not a problem with your 7/18 file. From what I can tell, the errors during the import of the 7/18 file are inconsequential.
  15. Matrice Laville wrote: Mel Vanbeeck wrote: That file is clearly very messed up. Can you give more details about where the file is clearly messed up? The Jaw Bone is missing in the files that we created on 12 july because the collada exporter dropped all bones which are not used for weighting. This is an intentional optimization to only provide the used bones. This optimization was discussed in the bento meetings a couple of months ago (allow partial rigs). I do not see where the collada files are messed up. The files from 15 july have been exported with the "include all animation bones
  16. Unfortunately it seems that in many cases the priorities I would put on the changes are somewhat inversely proportional to the amount of work you estimate is needed to resolve them. Showstoppers - likely to cause major customer backlash and customer service costs Jaw Angle: moving jaw bone destroys mouth animations, and customers are extremely likely to want to play with this slider if a head is weight painted in such a way that it actually changes the jaw angle. If a head is weight painted so this slider has no effect, customers may play with this slider then leave it in a bad position with
  17. Oh, and the outer eye corner is affecting an unrelated bone (mFaceEyebrowOuterX). If there isn't a pair of bones for this slider, the slider just needs to be disabled. I understand that from a certain perspective it is useful to be able to affect your eyebrow shape, but that's not the label on the slider, and the confusion that is likely to result among both designers and customers is not worth the feature's benefit.
  18. I mentioned Lip Fullness and Lip Thickness are having some problems due to the varying distance between the pivot and its vertecies.  I have the upper lip rotated up slightly to show the teeth, and these sliders are causing that to get amplified beyond the original setting. Some amplification is ok, but these sliders go well beyond too much (and well beyond what can be corrected through different weighting). I would suggest trimming the effective range of lip fullness to max out about where it sits when the slider is set to 75-80. Lip thickness turns into a problem by the time it hits 70
  19. Another adjustment that occurred to me if the lower teeth bones can't be removed is that the tongue should probably be parented to the lower teeth rather than the jaw bone, since the lower teeth will be the primary structure the tongue will have to interact with. If the lower teeth are moving relative to the jaw for various mouth position corrections from certain sliders, this would mean the tongue has a moving target to deal with as it is animated, and since the tongue will likely be using translation animations even in heads that are built to be compatible with sliders, this could cause the
  20. arton Rotaru wrote: Looks like today 10x is actually an understatement. :matte-motes-smile: Uncharted 4 Dev Flaunts New Milestone In Face Animation Smokes, 300-500 bones is where they go after ~100, lol. Well, I guess if the engine and hardware can handle it why not? Nice find ty.
  21. As a Maya user, it was fairly difficult to get going in this project. When I first got involved, things weren't uploading, etc, and the Maya file posted was not up-to-date. Once the June 2nd wiki update happened was the first time that I was able to actually upload anything and get a good look at the status of the project. Yes, I could have bought Avastar and started picking up Blender much earlier, but not being part of the original project it took some time to understand what the cost of not getting involved would be. I'll go ahead and eat my words a bit. Here's where they're using a fa
  22. I can get pretty far with "theory alone" a.k.a. just examining the demo rig. However, many of my diagrams were showing our Simone head rigged to the bento mesh. Granted I chopped Simone up quite a bit to help focus on the areas I was talking about. Does that give me enough cred to talk now?
  23. Head Size - Essential Head Stretch - Wanted Head Shape - Wanted Head Length - Wanted Face Shear - Not useful — I don't think I've ever seen someone use this other than as a brief joke Crooked Nose - Wanted Lip width - Wanted Lip Fullness - Wanted Lip Ratio - Nice to have Mouth Position - Wanted Mouth Corner - Wanted Lip Cleft Depth - Nice to have Shift Mouth - Would not sacrifice anything for it (if someone wants to look like this they can do it with an animation instead) Jaw Angle - Wanted Jaw Jut - Nice to have, but again this is such a rare one that a looped animation would probably suffice
  24. Actually, SL's rig can't work just like Snapper's rig, because that rig has about 10x the budget for bones, not to mention the dynamic wrinkle maps. Snappers Facial Rig is the Facial rigging tool for Autodesk Maya and also available for 3ds Max. It contains CG skin shader with multiple wrinkles maps and Rig Manager to handle selection and to create/save poses. No more information for now but you can take a look at demo video below. In fact it's unlikely that you'll see anything that detailed in any game today. Don't get so carried away with talking down to me that you stop making sense. Wi
  • Create New...