New prim feature: Wrinkled

I'd like to propose a new distortion parameter for prims: "wrinkled." It would put a mesh on the prim face, though not one that could be easily controlled. Cheaper prim-wise than using a bunch of prims to give an irregular surface, not much needed in the way of interface changes, and it's hard to see how it would add any more polygons than rounded objects or the existing dimple commands. Need to be able to set it per prim face, of course, using LSL. You wouldn't be able to adjust the textures on different polys in the wrinkles, though -- they'd still count as one "face".

With this and the "rounded corners" option on existing prims, I think we could start to see a lot more variety in the look of objects in-world, and more organic looking objects.

What do the rest of you think?

neko

Well, I'm not gonna say I disapprove of anything that gives us more tools. We all need a lot more of that.

But yer talkin' about dramatically increasing the number vertices used to define a shape. The whole point of using prims is to keep that number down. So given that, don't hold your breath.

This would lead to an outbreak of 'PANT BALL' the likes of which SL has never seen.

Do you really think so? How many vertices does "dimple" add? How about those twisted torii? Or any rounded prims, for that matter?

You're right, I'm not holding my breath, but I don't think it's such an unreasonable request. I think it is much more manageable than the ability to import meshes, because it would be far easier to implement within the existing interface, doesn't require massive additions to the data storage per prim (an algorithm would be used to create the wrinkles, just as one is currently used to make avatar hair bumpy, reducing to a single data value per prim face), would control the number of new vertices being added and the way in which they could be manipulated (e.g. not allowing a different texture per poly), wouldn't involve selecting from among a variety of possible mesh tools/formats (and automatically irritating some people whose favorite tool/format wasn't selected), etc. It's a relatively minor change that would have a considerable visual impact.

But still, I'm not holding my breath... and there are other potential features higher on my list (like a better permissions system, especially for land).

neko

Actually I thought about something like this a while back too.

You wouldn't have to increase the info downloaded at all, it could all be implemented client side just like hair and clothing are already. I was thinking wind reactive prims like the plants but perhaps fixed along one (or perhaps more) axis... I had nicely fluttering flags in mind at the time. With perhaps a setting for weight and stiffness and max only 2 textures. It could actually be a fairly simple to define(and download) prim.

The downside might be that clientside it might be as hard to render as an AV (especially in a high wind ) so would be pretty GPU intense. 15,000 "cloth" prims fluttering in the breeze.. yikes.
But if implemented like bump is already, ie not until you're pretty dang close, it could work.

L8r,
UU

I don't think you quite understand how SL transports data about prims. The attributes you see in the edit box are all that is transported to the client. No more data. Cut for example is 9 bit integers (sometimes signed sometimes not, and displayed devided by 200). On the server side they are something akin to a float. If we assume they are all 9 or 10 bit integers in the protocall then we can calculate out the amount of data needed to transport the data needed to describe a prim.

object_key = 128 bits.
pos = 32 bits * 3
scale = 32 bits * 3
rot = 32 bits * 4
cut = 9 bits * 2
hollow = 8 bits
hollowshape = 4 bits (or is it 2?)
twist = 8 or 9 bits * 2
topsize = 8 bits * 2
topshear = 8 bits * 2
advancedcut = 9 bits * 2
taper = 9 bits * 2
revolutions = 9 bits
radiusoffset = 8 bits
skew = 9 bits
90 + 48 + 320 + 4 + 128 = 590
or about 74 bytes.
then 16 bytes per face (for the texture keys)
the most number of sides an object can have is 10?
so the worst is about 236 bytes per object.

lets take a guess that the average texture is 128KiB. To properly express the complexities of a mesh we would be talking in the range of a texture in size. And you know how fast textures load compaired to objects in a lagged sim.

Did you know that a sim with thousands of different textures will be very slow compaired to a sim with much fewer? Not because it's hard on the client to render but becuase it's hard on the sim to have to send thousands of textures to the clients. Mesh would not improve this situation.

Yeah I want mesh but there is no way to sell the idea to LL without redesigning how assets are sent to the client. They are not keen on doing this I can imagine.

I'd like to add that a dimple adds a lot of vertices. And so does a ring that's been twisted. But how many more do you think there are on a twisted ring after it's been wrinkled?

Maybe as the tech improves, you know? Building tools are always welcome

Let's not forget....
Havok has what's called a "deep think" issue where concave meshes can completly halt the engine. I believe LL needed to create a modeler that would not alow people to create this situation (with the exception of dimple, torus and hollows) and I believe these are handled differently anyway. Maybe Strife has info regarding this? BTW Thanks for the informative post Strife!

No, not to define it. Although Strife didn't include dimple in his calculations it only adds a couple of bytes to the download of the prim.

It *does* add to the rendered complexity of the item but that is calculated on your client, it is only stored as a couple of numbers on the server/sim.

If it were implemented as I was saying, like a tree prim, it would actually be *less* complex (to download) due to fewer parameters, fewer textures, etc.

As for Havok, if they're phantom like trees it's a non-issue.

L8r,
UU

P.S. Strife: add color per face, llSetText text, particle system info, texture rotation/flip info (per face), texture anim info, llTargetOmega info, phantom/physics state info, permissions info, creator tags, name, description... still under a couple of K probably but a bit fatter download if you consider them in the thousands.

Rocks are sorta wrinkled and are resizable and retexturable. Might that afford what you are trying to do?

What you want is "normal mapping" or sometimes referred to as a parallax mode of bump mapping. With a normal bump map, like we can already do in Selcond Life (with the provided bump map images only), light and dark areas are added to a texture to enhance a sense of depth. What parallax does is move and stretch the pixels of the texture to enhance the 3D look even more. Here are some good example images , the table full of weapons in particular highlights how much realism can be added.

What is it?

1. http://www.infiscape.com/rd.html
   

dimple is advancedcut and holesize is topsize. They share.

But you are right about the stuff i forgot (was dead tired and was having alot of trouble remembering). Prim name, description, owner, and permissions are all downloaded sperately on mouse over. If i had to guess as i'm not in the mood at present to think about the bit requirements for them i would say it's about 1k per prim including texture info, text & particles.

As to interpilation & self colliding shapes. LL has done a great job of dumbing down the shape definitions so the sim doesn't deep think.

Thanks for all the info, everyone.

I was definitely thinking client-side, with a fixed algorithm for the vertices, not having to download the vertices individually, and the collisions would stay the same. I'm essentially trying to propose a visual effect, not a radical change in behavior. (But this does have its limits, which I'll get to in a moment.)

