Prop 1088 add freehand scewing and manipulation of prims

http://secondlife.com/vote/index.php?get_id=1088



This feature proposition will not only have an effect on how many prims are needed to build an object but will also add an extra malibility to the current prims, thus adding even more diversity in results.

please discuss. Don't hesitate to discuss this with me in game... I'm more then happy to talk about this. I also have anotecards you can use to pass out amongst the building community.
please vote

http://secondlife.com/vote/index.php?get_id=1088

The central design principle behind the current prim manipulation system (from what I've put together) is: by reducing any prim to a short list of numbers, you can transmit more prims faster to the clients.

Allowing some sort of direct vertex manipulation, you COULD make more shapes out of a single prim, thereby using fewer prims, BUT it would take longer to transmit. You'd have to send every vertex's x,y,z coordinates, and for shapes like spheres and toruses, that's a lot of points.

The other reason this won't work is LOD or Level of Detail. This is a feature of the client that will use fewer vertexes for distant objects. A distant sphere might use less than 30 vertexes, while the same sphere up close would have over a hundred. This is because a sphere that takes up little space on the screen doesn't need such fine detail, but one that fills your whole view does. So the vertexes aren't fixed. The numbers we use to define a shape are combined with distance and size values, and then run through a routine that generates a list of vertexes. (Or something along those lines.)

True, it would be wonderful to have that sort of freedom to manipulate objects, but it's just not compatable with the current needs of Second Life and the current state of general broadband.

I'd much prefer subtractive geometry. (With that, you could cut a circular tunnel through a cube by subtracting a cylinder from it, for example.)

Well I think then if you allow for vertex manipulation or skewing then you should have an optmize function that will translate it back into the limited vertices, thus solving the object detail problem

Also I think Havok transmits vertices anyway regardless of whether you can see it or not

Havok is only server-side.

This sounds impractical, but if there were a vote for CSG I would support that. Constructive solid geometry *can* be expressed as an operation on prims.

Then what is the gfx engine client side

Ferguson. First thing you have to realize is that the prims are just parametric objects. None of them are manipulatable meshes. I'd be happy enough if they introduce just a cube prim that can do this.

Applying it to other shapes like the sphere would require vertice information in the order of several hundreds for each prim.

Havok doesn't transmit anything. Its just a physics engine on the server that calculates polygon collisions. The server then sends you the information of how and where the object is moving.

Everyone nearby the moving object will get sent this information so they all see the same thing. If it was calculated on the client side, then you'd keep seeing physics prims which cease to move when the owner disconnects or leaves the sim.

ah okay well that was informative.

I'd still like to have the skew and manipulate though... if not on the vertex or point level, then maybe just the ability to pull or manipulate one of the axises to a point.

like beaing able to take the side of a cylinder and stretch it to a wedge so i could have a rounded side and a wedge side. from what you've mentioned this should be possible without needing to define vertices. unless i'm wrong there as well.

My thought is nomatter what if it causes the game to perform sluggishly, chances are the Devs won't impliment it nomatter the clamoring by the community.

Yes, you can create a wedge from a cylinder and stretch it. It looks just like. . . . PIE!

Actually, I think the amount of data isn't that excessive. Its probably no larger than the textures that we use. However, why add more data through the already limited pipe.

But the real reason why a lot of the suggestions seem to fall on deaf ears is, I think LL is far too busy working on solving so many other problems. And theres probably a lot of crappy old code to sieve through to solve those problems. But someone there is probably taking notes. Just no time to acknowledge it.

SL started in 2003. Its been almost 3 years of them patching and glueing and strapping the beast together with sticky tape and boogers. Just give them the time to do things.

Some fun history is at the SL History wiki:

http://history.secondserver.net

I don't think the OP is talking about real-time deformable prims. What I think he wants is a more robust 'stretch' box; essentially a GUI that would allow the builder to deform the object. If the deformations were limited to what can be represented by the current numerical values, then there would be no more increase in dataload.

Already, the current system allows people to build really complex shapes from single prims. I don't see how an interface like this could make any that are more complex. I think the most difficult problem with implementing this would be to figure out on the fly how to accomplish what the user wants (i.e. translating the stretching into the numerical values in th editor). But this would only be an issue during the creation of the prim. Once done, it would be like any other prim.

Non-symetric scaling of linked objects would be cool.

I'll settle for greater resolution in the topsize values!

Not sure what this means, but prims need to be constantly in the same state, because everyone that sees it needs to be sent the info on how that prim is created. It cannot be 'frozen' into another form.

Having a stretch box still requires control vertice data. Its much less than data for each vertice, but it puts a heavy load on the client side to calculate the deformations everytime you go near it. This is similar to the deformation tools in 3ds max.