Jump to content

Mel Vanbeeck

Resident
  • Content Count

    75
  • Joined

  • Last visited

Community Reputation

26 Excellent

About Mel Vanbeeck

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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
×
×
  • Create New...