object idea

I was wondering if it might be possible to have an object made up of many prims consist of 1 prim by merging them. maybe not entire houses.. but smaller things like chairs, or cabinates etc. once they are linked and locked they would not be able to be modified as individual units..
Much like photoshop and layers.
if you merge down 7 layers you can only modify as 1 layer now.
I dont know if this would take up as much server space as using many prims, but it was just a thought tha tI had.

This is probably impossible, because a primitive is, well, a primitive. Every client doesn't have the information necessary to render a "Quicksilver's Chair" without knowing the prims it's made out of. So, the server has to stream the individual components rather than the whole thing.

I saw some stairs the other day that were made with texturing. The prim itself was a single flat incline, but it was textured to look like it had many steps like stairs. This might not be exactly what your asking, but you can do clever things if your talented with photoshop.

As Loki said, texturing.

On a good day you could do a 2-prim chair with an alpha texture or two. On a _really_ good day you could do a 1-prim chair. All provided you don't mind the texture upload costs.

That and the requirement of good Photoshop-fu, of course

I'm a strong proponent of texturing as well, but it does have its limits. I would like to see the staircase - every attempt I have made looks good from a distance, or from one angle, but not from others. The one-prim chair is also possible, but suffers from oddities such as the front legs being invisible when the chair is viewed from behind.

It is so sad that we all have to sacrifice prims

There are some wonderful intricate designs that no one can afford to release

Textures with alpha just dont cut it...

The best thing i saw was a 1 prim table with Base, column and top. Done by some creative cut, hollow etc then swapping between basic shape types to get end result. The table looked like a Dumbell weight, i wish i could remember how to do that.

I am making a 10 prim vehicle..but I'd rather make a 50 prim one.

Now when ever I crash into buildings at high speed all i see it boring blocks until textures loads... I miss the lushness...it is such a pity cause I find the 3d Tools wonderful.

I know a lot can be done w/ hollow andn textures.
but like was said before.. sometimes thos just dont cut it.
I haven't delved into being a prim nazi because i am yet to own a house, but thought of that last night and though it may work.. but yea.. becuase everything is made from prim's and thats all the client knows I can see how this is a challenge.

Did anyone ever take a good look at the Linden supplied trees? They are multiprim objects but they only show up as one prim. They know how to do it, but they ain't saying. This whole prim thing is misleading, they are only using prim totals as a way of counting objects in a sim. It is textures and scripts and the shape of objects that tax the servers. Funny how the exact same servers that could only accomodate 10,000 prims suddenly can now hold 15,000 prims. For months we were taxed on the height of objects and objects made of light and now those characteristics don't matter at all.

There is more going on here than the "official" prim limits.

C'mon Lindens, let us in on the secret of how to make multiprim objects register as one primitive....

The trees cheat, Buck

As far as I'm aware, the system just sends stuff like "tree, x, y, z, height, type". They're all rendered client-side, and I think there's advanced settings you can set to determine how it does so. Fractals n' stuff.

As I'm given to understand, that's how they get the trees to sway with the wind too.

The 15000 prim limit raise was due (officially) to an improvement in streaming of the objects to the clients. That's allegedly the main geometry bottleneck.

Non-physical scripted objects shouldn't tax the servers much - most things requiring client update include a delay, and the scripts are time-sliced to available time anyway.

The height thing I _think_ was just to keep the skies clear. Especially when t/p's cost money, having free flight lanes would be very important, so you don't want sky builds all over the place. Less important now, perhaps.

Davo - you've got your 31 prim limit, I suggest you use it to the fullest. Just remember that passenger=prim, and you'll be able to get a fair few prims per vehicle.

Totally, OT btw Buck, but what the hell is your forum icon from?

That's the second time I've seen an anigif from that (I assume) random film recently.

Davo, I can prolly help u with that. If u look at my 'junkyard' in the corner of immac, I've got half a dozen of those dumbell cut shapes on the go (and plenty of other ridiculously morphed single prims too

As well as making good tables, they make good columns, navel bars, earrings and various other things. It's the same principle as the hottub u saw on my deck that is a single cut torus for the sides and seating areas combined, and is used extensively to make my full body armor so close fitting. Advanced cuts are your friend (although maybe not the clients).

One idea that I've suggested the Lindens might employ some day is to create a "make local primitive" feature, whereby a repeated structural element such as a pillar, or windowframe might be designated as being a single object, then rather than downloading a half dozen different sets of coordinates, rotations and sizes, only two vectors, rotation and location would be sent.

If you used 5 prims for a window, but had 20 windows, you'd only have to send the equivilent data of 5 prims for the original one, and then 19 more prims for each copy of the first "local prim". The other way would require a transfer of 100 prims for the entire set of windows. Obviously, it would be a further extention of the already fairly steep learning curve of the SL building engine, but for those of us who knew about it, it'd be a handy way to both cut down on the transfer time of our builds, as well as a way to save prims. I would imagine that the prim cost of heavily repeated objects might go down as more of them were rezzed, in an effort to acknowledge both the decreased bandwidth consumption and the reality of rendering that many more polygons.

