Prim Vertex Editing

I searched the suggestions forum for something like this and didn't find anything, but I cannot believe someone else wouldn't have thought of this before so I apologize if this is a repeat.

The single most important feature on my personal list, that I would like to see in game, would be a feature to be able to drag the vertexes of a prim around.

Right now, we're very limited in the shapes we can make because each prim only has about half a dozen ways you can alter it, such as twisting, making one side smaller than the other, and cutting and the like. Additionally, even this is hindering because you cannot control which side gets shrunk, which axis gets twisted and where the cut shows up on said prim. Yes, it's possible to do a good many things by either being creative with textures, using tons of prims, et cetera, but the limits are still there, especially with people who have decent modelling skills but are hung up by having to be some sort of spatial and mathematical genius (a bit of an exaggeration, I admit, but still).

If we could move the vertexes of a prim, all of these ceilings would either disappear or be so transparent that they would be a mere ghost of the hindrance they once were. Lining the edges of two prims up would be a breeze; simply move the two vertexes of a corner onto each other, repeat for all corners of the side that touches. The number of shapes possible would shoot through the roof, allowing us to build with fewer prims, with more acuracy, and in many new and imaginative shapes and sizes. Naturally on some prims this would be moot, but even if it were only applied to cubes the possibilities would shoot through the roof.

So yeah, I think this needs to be done, and if it's 'impossible' I then move to have the code or optimization that would make this idea possible put in so it can be done. If we could move vertexes, our models would increase in quality by a hundred fold.

There's a reason why these limits are in place: prims, as they are now, can be described by a VERY compact series of numbers. This is completely necessary because so many 3-dimensional objects are being blasted across the net to so many people all the time in SL. If they had to send an entire mesh of vertices instead of just a series of 10 or less numbers, the efficiency hit would be staggering... it might not even be possible to have a world like this.

The bandwidth costs would be huge and flying across the world would result in quantities of data similar to a DOS attack.

Not to mention making physics extra complicated for the physics engine .

All you'd need are additional numbers for the locations of the 8 vertexes, but I digress. I was afraid bandwidth would be the limiting factor here. I guess it's not believed to be possible yet, though I still personally have little doubt that it could be done. Then again, what do I know, lol.

Now if only someone would invent a Bag of Holding for data, all our problems would be solved!


Who knows? Those compression scientists are certainly crazy enough.

Prims don't have vertices in the same sense that 3d objects generated from polygons do. Well, they do eventually, but that information is generated on your machine.**

(Warning: simplified explanation largely based on educated guesswork)


The simple case, a default sized cube prim (so we can ignore scaling, texturing, and ancillary data like Shear and Hollowing and such) is pretty much something like:

1. Center: (x, y, z)

Three numbers.

Since there is no vertex data in a prim, you can't edit vertices, obviously, so we have to add it, as you suggested. This is considerably more than merely eight more values (one for each vertex) however.

A polygon-based cube is fundamentally just a list of 8 vertices:

1. v1: (x, y, z)
   
2. v2: (x, y, z)
   
3. v3: (x, y, z)
   
4. ...
   
5. v8: (x, y, z)

That alone is more than eight times as much data as our default prim cube. But that just defines where the vertices are ... it doesn't tell us which ones are connected to which. For that, we need a face list, to define our polygons. This can be done as either quads (4-point polys, which are more natural for a cube) or as triangles (which avoid certain rendering errors). Quad poly list would look something like so:

1. Poly1: (1, 2, 3, 4) - This means that vertices 1 through 4, defined in the previous list, are the four corners of one face of the cube.
   
2. Poly2: (3, 4, 5, 6) - Note that this polygon is connected to Poly1 at vertex 3 and vertex 4, so it just refers to the existing entry in the previous list again
   
3. ... etc.

For triangles, each poly would only have 3 vertices instead of 4, but there would be twice as many polys (draw a line from one corner of a square to the opposite corner, and you just turned a quad into two triangles).

Since each vertex is 3 coordinates, and each of the six faces of the cube needs to be defined by at least four vertices (either a quad or two triangles), you can see that we are already sending quite a bit more data than a prim ... our vertex data: 3*8 = 24 values, plus either triangle data (6 faces *3 vertices * 2 polys per face = 36) or quad data (6 faces * 4 vertices = 24), for a grand total of either 60 or 48 values per cube. Compare that to our original 3 values for the prim version.

This discrepancy just gets worse with more complex shapes like icosahedra or curved surfaces like tori and cones and spheres (which need lots of polygns in order to look right). A decent looking low-res polygon sphere might have something like 128 polygons in it, which means quite a lot more than 8 vertices.

Factors like hollowing or twisting also make it worse. Hollowing would basically double the number of vertices in your list, and add a few more polys, whereas with a prim, it's just a single percentage. Twisting could multiply the number of vertices enormously, especially with quads (because polygon can't be non-planar or you'll get rendering errors ... twisting can make quads nonplanar very easily unless you add lots and lots of them. This is one of the rendering problems I mentioned above).


