Parametric Model Debate
- Bandwidth: While parametric models (prims) are somewhat restrictive, it means SL requires only very small amounts of data to describe each prim, making efficient object data streaming possible. Though it would be more efficient for many classes of items, they would have to be static as to stay under the bandwidth limits. Since facsimiles of most mesh-based models (meshes) can be made with prims, in LL's mind, this is an advantage for prims but limits what can be modelled (without overlapping/intersecting prims) and creates many covered, hidden polygons (which cause more framerate hits).
- Transformation: Additionally, prims can be transformed in parametric ways without it having to be specified by the modeler in advance (keyframe animation), something that meshes cannot do.
1. Obviously, non-parametric models can't be transformed parametrically, but meshes can be transformed vertex-by-vertex, polygon-by-polygon--UNLIKE parametric models
2. And bandwidth-intensive to change it vertex-by-vertex.
- So what? You're gonna complain about bandwidth yet dismiss how bandwidth-wasteful SL already is (redownloading GUI images/sounds each session, for example)? -Eep
1. Arent they cached?
2. GUI images & sounds are shipped with the client, why do you think it's so large?
- It's mostly large because of ..app_settings/static_data.db2 and, after an inspection of it, the GUI images appear (12.3MB TGAs of 25MB) to be in there (well, everything specified in viewerart.ini anyway but I know the standard terrain textures, collision sprites/sounds, and default wood texture are redownloaded EVERY session. -Eep
- But they aren't part of the GUI. -BW
- Yes they are. Try to close a window right away and you'll notice the lack of a "close window" sound until it mindlessly redownloads EACH SL session. While the GUI images may not be redownloaded, the GUI sounds are. -Eep
- Keyframe Animation: Would bloat the size of any mesh. For the versatility and flexibility of prims, mesh modeling does not come close. -BW
1. And parametric models don't come close to the versatility and flexibility of meshes.
- Can they in the same amount of bandwidth? -BW
2. By changing the prim type, the number of polygons changes as does the number of textureable faces, also its vertex setup for those faces while using minimal bandwidth. I maybe be a bit out of the loop on this, but I haven't seen this sort of thing done before with meshes, and I cannot imagine it would use the same bandwidth.
- Arguments For Meshes:
- Describe objects that parametics cannot do efficiently (which is any non-primitive shape) but there is a point where the number of prims in an object consume more bandwidth then it's mesh equivalent; at this point prims are used less as building blocks and more as polygons.
- Which goes back to why meshes are better overall. However, parametric primitive shapes could be animated within meshes, too. -Eep
- If meshes are better, why are there more cons then pros? Meshes are better suited for describing complex static objects but overall are not better, as described in the next section. -BW
- Arguments Against Meshes:
1. level-of-detail transformation is CPU-intensive and imperfect; parametrics transform without hassle.
1. There is no point in having this discusion if they cannot be rendered in real time.
2. Because of how prims transform, the modeler doesn't have to waste time building multiple LOD's, saving bandwidth.
- For a mesh to have multiple LOD would require extra bandwidth. -BW
- LOD levels can be created dynamically. -Eep
- But can it be done on hundreds of meshes at the same time, in real time? A while back LL changed the LOD calculations on objects to be object-based instead of prim-based, resulting in a dramatic improvement to framerate. If parametric LOD calculations cause lag, just imagine the effect with meshes; dynamic mesh LOD calculations are more expensive. -BW
- Have to have the entire mesh before dynamic LOD calculations can be done; or it will have to re-done -BW
- Dynamic LOD could complicate animation -BW
2. Meshes use more bandwidth and would have to be streamed entirely while parametrics only stream the non-default parameters.
- 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).
2. The terrain is a bad example because a good portion of it is constant and built into the client.
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.
1. The terrain is in part constant - the texture and color is stored/computed locally by the client.
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.
1. If avatars are parametric (and there are quite a few sliders!), ANY mesh can be made parametric!
- 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.
- 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.
1. You have to have the parametric model before you can change its shape, too.
2. True, but if I'm understanding BW correctly, you need the entire mesh; with parametrics you need just one prim.
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).
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.
5. Are too rigid for the bandwidth constraints; they cannot compete with the flexibility of parametrics in the same amount of bandwidth.
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.
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.
- 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.
- 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