Don't click here unless you want to be banned.

LSL Wiki : ParametricDebate

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl338.us.archive.org

Parametric Model Debate


Debaters: Eep, BW, Chris








2. Meshes use more bandwidth and would have to be streamed entirely while parametrics only stream the non-default parameters. -BW?
  • Not true: specific vertices/polygons can be altered without transmitting the entire mesh each update; how do you think terrain modification works? It's a mesh! -Eep
  • 1. It's a mesh, true, but only to a certain extent. LL is able to take liberties with terrain because it can be described using a texture (look at how estate owners can set their land properties). -Chris
    2. The terrain is a bad example because a good portion of it is constant and built into the client. -BW
    1. Um, no it's not. Terrain can be modified on-the-fly just as primitives can be and it's downloaded just as objects are. Oh, guess what else is a mesh: avatars. Turn on cloth rendering in prefs ("Bump Mapped & Cloth") and watch the av's hair/clothing vertices animate with, oddly, no bandwidth impact. -Eep
    1. The terrain is in part constant - the texture and color is stored/computed locally by the client. -Chris
    2. Also, avatars are parametric--that's why we use sliders to manipulate the av properties rather then uploading a mesh itself. The cloth movement is vertex manipulation done by a DLL that comes with the client download, so it naturally wouldn't affect bandwith. -Chris
    1. If avatars are parametric (and there are quite a few sliders!), ANY mesh can be made parametric! -Eep
    • Each mesh must still (at least initially) be described vertex-by-vertex. Even if users are able to dynamicly load parametric vertex manipulation code for their particular mesh into the client software (effectively creating their own primitive), all of this requires significant amounts of bandwith. -Chris
      • I doubt it--and certainly not as "significant" as you and BW think. -Eep
        • Actualy the av meshes use morphs. Every time a vertex is affected by a morph, it is redefined in that morph's definition. For example, the av head contains 1132 vertices, 1844 polygons (highest LOD), and 93 morphs (not including hair or eyes, 32,554 redefined vertices). The head then has 5 LODs which recycle the main definition's vertice/morphs and just redefine the polygons. The other 4 levels respectively have 1290, 590, 277, and 184 polygons. Total size: 1,650,567 bytes, vertices: 54,336 bytes 3%, morphs: 1,568,554 bytes 95%, polygons: 25,120 bytes 1.5% (the other 0.5% is for headers etc). As you can see, morphs take up a significant percentage of that. But the head isn't a good example because expressions are morphs. The lower body contains 977 vertices, 1654 polygons, and 24 morphs (5771 redefined vertices). 5 LOD, polygons (1158, 662, 330, 249). Total size: 352,059 bytes, vertices 46,906 bytes 13%, morphs 280,090 bytes 79.5%, polygons 24,328 bytes 6%, (2% for headers etc). The point of this exercise: morphs are the simplest form of animation; morphs bloat the size of the mesh quite alot. That said, LL's format isn't that efficient for streaming. What it is designed for is render speed. The format is ideal for being read directly into memory. While compression (etc) could make the streaming footprint less, it wouldn't address the issue that the mesh es are huge when decompressed. Currently, a sim full of objects is only a few megabytes. A single mesh can be well over a MB (like the av head). A sim full of meshes would eat a lot of memory (it is my understanding that the av mesh is only ever stored once in memory). 1000 meshes could eat 1GB of ram.-BW
          • Keyframe animation then for parts of meshes. My point is: most meshes don't NEED to be fully animated, but the benefits of meshes exceeds just animation, as I've already explained (framerate, detail, etc). Oh and where did you get the models? Do you have a viewer or something? I'd like to check it out myself... Anyway, my dealings with RenderWare script (RWX) files in Active Worlds shows that the binary versions of ASCII files can be SEVERELY compressed--and that the ASCII versions tend to have a LOT of duplicate info (material stuff mostly). I'm sure those file sizes could be brought down substantially. Regardless, I don't understand why morphs have to be so large when they should just be vertex ranges or something. -Eep
          • The avatar mesh morphs don't redefine the entire mesh just the verties that are being changed. LL's format is very basic, it only supports morphs, 3 vertex polygons, uvw mapping, remaps, joint table; what a remap is i do not know, i got the strings from dumping the text from the exe. What I do know about remaps they are vertex pairs. The W portion of the UVW is optional and has to be enabled by a flag in the header (eyes for example don't use W). Morphs cannot effect W. I don't think it's right for me to expose LL's format or to distribute the tool i wrote to decode them.-BW
    2. The terrain mesh's U, V, X, & Y values are constant; only the Z value changes.-BW
    • It still adds to bandwidth--OH NOES! <eyeroll> -Eep
      • And those constant parts are not streamed to the client, they are built-in. Like I said before, the terrain is a bad example. Any user mesh will be unable to take advantage of any constants built into the client. -BW
        • Terrain and avatars are examples of meshes (parametric or not) that have their vertices manipulated. -Eep
    3. You have to have the mesh before you can change its shape, meaning the entire mesh has to be streamed first. -BW
    1. You have to have the parametric model before you can change its shape, too. -Eep
    2. True, but if I'm understanding BW correctly, you need the entire mesh; with parametrics you need just one prim. -Chris
    3. Chris understands what I'm saying. When you download the client, the parametric models are already computed and in the executable (hard-coded), meaning that when you login only at most 2-dozen variables are needed to describe a prim. To describe a 100-vertex mesh would be something on the order of 500 variables--adding a single morph could double that. Modifing it vertex-by-vertex would be highly inefficient.
    • Then, obviously, a mesh could have specific parts of it set as parametric. Come on, guys, think relatively please... -Eep
      • And setting that up adds to the size of the mesh requiring... more bandwidth. Not to mention, now you are arguing for parametrics. -BW
      • The default avatar mesh comes with the client download, the vertices of the mesh itself are never streamed--just the parametric vertex manipulation parameters. How would you go about implementing a parametric mesh? I would understand an argument for texture-mapped primitives (having a surface defined by a texture, much like terrain) included in the edit tools, but we haven't yet discussed the implications of meshes in relation to Havok. -Chris
        • It all takes bandwidth--and there are pros and cons to parametric-only or mesh-only designs, but the bottom line is: it's all vertices and polygons in the end. I'd rather have higher framerate (and more optimized, efficient models) than more bandwidth (which is becoming more and more moot with broadband connections, while framerate is ALWAYS an issue). Why is LL so concerned with model bandwidth when it's wasteful in SO many other areas like updates (mindless whole-client redownloads) and texture/sound redownloads EACH SL session? It's hypocritical! -Eep
          • Because redownloading an asset each session is only a small percentage of the assets sent to the client. Is it really redownloading them, or just decoding them from the client cache? The cache is unsorted and can contain 26,000 assets, it could take a while to find and decode an asset. -BW
            • If SL takes THAT long to freakin' find and decode its own cache files, that's just pathetic... -Eep

3. A sim full of custom meshes could easily exceed 1GB (see bandwidth above). -BW
4. Asset sizes larger then the average image (see bandwidth above). Seeing how long it takes for images to download people would complain about mesh rez times. -BW
5. Are too rigid for the bandwidth constraints; they cannot compete with the flexibility of parametrics in the same amount of bandwidth. -BW
6. Steep learning curve associated with most modeling applications. Most SL users find Photoshop a steep learning curve and that's a walk-in-the-park compared to 3D Studio and Maya. -BW
7. Animating a mesh would have negative effects on sim performance as it would require recalculating the bounding box via dynamic LOD (prim bounding boxes are about the same as rendering objects with LOD turned all the way down). Seeing as the sim has more responsibilities than the client to perform in real-time, it is not practical. Also the bounding box generated may be unsuitable. -BW
  • Bounding boxes can be set with each keyframe. -Eep
8. The complexity of a mesh's bounding box may be too great for Havok to handle in real-time. -BW?
  • Bounding boxes don't have to change, but even if they do, it's a freakin' BOX. If Havok can't handle dynamic bounding boxes, it sucks. -Eep
Streaming subdivision surfaces: http://www.blender.org/modules/verse/index.php
A list of papers, some of which are about streaming 3d, http://graphics.im.ntu.edu.tw/~robin/plist.html

EP-- (not Eep. :D). This entire debate seems to be formed on the misconception that SL has to either use prims OR meshes. Is this true? It seems there are places where prims perform better... and it also seems there are places where meshes would be better (such as a very detailed, non-changing build). Is it impossible to have a world where both meshes and primitives co-exist side by side, each performing in whatever capacity works best? Why the tunnel-vision "one or the other"?

More discussion: 1

prim
There is no comment on this page. [Display comments/form]