As for trees, yes, in fact they are a single prim. Remeber that SL's "prims" aren't true primitives such as one might expect to find in 3D Studio or Maya, rather, they're fairly complex, predesigned models that are able to have certain parameters passed to them so as to appear differently.

Consideration of the number of prims available to us through the "Building Block Type" dropdown list in the Edit window, (Box, Cylinder, Prism, Sphere, Torus and Tube) as well as the Grass and Tree objects, and possibly -- I have to admit, I'm speculating here, in no small part to some wishful thinking -- the avatar model leaves me with a count of 8 or 9. I further propose that the prim signal in the SL communications protocol may, in fact be not just a single byte, but a 1-digit integer, giving us a maximum of 10 objects with which to build.

This is the sort of speculation that either results in messages from the Lindens along the lines of, "Catherine, you've... never written a network app before, have you?" or "Did you break into the CVS server!?" In other words, I have no idea what I'm talking about, but I could be lucky here. It's not important anyway. (*pats her homemade, reverse-engineered SL client* "Soon, my pet, soon!"

No, I have no idea where I was going with that tangent either. Onwards!

So yeah, fancy stuff, Kris. I like the maroon coloured thing. If only we had a way to change all that stuff in the Object tab of the editor window via LSL. I'd love to see those animate and grow on their own.

And finally, to Hawk:
That's a clip from a Japanese TV commercial for a large construction company, Anabuki Construction . I believe it's about five years old or so. As part of an effort to not seem... you know, evil and all, (they are in the same business as Halliburton, mind) they commissioned these commercials depicting large, anthropomorphic woodland creatures not being crushed under the wheels of progress, so to speak.

Because the company's name, "Anabuki", sounds similar to "Anabu-kin-chan", Little Red Riding Hood in Japanese, they chose her as the mascot of the ad campaign. You know, it's one of those newfangled "play on words" things?

Anyway, the deal with the gigantic furry testicles in Buck's forum avatar is this: that's not a raccoon. They don't have those in Japan. That's a tanuki, (Remember the Tanooki Suit in Super Mario Bros. 3?) commonly (but erroneously) called a "raccoon-dog" in English. (Just as westerners tend to say "panda bear" rather than "panda" in colloquial speech, a sort of attempt to classify species by behavior and appearence rather than genetic heritage.) Though it is a member of the canine family, the tanuki only looks like a raccoon. Parallel evolution in action!

In traditional Japanese folklore, the shape-changing Tanuki plays a role similar to that of Coyote, the trickster spirit common to many Southwestern American Native cultures. (Some anthropologists and cultural historians have suggested a link between the two, but I suspect it's another case of parallel development.)

And in folklore, a Tanuki gets his powers from his testicles and scrotum. Seriously. So that's why they're depicted as being monsterously large in the commercial. And the reason for having Little Red Riding Hood come face-to-ahh, "face" with said monsterous appendages, then giving us the reaction shot of said little girl looking bewildered and somewhat frightened is because the Japanese media is completely insane

For more on Tanukis, Anabuki Construction and Anabu-kin-chan, please visit your local library--er, no, visit these sites:
http://fursuit.timduru.org/dirlist/FursuitVideo/Commercials_Ads/anabukin/
http://www.stinky.com/anabu/index.html
http://images.google.com/images?q=tanuki&hl=en&lr=&ie=UTF-8&oe=utf-8&safe=off&sa=N&tab=wi
http://www.anabuki.co.jp/anabukin-chan/
http://www.nausicaa.net/miyazaki/pompoko/faq.html#title

What you're talking about here is what's called "instancing" in other 3d apps and it seems perfectly feasible to me. The idea is exactly as you described it... the recipe for the object needs to only be stored once... for all the other instances all that's needed is the offset from the original in postion, rotation, and scale. It's a way to keep the file sizes down and free up RAM for the renderer.

Instances would also be hugely useful in Inventory so that people could put no-copy clothes into multiple outfit folders but still only have one copy.

As Chip says this would be HUUUUGELY useful! The amount of times I completely misplace clothing or jewelry because I've saved it into a new outfit. And it really is a pain to not be able to say 'yeah but I also wanna use this in this outfit, too'.

On occasion I've even bought multiple copies of stuff just cos it's easier than trying to work with the inventory (which reeeeally needs an overhaul, Lindens! (at the very least we need multiple selection drag n drop, searching etc)

BTW, Cathrine, you are referring to archetypes, sorts of character themes that appear throughout human culture. Trickster as you mentioned above is also found in Loki from Norse mythology. Other common archetypes are the boy-king(King Arthur, Luke Skywalker), the captive princess, the absent-minded wizard. I am not sufficiently knowledgable to comment on whether Tanuki/Coyote are derivitive, or just common applications of the Trickster archetype.

Thanks, Dusty, I know. Never post to the forums when you're sleep-deprived, guys.

NP, Cathrine. You apparently knew of which you spoke, I just tossed the word out there for the possible edification of others, and because I am fascinated by the architype concept.