Prim Suggestion: Tensor Product Surfaces

I'd really like to see the addition of tensor product surfaces as building prims. I believe this would be a boon to creativity, allowing builders to produce complicated organic shapes with greater ease. For example, an animated flowing cape or a table cloth or a automobile with sexy curves would all be much simpler to make with a Bezier/B-spline/NURBS patch prim. I realize that integrating such objects into the physics model may be really tricky (I don't imagine collision detection with tensor product spline surfaces is in any way a simple computation), but perhaps they could be visual objects only or else their physical interactions could be roughly approximated by the convex hull surface, which is a simple mesh. Streaming the object over the network doesn't seem like a problem since all you need to transmit are the control points and the knot vectors. OpenGL supports splines, so it's not like you'd have to hire Carl de Boor to figure out how to get the surfaces to display in a computationally feasible way. Other than an issue of computational feasibility that perhaps just hasn't occurred to me, I can't think of a good reason not to have splines supported as a prim object. There are just too many wonderfully creative things that can be done simply and intuitively with them that can only be done with great difficulty using polyhedra, quadric surfaces, and torii.

First off you have to know that SL doesn't stream mesh to the users. Avatar mesh are based on static files the client has; object mesh are created from a seriers of equations that the sim sends the input values for. Something like 24 floats are used to define the shape of an object; excluding size, position and rotation. I think these would be interesting to have *but* we are unlikely to get them

What Strife said. ^

But I think it'll move in that direction eventually - once it's feasible to stream that amount of data.

Didn't Xero state pretty clearly that you would need to transmit only the control points and knot vectors?

The question then boils down to the number and size of control points and knot vectors, versus the same for current primitives. If they are similar, the objection given doesn't stand.