So anyway, what you are basically suggesting is changing SL to use polygon meshes for everything. (There's not much qualitative difference between a cubical polygon mesh and any other polygon mesh.) We'll get such meshes eventually (it's unavoidable if you want a realistic-looking environment), but right now, the only meshes SL uses are our avatars.


** A process called tesselation is applied to prims to turn them into polygon meshes probably somewhere between the SL client and your graphics card (because your card works on polygons, not prims), but the servers and client don't talk to one another that way. Curvy prims, in particular need this process (a cube is relatively easy to turn into polygons. A sphere ... not so much. This is why something like a torus is slightly harder on your machine than a cube.

Devil's advocate:
Mesh data is the same order of magnitude as a texture. A single prim can have, oh, 11 textures?
Streaming entire meshes is perfectly feasible (OSMP did it a year ago)... so maybe the physics engine can't handle it, but really does that necessarily mean anything?
Visuals have an important place in SL, even if they have to be phantom and unscriptable.
Trees anyone? Attachments?

How many meshes (at what resolution ... I think it uses Quake 2 mdl format IIRC) can OSMP handle in view without bogging down the network connection or rendering engine?

The problem is what happens when, not only avatars and their attachments, but also hundreds of random objects (with scripts, with rotation, with local lighting and shadows and shiny and particles and all of the related problems thereof) are composed of meshes and all need to stream down to the user at once.

Edit: I'm not saying it's not possible. I'm just wondering what the limits would be. If the allocation would be something like ... 2 low res meshes per 117 prims ... well, that doesn't improve the situation a whole lot from what we have now.

cubes with moveable verteces don't have to use that much more data.

There are many shapes that require overlapping prims right now and would be simplified if we could have draggable corners.

If we allow it for a new type of prim, a "mesh cube", it would be managable.

As it is, we have:

A cube actually has 9 sides (I think): the outside 6, two inside faces, and the "cut edge".
Origin: 3 32 bit floats (12 bytes total)
Scale: 3 16 bit ints (6 bytes total)
Rotation: 3 16 bit ints (6 bytes total)
Textures: 9 128 bit UUID's (27 bytes)
Color: 16 bits per side. (18 bytes)
Transparency. 9 bytes
texture scale, size, rotation: 118 bytes
Parameters: cut begin/end (at least 2 or 4 bytes, maybe more)
Twist: 2 or 4 bytes
Top Scale: 2 or 4 bytes
Skew: 2 or 4 bytes
(hidden): dimple: 2 or 4 bytes
Hollow: 1 byte


THis comes out to 207 bytes.

I may have missed some parameters, but that's what I can think of at the moment.


SO.. if we get rid of the cut, hollow, twist, skew, top scale, and dimple, 3 textures, and scale values, we get back around 150 bytes.

To match the current precision for scale, we need 5 digits. that's a 16 bit integer.

those 150 bytes of stuff would be replaced by 8 triplets of integers. 3 integers take 6 bytes, so we'd need 48 bytes.

So creating a new prim with 8 draggable verteces would actually be more efficient than the current cube prim.

Now this admittedly doesn't do a thing for spheres, toruses, or all the other shapes. But you could use easily the same "vertex drag" principle to do adjust the shape and size of cylinders and prisms.

To take this further... often, in a large build, more than half the faces of a cube are wasted. If we allowed meshes with 2-sided faces and uv-mapped texturs, we would not actually lose out in the end... SL would instead become more asthetically pleasing and realistic without using more bandwidth.

we could easily add a prim type of "mesh" with, say, 12 faces. This would allow for new types of shapes (especialy if we allowed bezeir [sic] curves) and still not use any more bandwidth than we already hae.

The limits would be up to LL to decide of course. I'm just saying we should keep a "can do" mentality around these parts, look for what can be done to give people the tools they need to continue creating great content. It is clear that for some situations meshes are the optimal solution in design, rendering, or even network transmission. Especially with all the new mesh compression techniques floating around academia.
For instance, jewelry is often hard to make because it requires torturing prims in complicated ways to achieve some very basic shapes not directly supported by the SL engine. You could make a lot of "gem" shapes with only a few points, and generate the others adding a few bits that would let you define the type of simmetry.
In the long run, SL will eventually have to cut itself loose from the shackles of parametric extrusion. We could move to a more generalized extrusion system right now with no performance hit.
Right now SL can only do linear or rotational extrusion of regular n-sided polygons when n=3, 4, or "infinite". How much more complex could it possibly be to allow a sane, user-defined, value of n?
Why can't I have, say, a pentagonal prism or an octogonal torus?
I'll tell you why
Sources in the FIC claim LL's netcode is crap. They want to clean it up eventually and move to something more flexible... but that's probably after 2.0 comes along.

For a discussion of Bezier surfaces, see this thread:
/13/95/63306/1.html

I may be beating a dead horse here, but prim vertex editing is "kinda" possible. Of course, the number of prims needed for most models ranges from astronomical to flat out impossible.

Application example here.


The way I see it, though, LL just needed a simple, concise solution for building that wouldn't let people go insane with the data in their servers - something that sorta happened, anyway.

The problem isn't the ability to be efficient with mesh versus primitive data; it's the simplicity of the system and constraints it places on keeping the data low. No offense, but most people that use meshes haven't the slightest idea what the heck they're doing.

So, as middleware, it's a fairly good solution. For the long haul, they should focus on standards to keep meshes with a low footprint. That's something steeped in the arcane pages of linear algebra, I'm guessing.