But I think the visual effect would be a lot more interesting and convincing with actual bumps, not just the light-dark overlay Flux is suggesting. I've used that effect, and it's good, but not in profile.

Rocks are the right idea -- I'm just looking for more ways to do similar things. In particular, this came up regarding wanting to build caves. We can dig down and put a roof over a cave or tunnel, and even texture the roof with landscape patterns, but they always look unnatural because they are flat or rounded too regularly. I was thinking that wrinkles or bumps would help that. And they would, but if the prim still acts like it's flat or round or whatever, I suppose it will look strange when avatars walk across it....

neko

I think wrinkles and bumps and stuff would make for more compelling effects with organic structures -- like Neko said, caves, and the other suggestions in this thread. Even the option to import custom bumpmaps would be a boon. It's difficult to get some really ragged surfaces: even with shiny on, a bit of grit can go a long way.

a prim noise distortion algorithm would be fun, as would custom bump maps. I'll support those.

Graphics cards for a long time have been able to bump-map without any performance hit. Given that I think the only reason we don't have bump mapping in SL is that it would further increase the texture download bandwidth. Allowing anyone to slap whatever texture they like anywhere they like already means that the SL engine has major texture management issues that typical game engines don't have. Maybe they could allow bump maps if the size were tightly restricted. Making seamless tiling bumpmaps for things like stucco or brick isn't too hard. Certainly LL would want to look at implementing a basic technology like bump mapping before looking at something as advanced as displacement mapping.

tell that to my graphics card.

transfering the extra textures to the graphics card can over stress the arcitechture of older cards (you can't force 10MB in 1 second through a pipe built for 5MB per sec).