A basic n=m=3 Bezier patch is defined by 16 control points. So, there would be a total of 48 floating point numbers that would have to be transmitted from the server to the client. A basic n=m=3 b-spline or NURBS patch has the same number of control points and additionally has knot vectors, which add some complexity (more floating point values). For comparison, the torus prim as implemented in the game is defined by 22 floating point and 3 integer parameters. So, yes, these surfaces are somewhat more complex than the existing prims, but not excessively so and not nearly as complex as the mesh that would be required to render a visually equivalent surface. Even if, for example, a Bezier patch counted as 2 prims for the purposes of a land owner's prim limit, they'd still be absolutey worth it because it would otherwise require many of the existing prims and a lot more of the designer's time to produce a surface of similar complexity. Even then, you'd likely have unsightly discontinuities at the seams because there is currently no way to achieve blending of the surface normal vectors at the boundary between two linked prims (at least none that I'm aware of).

Only by choosing what you try to build very carefully, and knowing a lot about the shapes.

Physics and collision detection is what I'd worry about. Also, maybe I'm missing something, but this seems to define a patch of surface rather than a solid 3d object? The physics engine doesn't deal with objects of zero thickness even with the prims we have.

So, yes, right now it sounds like it would have to be phantom if it could be made to work. IIRC the same set of parameters are stored and sent for all prims, whether cube or torus, so I suspect the flexibility in needing different sets of data for different prim types would need some major rewriting.

It would be very cool though

!!!!!

Do you have a reference for that?

If it's true, it constitutes a major inefficiency since the vast majority of prims are cubes, and ought to be highlighted in Hotline to Linden to make certain that this flaw is on the timeline for improvement in 2.0.

I think that the ability to torture prims (like dimpling cubes) reveals this.
This "inefficiency" lies at the heart of a very many wonderful builds in-world. The number of knots and nodes that would be needed to represent a cut, hollowed, dimpled, top-sized torus, for example, would be much, much greater than the set of parameters that SL currently uses.

You're missing the point. Tortured prims deserve tortured parameters, ie. lots of them. The collosal majority of prims though, which are not tortured, don't.

Yes, these are surfaces, not 3d objects. However, except in the degenerate case where all the control points are coplanar, the convex hull is a polyhedron. So, the physics interactions could be roughly approximated by the convex hull. Granted, this means that collision detection would be happening with a bounding container rather than the surface itself. So, visually, collisions would happen in the air surrounding the surface instead of happening on the surface. If you really wanted them to be 3D solids, that could be done by defining 3D objects with spline patch faces and enforcing C0 (or greater) continuity constraints on the edges where the spline surfaces meet, although this would increase the amount of data that would have to be streamed to the client because you'd have a spline patch for each face. After all, all solids in computer graphics are modeled as infinitely thin surfaces with the inside/outside faces defined by the direction of the surface normal vector.


That really depends on whether the prim code was written with extensibility in mind. If prims were implemented using an Abstract Factory design pattern, adding a new prim that behaves in a different way is no big deal. Otherwise, yes, it would involve a major rewrite.

No I'm not
I'm not justifying the way in which it's done - just supplying evidence to back up Seifert's assertion (you asked if there were any reference to it)
My main point actually lies in the second half of my post though. Earlier on it was said that:

In this we see that something as simple as a 3x3 patch already uses double the data of a torus. One of the simplest patch surfaces uses twice as much bandwith as SL's currently most complex form. And as the point count goes up, so does the bandwidth requirement - so I would say they are "excessively" more complex.

But that wasn't the point I was addressing.

The point was a very simple one: the data streamed down for a prim should not include those fields that are in their default, untortured state. That's the whole idea behind the concept of "default", after all --- the values do not need to be supplied anywhere, especially not in the download stream. And since the huge majority of prims are untortured, such an implementation would save an immense amount of traffic.

This has absolutely nothing to do with the pros and cons of more advanced types of prims, it's orthogonal to that discussion. But if the above commonsense approach to defaults isn't being used for traditional prims, then it's hard to hold a sensible discussion about future ones. A given parameter should be streamed down only if it has a non-default value!

Fix the old prim streaming before compounding the problem with new objects.

/me rotates PI_BY_2 conversationally
good point - maybe a byte of two up front, with each bit repesenting the absence/presence of each small group of properties (twist/shear/top-size/etc)

Indeed. Or even less than that --- the mere fact that the message block for a particular object has terminated can imply that all unmentioned parameters should take their default values.

I'd say the better measure of whether or not they are "excessively" complex is: would you need two or more of the existing prims to build the same surface that you could build with one bezier patch?

How many prims would you need to make this surface?
http://www.cs.utexas.edu/users/fussell/courses/cs384g/bezier.jpg

That surface is effectively impossible to build with the prims we have now. Not without ugly seams, or using a prim per polygon or something.

But then... what is that surface for? We're not interested so much in "can one build this exact mesh" so much as "can one build a thing that looks like an X", where X is whatever you want to build.

There are always going to be things that are impossible to build, until we can build meshes themselves. So there will always be restrictions that one has to try to get around.

Personally, I would love to get my hands on something like these - I'm into doing things with smooth surfaces. It'd probably also be a boon for sculptors. I dunno how useful it would be for other builders.

Hmm... just thinking out loud - one of the very nice things about the prims we have are how they can link together with each other. By which I mean that fitting a sphere onto the end of a cylinder to get a smooth join is easy. I can see that fitting these surfaces together with each other would also be easy, but fitting beziers to spheres say, looks difficult if not impossible.

I think LL probably needs to completely revamp their network code. There are many optimizations that are possible.

And I ask, why not have more prim types? Let's say that the data stream for a prim is like this (I'm not sure how I'm supposed to represent this, but bear with me)

byte 1--prim type (256 possibilities!)
byte 2--Length of name
next bytes--name
next byte--Length of description
next bytes--description

Now it will pass along any non-default parameters. The form of an object when it's first rezzed is considered default.

next byte--Parameter type (PRIM_SIZE, etc.)
next bytes--Parameter value

Prim textures would be like this:
Parameter type: PRIM_TEXTURE
next byte--side number
next bytes--asset id

And so on. You could represent a just-rezzed cube in about 11 bytes.

I did some study into SL's object definition a while back (6 months) and couldn't make heads or tails of the format. Sure i could isolate parts I recognized but at the time it didn't dawn on me to consider default paramaters. Without looking at my notes, the default paramaters sounds like the way they are doing it now.

No you couldn't, the key of the object takes 16 bytes.

I'd suspect that most of the optimizations that have been suggested (and others that have not been discussed here) have already been implemented. Default parameters likely have been considered. Also, because the parameter values for prim geometry do not use the full range of values of a single precision floating point type, it's possible that they are represented using fixed point arithmetic. I'd bet that most of this is beside the point anyway though. The number of bytes required to represent the geometry of a prim, whether it be one of the existing prims or a Bezier patch, is dwarfed by the size of texture data even with JPEG 2000 compression. Even if the compression ratio were as high as 200:1 (a generous estimate), a 512 by 512 texture would still require (512 pixels)*(512 pixels)*(1 byte/channel)*(3 color channels + 1 alpha channel)*(1/200 compression)=5.12 kilobytes to represent (+ image header).

JPEG2k is a progressive compression sceme that is capable of standing mass dataloss and still produce an image (all be it, parts will be corrupt). A solid color image of any size or color takes up about the same amount of space (200 bytes +/- 40 bytes).

Your average 512x512 image in SL takes up about 70KB +/- 30KB. 1024x1024 usualy average out around 400 KB +/- 100 KB.