OptimoMaximo

You got me the wrong way: reduction or decimation will lead to similar results because the methods are similar (although limited anyway), still better than GLoD

It's Epic Games you're talking about, not LL. The pioneers of online gaming, those who for first came up with the whole idea of a game engine with modding in mind, many years before the others (the first Unreal Tournament online, dating back 1995 or 1998, can't remember right now). They've got a boatload of experience and knowledge in the field and that's why all other game engines run after UnrealEngine's features. Whatever plug in or scriptset in Unity that tries to port some of the most useful feature found in UE4 just doesn't deliver at the same level, beginning from Unity's "PBR" shaders (blinn/phong model based when the industrial standard uses ggx AKA Disney's tail fall off version). Decimation or Reduction in different softwares will always lead to similar results, may be better than the viewer's GLoD but still similar polygon reduction methods. A scripted solution to create just the lowest LoD as impostor is a good idea though

What is its LoD Power Level?!

Not at all. IK is definitely among the animation properties one could set. It only works on the default animation but doesn't when setting them upon upload. In the Object tab, there are the physics properties. Default density is 1000 Kg/m**3. That's the main killer. I was recently making a spacecraft and the vehicle scripts couldn't fly it until i set the density down to 100Kg/m**3. Bounciness does what the name says and for the cushions, i think, it should be a very important property to set.

The hip position is calculated from Avatar Center, a utility attachment point to mark the hip position when the character is not animated and in TPose. The calculation of the hip position is done by taking this original position and consider it the zero vector location. The reason for it is that all the joint scaling used to determine the new shapes happen locally within the hierarchy, so being the hip joint the root, everything happens relative to it. The height adjustments happen using the new size of the box that contains the avatar inworld. It makes sense if your standpoint is RL reality, with a growth pattern and constant physics applied. Avatars have none of those. They react to transform nodes that inherit their positions from accumulated local scaling, therefore the root must be the only stationary reference point or things would easily fall apart.

Yes but: Which means more data. If you compare the SL imported meshes from a viewer, you will notice that each SL face is a separate plane AND it takes its own square UV space. Being separated like that, each single vertex gets one UV vertex, which means the corners are made of double vertices overlapping on the same spot. Apparently, it's more costly to have 2 UV vertices on one 3D vertex rather than the opposite. The uploader tries to do that indeed, splitting the mesh into material sub-meshes. Most likely, the more common UV vertices are referenced in all the submeshes, the higher its download cost (more stuff written to file)

Hello @Motoko Oanomochi . Very interesting intervention, thanks for showing us how a pseudo-Unity shader looks in Sansar. Seen and worked on that sub-industrial standard shader long enough already, thanks. Personally, i couldn't care less.

Well, you know how it goes...

I'm sorry but a scene that shows around 1.8 million triangles within the culling distance/drawing distance definitely IS ans excessive number at one time. That may be true for single player games or these newer platforms where you download the place before you can enter, where realtime environment changes can't happen because you upload your experience/place for others to download and then enjoy. SL is on the opposite side, and rendering something that is constantly updating through the internet has a different load of computational costs. Plus, the design. An experienced Environment artist know how many polygons are allowed in the polygon budget and should not exceed that, however if the scene has to be very densely item-populated, the culling distance plays a big role. Designing a scene where you will never get to see farther away than X distance is a necessary skill to design packed scenes, and would be useful in SL too if you could force-reduce the drawing distance of incoming visitors, so that they render only at the intended distance, while the culled area beyond that is constantly covered from view This link you're providing, currently, explains how they're beginning to implement asset compression instead of using the original fbx asset file, for faster load. SL does that on both mesh and textures: collada files get compressed into their own mesh asset file and textures end up being compressed into jpeg2000. The difference is in the involved formats. Further down below they mention LoD creation as one of the anticipated features, and it doesn't even go into detail about any automatic or server side generation. Meaning that they don't have a LoD system in place already, or that they intend to change the current one. I'm more inclined to believe it's the first option, though i don't know.

I went to the diner too, but i stayed steadily at 20/23 fps. But the region details was my first check at the landing point and already 1.8 milion triangles were thrown at my/your viewer, not to mention the number of unique textures

Animating the joint is possible, but the bouncy effect is a physics simulation based on the avatar movements and they are two different things. This perhaps may work with something like llApplyImpulse to push the avatar and cause the physics to move the bouncy joints.

On a second thought, and not at all serious, given the inclination LL has always showed toward Hinduist naming (from the main continent Samsara/Sansar, the word avatar etc etc) and being Maya "the illusion" (or, in more modern words, the matrix) he taught you to manipulate, why not chanting a mantra to him and his generous loving contribution? Sri Phillip Meshinda hare Laggare, hey Net Binaryana viewerDeva (Lord Phillip lord of mesh destroyer of evil and the demon Lag, hey Net's peaceful binary place ward of the Divine Viewer!) =)

Same here. Upon inspection , the region showcases around 19000KTris, 19 milion triangles, of which "only" 1792000 Visible, and i dropped from a steady 95 FPS at Builders Brewery to 23 fps, at high/ultra settings. And i don't need a hardware upgrade.

Here is an example how a few days ago another Maya user has been able to trash poser =)

If you use Maya, i released an animation tool that works with HIK as well as custom joint positioned skeletons and exports .anim format. The interface of what? the BVH upload thing? I'm not sure if you're aware of the BVH specs being an absolute contradiction to the actual environment. here is a schematic explanation of what happens with BVH files BVH files have a standard Y up and Z forward. However, it should use meters as linear unit but, for SL compatible files, it's not the case. The original character was made in centimeter scale, so someone REALLY smart thought to convert it into a inch linear unit (from centimeters, scaling the character up by 39.37 you get that proportion). So an imported bvh for SL would showcase a rather small skeleton Upon upload, the uploader performs the following procedures (among other things): Recalculate the world orientation matrix to turn the whole character into Z up and +X forward Recalculate the distance between the joints and the mPelvis joint basing on the new orientation Convert those distances (inches) into an equivalently scaled-to-meters-joint-offset character Convert all the euler rotations found in the animation into normalized quaternions, plus they also perform an in place conjugation of such quaternions to maintain the W term sign consistent and, as such, can be trimmed off and be recalculated on the fly by the viewer (to include less data in the final animation file). Now, after all these conversions and world rotations, add also the "clean up" it does for you, BVH files uploaded into SL are VERY lossy in comparison to the original animations you made. In the worst scenario possible, we top all this again with our Poser character not being properly scaled and we end up animating a sit animation that in SL looks more like a dive animation (joking here )

The Avatar Workbench page in the Mchinimatrix website has them in .collada format https://blog.machinimatrix.org/avatar-workbench/ Probably not the best exchange format if you're working with softwares other than Blender.

Yep, indeed: I agree. Well if i can work with PBR assets i rather prefer keep publishing models on the UnrealEngine marketplace for considerably higher prices and WAY less time wasted fitting the asset to the platform than Sansar can offer at current state. They can do the usual business as much as they like, for what i'm concerned.

Quoting myself here ecause this topic has just reminded me about this. As a creator, i will not enter Sansar until an actual EDITOR for materials come out, as well as keyframed object animation (not scripted) and its relative Takes management to say the very least. Just the fact that they started opening the "Beta Creator Preview" without an actual Terrain system in place leads me to feel their features' definitions like trying to make a fool out of me/us. At current state Sansar isn't worth being classified pre-Alpha release. Sorry for this vent, i really needed it as i pulled the thing up myself, i made myself start thinking again to one of the most irritating things i've seen so far.

Instancing was available in old game engines like Chrome (not the browser) and BlueMars (based on CryEngine2 if i recall right). It's not a new thing and it's been used, more or less successfully, in the past in many games that featured similar characteristics to SL. Now the asset management and storage should undergo a big overhaul that should begin with implementing an inworld, user defined object hierarchy structure other than a skeleton, in the first place. So yes, since the devs we're talking about is LL plus the many other aspects/features needed to just lay down something similar to an asset management system, in SL this is most likely to not happen...or at least if it does happen, in twisted LL style flavor (like the "material editor" they announced a while ago for Sansar... which is NOT an editor, just more upload options)

I didn't notice the shapekeys, really. That is also good advice. As Etheria says in her message, to test the collision volume bones and how it works with shapes, she had to remove the shape keys in order to tell Avastar to add them again, anew. So, TPose first as it is the only one actually working, shape keys removal and then all the rest as previously explained. Good to see that you're getting in the right direction

Reusing things is not like instancing mesh objects, Chic. While a texture perfectly falls within the definition and definitely saves up on texture resources, on the other hand we have mesh assets that load as a unique object. Either you whip the item out of your inventory, rez from object or shift-drag to duplicate, if you experience a bit of network lag you can definitely see that the new/copied object reloads again, totally unaware of the mesh it came from was already in the viewer cache. A true instance does count in the polygon budget for a scene BUT it doesn't count against the number of draw calls per frame (being drawn once, its transform node does the rest for all the copies), thing that doesn't happen in SL, since mesh items do counts against LI (say, the "polygon budget") AND against drawcalls, being all those vertices detected by the viewer tools and counted. Your statement is not incorrect, at all. It's imprecise. In my opinion, at the current state of things in SL, reusing the same assets in full sim big builds is good to keep design and style consistency and performance, accurately choosing the items and textures for your design. True instancing would allow a boat load more assets in a scene than a simulator would ever be capable to contain in the current sim area.

Oh goodie! Since there is a thread about the importance of low poly counts and optimization, that's their response to the issue LOL!

Indeed, it doesn't work as you think. The physics enabled bones are the BUTT (disabled on the male avatar) and the pectoral ones (for the breasts). You can enable them using a physics shape body part to determine how those physics are going to affect those bones, but then it's all a matter of being physically animated in response to your avatar's movements, both from animation and actual controller. There's no script involved. As odd as it sounds, not even collisions would trigger any movement on the collision volume bones, unless that collision moves the avatar as a whole. The initial actual purpose of collision volume bones wasn't even for fitted mesh, go figure...

Look, i found a page that references what i wrote so far http://blog.machinimatrix.org/fitted_mesh_survival_kit/ Somehow, at least. So i guess that as long as you keep those custom properties it should work also without Avastar like shown in the second example i did

As you quoted me, i said "each asset you rez from inventory". Textures are rezzed on objects and reference one single image on server, so that is an example of instancing. What i was pointing out is an asset that goes to land from inventory. Those effectively are full copies of an original asset, not instances. An instance would have independent object properties with dependent (instanced) Shape node/Mesh Data. So a real instance would respond to vertices location changes on the original, but in object mode it may be positioned/rotated/scaled differently from the original. Also, like it happens in Unity or UnrealEngine or other game engines, updating the asset's mesh means automatic update of all assets that reference the original one. But this is a different type of instancing, where the asset is a compound of things, including a mesh object. So, basically, "they are an “instance” (LOL!) with different properties, potentially", as you said. But there is a very important missing link.