OptimoMaximo

Because "open" is usually a function to open the files that are native to the software. Try looking for "import"

No way to export directly to collada .dae format and have it de forming along with the avatar. There is an extra set of steps, you export from MD using either obj or fbx format, import it to either Maya or Blender, rig it until it works on the animate able avatar in your software, and finally export that for SL in collada format

Most likely it is an animesh object.

It's a PEBCAK bug Problem Exists Between Chair And Keyboard I don't know who came up with this first, but it's a well known programmers' punchline against inept users 😂

Getting offended? Over what? Don't make me laugh please. Oh sorry, you already made me laugh. I got over it all, so much so that I don't WASTE my time with LL nor the "pros" in the content creation user group. Yeah keep going, I need good laughters.

Yeah, right, exactly as you say. Keep going.

Yeah, and such pissed replies for what blatantly is NOT a match with the implementation I would cheer upon, with height maps missing. And about participating in the project? Yeah no , I don't waste my time with LL. I quit taking part in their content creation user group meetings much time ago, because they don't listen to advice given for possible issues, except when they come up and the solutions given the first time are being credited to others, who apparently listened, and sweep in to provide the solution "they" found (sounds like anything on a wolf skeleton and its animation, Med?) So yeah, I'm not interested in wasting my time, thanks. As already said during project Bento, I'll get what the pros come up with and make it work for me, if I'll ever bother to implement any scripted solution for Maya.

Alright Arton, let's bring this back into context, shall we? My initial comment was about what I would cheer upon, that's the exact same type of implementation that Unreal does. OH so sorry to have missed a link contained in the page you linked to. We'll might have as well given the correct link in the first place, pointing directly to gltf project. How could I dare to expect that, though. OK then finally, after finding the link in the LL project page, I see the implementation, that is not what I stated I would have cheered upon, came back to the forum and say it, and that's your reply... Yeah... Well aside from the fact that in productions nobody uses gltf, rather every single studio I know is working towards using USD, I don't see how you (or someone else in some posts above, I can't bother to verify who was it) could claim that the new system uses the same implementation that Unreal does, unless you don't have a clue about what implementation actually that is. OH well...

OK I found it, it's a link contained in that page but... That's not the Unreal Engine standard, nor the exact type of implementation it does, which, quite obvious, is not what I would cheer upon as I already said. Specular Level in Unreal is just one texture, and not two for intensity and color. PBR in general is about consistency of results given a certain lighting setup on material specific features. Being able to tamper how the specular light gets tinted defeats the purpose of pbr... Oh well...

I don't see a specification of the packing in that page. However, from the list I saw in previous posts, specular level is missing, as well as height map. Reason why I was saying I would really much cheer on such exact implementation.

I would very much cheer on an implementation that would use the same texture packing that Unreal uses. Base color, Emissive (optional) and normal map each as a standalone texture Ambient Occlusion, Roughness, Metallic and Specular Level packed together into one texture Height map as a single 1 channel 16 bit texture for Parallax Occlusion, optional.

This is incorrect. Every single joint in the skeleton can be animated over the base animation layer.

The difference between a male and female skeleton sits in the scale value of the mJoints and scale+position values for the collision volume joints. So if you import an fbx file, in the import options, you will see that the default operation is "add and update animation", which means "add whatever isn't already in the scene, otherwise if same name is found in the scene, update its animation data". So I think you started with a male, imported something made on a female, the bind pose took the latest updated skeleton and therefore bound your stuff to the female avatar.

Interactive normalization means that Maya automatically scales the weights on any given vertex so the total always amounts to 1.0 and no more, upon brush stroke time. Post instead let's you work with weighting that you paint freely, regardless of the total amount of weights, which at this point can sum up to more than 1.0. The word "Post" refers to the assumption that the user will run the normalization manually after the fact, or it's going to use an automated normalized version that results from the current weighting (but this is reserved to Maya internal usage, for example animation caching and Arnold .ass files export and kick operations... Yeah not a joke, in Arnold the standalone renderer needs Maya to "kick.ass export" 🤣 but I'm digressing... )

When issuing the smooth bind command, make sure to set the max influences to 4, maintain max influences checkbox ticked on and normalization set to interactive. Alternatively, the newly released Mayastar 7 does it all for you with a single button click, as well as a copy weights feature with another single button click, all tailored and optimized for SL.

Aside from the fact that an elbow doesn't bend in that direction, the deformation problem you see is an issue inherently associated to how the mesh body was weighted, so you can't do anything about it, except avoiding those angles when bending a joint

Did you apply pose as rest pose as well? In pose mode, ctrl + A

OBS for recording, and Kden-live for editing. Similar to Premiere, but it's free and open source with tons of plug-ins and possible output settings, both compressed and uncompressed solutions. Though, when I need to compress something with no loss of fidelity, I just use the raw ffmpeg utility from the shell.

I can say something about it. Right now, USD is the format that every vfx and cartoons studio want to move to. In the last two years I moved from the game industry to the movie productions, so I'm well aware as per why this is such a buzzword now. Imagine that every studio has every department starting point with a "build" stage and a finish point with a "publish". Every single component and subcomponent gets a publish, and a versioning number as well. Every step in the production has to query the latest or the recommended version of every single component and subcomponent from the previous production step to build their starting point from. So this production method leads to the need of automation tools for the building system (queries to the database, say Shotgrid, save path retrieval or download, building in the scene) and publishing, which is the reverse process. Therefore, interoperability between studios is not really that viable this way, because each one has their own system, categorization, dissection method and sometimes proprietary nodes involved in the scene. USD comes in as a generalized "builder" and "publisher" of scenes, because it can be updated at a second time, offline, or can contain scripted instructions to do things at loading time to update assets if need be. So as far as dcc software solution interoperability format it is extremely useful, considering that the latest fashion consists in studios collaborating remotely and doing work splits on a per-department basis. If needed, I could provide some examples, but that would take quite a wall of text right now, so I will leave at that if the process is not clear. In the game industry, instead, this isn't a so much felt need as much as in the movies, because the production within a dcc software is limited to the assets alone, and the building happens in an engine, as opposed to the movie production, where animation scenes are considered assets (compound assets made of tons of different assets) on their own and need to be updated from time to time with content from other stages, departments or people, and so the asset that goes to rendering needs to be rebuilt from scratch before one can continue to work on it. From rumors, USD format is Pixar's take at a compounded equivalent of gltf that is more inclined to work with many pointers to different asset types in a single archive file, containing useful Metadata for the kind of work flow that is used in movies, rather than a file format containing more "raw" type of data for the contained asset.

2000$ that using either Maya or Blender is going to crash it. I still advocate for an exchange format that is readable for EVERY software, like gltf. Then a software specific version for each software.

No it wasn't. And most of the creators were using Blender. I wonder how that platform is going these days... And why🤔

Export that animation 😉 The thing is that you will need a script to trigger the start play animation once you uploaded both mesh and animation

Most likely because the skeleton was already facing the +X axis, the export for SL added a rotation that's only necessary when using the default Blender orientation, which is - Y forward

This old post might be of help

DAG type of system for the win Animats. That would also help to open the doors to an actual, real instancing system.