Jump to content

Siana Gearz

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Siana Gearz

  • Rank
  1. leliel Mirihi wrote: Flexi pre dates Qarl by a year. Are you sure? I'm too young to have experienced flexiprims being introduced first hand, but i heard a lot of times flexiprims being attributed to Qarl. Just googling "flexi-prim qarl linden" brings up a lot of publications (such as stories about Qarl being fired, introductions before interviews with Qarl, stories about mesh deformer) which attribute flexiprims to him specifically. This isn't of any particular regard though, as well as what he has or hasn't done, how well or how badly. I veered off. The technical state in which he delivered mesh deformer and the disappointing amount of effort he seems to have put into it is probably one of those reasons why it's not in, which was my point. Project dynamics is to be considered too. When someone contributes something on their own time, and he ran out of time or willpower to get it finished and polished, next person may acknowledge the effort, and in turn contribute their effort to the project. When you have a paid developer who underdelivers, nobody in the community will bother. Why? I'm gonna be honest. Jealousy is a part of it. Thinking if he gets paid, i should get paid too, but since i won't be paid, i'm not going to help. And yes, i understand, 5 grand is nothing, it's a good bit less than my monthly salary [when i have one]. I would have expected myself to deliver more in a month though, and i would definitely work longer and under industry rate, if the trust of community was at stake, if passion is involved, if my only purpose isn't to just pull money out of someone, twiddle the thumbs for a while, and then see things crash and burn. I'm not a disgruntled ex-Linden after all. Aaand sorry, i went into rantmode again -.- super sorry! The solution with separate morphs and setting a versatile standard, moving the intelligence into the tool code and/or into the hands of the creator, as pitched by Geenz, was actually a good one. It too had the potential GPU upload path bottleneck issue though, something had to happen to limit the resolution of rigged mesh artificially for that not to be an issue, or a refactoring of avatar physics as i pitched. I do think Fitted Mesh was also rolled out politically, in a hurry, and without careful consideration of whether it is ACTUALLY the proper idea. One proof is that clients shipping fitted mesh fail across the board on many ATI units across various OSes and years of driver versions, and they just brushed that aside as "driver bug" (well, what if it is - it affects a lot of people anyway, many without a viable solution!) and released regardless.
  2. I can give you some insight why i advocated that deformer not be implemented as-is, and i believe this point of view was shared by at least some of the responsible Lindens i spoke with. Basically, with SL, for every thing you add, you need to think: how bad will it be once everyone starts using and abusing it? And get limits into the system. Deformer worked at good performance in isolation, however, it has potential to quickly go bad with no good way to limit the issue. If a lot of people were wearing mesh deformer in crowded locations, the performance would tank badly with no way to salvage it. It's a performance dead-end. I had offered also an idea for a solution for that, but it would have needed to be deployed before mesh deformer. The bad point is interaction between deformer and avatar physics. Every movement of boobs requires update of the avatar mesh. These are a few thousand vertices, it's a quick calculation, and it's a small upload of a new mesh to GPU on every frame, or as it stands, every few frames depending how far an avatar is from the camera and how many avatars there are in view. It gets much worse if deformed mesh needs to be re-calculated. The calculation itself is reasonably lightweight, it takes less time than pushing new geometry to GPU, and could be optimized further. However, combined with mesh attachments usually being much denser, having usually tens thousands of vertices as opposed to default avatar's couple thousand, this will saturate the link to the GPU with some avatars around making use of it, considering we're already nearly saturating it with different other kinds of information we upload to GPU every frame. .oO(i should note, that the main memory to GPU bandwidth is really about 1-3 GB/s and we're not technically saturating it, but together with memory bandwidth overhead, driver overhead, vertex buffer overhead in the viewer, we are really limited by what we can push to GPU with codebase as it is, or perhaps even by principle of what we have to do with truly dynamic data, it's a bit complicated but the point stands that we can ill afford to keep adding to it, particularly with no well-defined upper bound) A possible countermeasure is reduction of avatar physics resolution for avatars with heavy deformed mesh, however i think the results would be unsatisfactory and visually surprising. The solution i had in mind is abolishment of current avatar physics code which updates the avatar geometry from morphs, and instead implementing it with jigglebones. Then, default avatar could be a normal mesh, technically implemented with almost same code as current rigged attachments. In addition to the base avatar bones, it would be rigged to jigglebones to drive the avatar physics movements, and near-100% compatibility with existing avatar physics wearables can be retained. Currently, avatar physics is very unreliable visually, so hard 100% compatibility is hardly a worthwhile goal, the results will depend on framerate and number of surrounding avatars, but with near zero physics cost, it can be made absolutely consistent easily, and nigh indistinguishable to how it would behave in prior system for a given framerate. You could say that the current system isn't even 100% compatible with itself because the results vary so much, if you were so inclined. Due to this change, the mesh creators would have to also rig their uploaded meshes to the same jigglebones, if they want avatar physics to apply to them. This should not break prior valid rigged meshes, because they didn't support avatar physics anyway. For mesh deformer functionality, a new deformed mesh would need to be calculated once at load-time, and the expensive framewise updates would no longer be necessary. I think Qarl Fizz didn't do due diligence with regard to mesh deformer. He delivered an incomplete, underperforming proof-of-concept implementation. It wasn't good in crease areas and did the most trivial thing there, i think some research into area influence or lowpass algorithms would have been prudent, and at least a demonstration of work done, even if they would have proven of little advantage. While it would have been an excellent solution if better developed, i'm not surprised it didn't go in, it couldn't have. The handful of lines of trivial, slow code delivered, is really disappointing for the sum he got paid. I think the other things he is known for also haven't been thought through quite as well as possible - flexis should have been a system with perhaps a handful of matrices and skinning instead of full geometry update - it wouldn't have looked exactly the same, but close and would have been hardware accelerateable, but now we're stuck with what we have. Furthermore, this would allow to flexify ANY rigid object at no further overhead, be it a tortured prim or a sculpty or even a mesh! Sculpts are OK, their complexity is well managed, but his initial implementation was also bad, with unreliable OpenGL readback, good thing this was overcome.
  3. Unfortunately i do believe rigging mesh in SL is a "good enough thing". You can rig a mesh to a very specific shape to follow it 100% exactly, however people don't usually wear a specific shape, a mesh is usually made for a variety of shapes. Other issue is that this invites z-buffer fighting because the GPU cannot reliably determine which of the surfaces has precedence. Because of very deep z-range in SL viewer, the z-buffer precision is particularly terrible in SL, it's only good down to about 0.2-0.5cm at typical avatar viewing distance. The reason is that the viewer must be able to render objects as far as 1km away, and as close as your own boobs in first-person-view mode. Commercial titles do a multi-pass approach where for example your own first person view hands/weapon aren't rendered together with the rest of the scene at all, and don't share the same z-buffer. Also parts of the scene further than 200-500m away are also usually rendered separately. This involves gameplay and artistic design specific to the z-buffer ranges chosen for these up to 3 distinct rendering depth ranges, because intersections between these cannot be resolved - your weapon is always going to appear in front of your immediate surroundings, and the far-range objects are always going to appear behind your immediate surroundings. That is, the objects assigned to either of these 3 ranges cannot intersect themselves with objects assigned to the other range, which is not a guarantee you can easily make with user-generated content not designed with these limitations in mind. So with rigged mesh design, you have practically two choices - either leave ample room between mesh and avatar, or prevent parts of avatar from being rendered using an alpha mask.
  4. Medhue, the way it works: there is the base skeleton, it's what, 20-ish bones. The base avatar mesh is rigged to this skeleton. Vertex weights specify, for each vertex, how much it is affected by the two base skeleton bones closest to it. When vertex weights are modified, the skeleton itself is not modified. You should also keep in mind that in the middle of any major bone, the weight of nearby vertices is always 100% to this bone and 0% to other bones. So whether in motion or statically, no major features of the avatar mesh can be affected by vertex weights, only the specific crease where two base skeleton bones connect is affected. You may be wondering, how it works with only two bone weights at all. Well, i can tell you that it can't work perfectly. All professional grade systems use three-bone or higher-degree weights as they allow better crotch and shoulder connections, where at least 3 bones are in proximity of the crease. However, the SL avatar is limited to two. On top of base skeleton, there are other bones, such as for attachments, volumetric bones, and Fitted Mesh bones. They depend on the base skeleton, but do not depend on vertex weights. The avatar mesh is not rigged to any of these. Attachment creators in Second Life do rig their meshes to both these bones and the base skeleton bones though.
  5. Hai. Mr. Oz Linden asked us to move a long-winded discussion about avatar vertex weights from the JIRA entry elsewhere, so i'm opening it here. https://jira.secondlife.com/browse/STORM-1800 The vertex weights determine how much each vertex is affected by its closest bones of the avatar skeleton, thus determining how sharply an avatar bends in animations at joints. Excessive creasing of stomach, shoulder and thigh area when animated in SL Viewer is all down to bad vertex weights. In my viewer, Singularity, modified vertex weights from this JIRA entry are aready deployed, under license of original contributor, Alison Alena. There are some issues with new weights that may still need correction, however i believe it doesn't interfere with fitted mesh or other features. You are welcome to experiment and judge yourselves though, opinions are welcome. As a word of note, i don't believe moving the discussion here as requested by Oz is reasonable - i think anything pertaining to whether and how an issue is to be implemented belongs on the JIRA entry. But we don't have much choice in that matter.
  6. Mesh repository code in Singularity is a bit stale and will need some rework - if the bug is regarding that part of the viewer, it has probably been there for a long while. However, it could be a non-mesh-specific issue, we also have some bugs in the renderer regarding object updates, and there can be texture related bugs too - either of those are probably recent and had not been present yet in 1.7.2. It is to be kept in mind that current Firestorm release is based on older version of the Linden renderer, same as in Version 1.7.2 of Singularity and Version 3.3 of LL viewer, while we have charged forward a bit. A suspicion that we have any particular bugs because we're V1-UI is totally misplaced, our bugs have other reasons - usually our own omissions when we try to make things better. I suspect the bug is an object update issue which not only affects mesh and we're hunting it now. We do not monitor these or any other forums. Discussing issues here is 99% pointless. Please report issue to Singularity Issue Tracker. Please specify where we can purchase reproduction items. Please also specify how it behaves after cache is cleared (from Preferences, Network), and which graphics settings you use. Copy-paste of Help->About Singularity... for system information would be nice too.
  • Create New...