Talk:Mega Prim

To Do

Would be nice if this article could contain:

• History of mega prim creation
• Legitimate use of mega prims
• Banned use of mega prims
• Mega prim liberation through physics engine (part of history?)

I would write it myself but I'm not an expert about it... Lynch ^{(talk|contribs)} 01:50, 5 September 2008 (PDT)

Googled most of the stuff on my own now... still welcome any input =) Lynch ^{(talk|contribs)} 02:32, 10 November 2008 (UTC)

Mega Prims and Lag

It has been recently proven and tested that mega prims, in certain situations can be a large cause of sim performance, creating lag. It was hard to prove because the specific situations that megaprims cause problems is when avatars or objects are colliding with or standing on (also a collision) a megaprim. The amount of lag a megaprim will cause can also depend on its size. The larger a side that is being collided with, the higher the collision cost on the region appears to be. That being said, just one avatar and a few objects colliding with one megaprim on a quiet region will not cause much noticable problems. When combined with several megaprims floors in public busy places, the amount of sim degradation is extremely noticable. Estate owners and managers can monitor region collision debug screens to see the collision cost of megaprims are.

-- Removed from main article for lack of supporting source evidence.

Non-phantom mega prims might also cause a problem for the havok physics engine, since - again because of their size - they might detect - and need to handle - way more collisions per prim than with regular prims and therefor cause lag.

This argument is not founded and it's actually totally wrong. Why ? Because mega prims are mainly used to REPLACE many smaller prims in a build and the increase of collisions per prim is then compensated by the decrease in number of prims. Example: you use one 100x100x0.1 mega prim as a floor instead of hundred 10x10x0.1 prims. Then when you walk on this floor with your avatar, the physics engine will detect the exact same number of collisions with the mega prim as with the 100 individual prims. The actual difference is that your 100 normal prims have each 6 faces which means the viewer and the physics engine on the sim server have 600 faces to deal with (for only one useful surface: the one on which the avatar will walk on), as well as dealing with the corresponding object/object occlusions (only the top face of each prim actually being rendered and the rest being occluded) while your mega prim got only 6 faces for the same floor. Also, with the normal prims floor the asset server, the sim server and the viewer have to deal with 100 different objects, each needing their parameters to be exchanged on the network and stored in database and memory whereas the mega prim floor is one single object. FACT is that the mega prim floor LOWERS the lag A LOT instead of increasing it. Of course, because you saved 99 prims with your mega prim floor, you will be able to build more objects on the same parcel (and then the storage saving argument becomes moot), but for usage in large builds, the mega prims are still saving a lot of lag by avoiding to deal with faces which would otherwise be useless (not shown) when using smaller prims. —The preceding unsigned comment was added by Henri Beauchamp

Hi Henri!

I moved your edit from the article over to this discussion page, since the article page itself isn't the right place for this. I want to state that I appreciate your addition, since I wasn't sure with this argument either. In fact, I wrote a comment on Andrew Lindens talkpage shortly after I added the argument to the article and requested clarification. After we find a consens, we can reword it and add it to the article again.

Just for the record: I am aware that, when I walk over a mega prim, it won't detect more collisions than when I walk over a regular prim. What I wanted to say is, that when more avatars walk over a megaprim floor, these are all collisions with the same prim, while - when you got multiple prims as floor - the count of collisions per prim is smaller than before, cause Avatars are walking over different prims now. The argument I heard was, that the later scenario would be less computationally intensive in havok. I am not sure if it is right or wrong, that is why I requested clarification.

The texture argument on how a mega prim reduces lag sounds logical to me. I don't know if it outnumbers the effect on the physics (in case there is one). Furthermore I think it might be two different kinds of lag. The physics lag (in case it really happens) would be server side lag, while the textures would be lag caused by the slow datastream. I think in a later version of the article, the texture effect you mentioned should be included. So thank you very much for that!

Lynch ^{(talk|contribs)} 17:20, 11 November 2008 (UTC)

Greetings,

Not being as good as you are with Wiki formatting, I will just put this reply in italics.

The argument about the number of collisions per prim is completely moot: each collision results in one event server side. What mostly counts as far as lag is concerned is the total number of events per second (which is directly related to the time the server will need to deal with all the events), and not the number of events per prim. In fact, having all the events occurring on one prim instead of many might even cost less processing time, because you will not have to deal with loading the characteristics of each prim at each new event (they will be already cached or stored in variables (depending on how the event code is implemented), and ready for the next event)...

As for the number of faces to deal with, it's not as much a problem with textures (unless you texture all the faces of your multi-prims floor differently) than a problem with drawing (or calculating occlusions to avoid drawing) all the hidden faces of a multi prims floor (for the 100m x 100m floor in my example: 600 faces in total for the multi-prims floor among which only 140 will be visible (the top and sides surfaces of the floor), against 6 faces in total for 5 visible for the mega-prim floor). In this case, the lag will be due to both the calculations needed on the viewer side, and to the amount of data to transmit over the network (each prim is worth 1Kb (compressed) to 3Kb (uncompressed) of data, so a 100 prims floor is 100Kb to 300Kb whereas a one mega prim floor is 1Kb to 3Kb). The latter (the amount of data) is not as important as the former (the occluded faces problem) as if you saved 99 prims on a floor, it's also because you want to use these 99 prims in a more useful way (and thus the data for them will also have to be transmitted to the viewer at one point or another).

Henri Beauchamp.

Heyas =)

@Formatting: You can use a collon in the beginning of every new line in order to display it as an intended line. In case you'd like to answer to an already intended comment, you can use two collons in the beginning, then three, etc. You can also sign your comments using four tildes ~~~~ (or the signature button ). These will automatically be converted into your username (with a link to your profile) and a timestamp.

OK, that sounds logical... Do you know where the rumour that mega prims would cause lag is comming from? Is there any indication for that or anything we didn't pay attention to? I think I'm going to write something like

Although there is a persistent rumour that mega prims would be a cause for lag, they can in fact be used to reduce lag. For example, by using a mega prim as a floor - instead of multiple regular prims - the number of faces which need to be drawn by the viewer can be reduced dramatically.

Additions, critics, comments?

Lynch ^{(talk|contribs)} 20:28, 12 November 2008 (UTC)

Hello,

I also saw the false argument about lag in some forum thread about mega prims. Not sure where.

As for what to write, and in order to be more precise, I would write:

Although there is a persistent rumour that mega prims would be a cause for lag, they can in fact be used to reduce lag. In large builds, by using a mega prim instead of multiple regular prims (for a wall, a floor, etc), the number of faces which need to be drawn by the viewer (or, depending on how "smart" is your graphic driver, the number of occlusions to calculate so to avoid drawing hidden faces) can be reduced dramatically.

Henri Beauchamp 08:42, 14 November 2008 (UTC)

Kewl, thx! =)

Added it to the article this way.

Lynch ^{(talk|contribs)} 09:40, 14 November 2008 (UTC)

Salt HUD

While I can see that there are many Residents who collected mega prims, I would like to mention this HUD in particular, since it actually sorted these prims. The Resident seemed to have a look at many (most?) of the available mega prim freebie boxes, renamed them and made them searchable. An example why I think that this is more useful:
A popular freebie box contains a prim that is named something like "giant pink dot". While this is indeed correct (it is a pink mega prim sphere), the name gives no indication about the dimensions of the item. That's why I think that the HUD tool is particularly useful for builders since they can request a prim with the exact right dimensions instead of having to search in incomplete collections with inconsistend naming sheme. It is not that I would want to push someones item to popularity in order to give him more sales. I don't know the creator of the HUD, never met or talked to him and it is a freebie (so no real benefit from sales). Maybe we can store both, a link to many collections and mention the HUD in particular? Would that be a compromise?
Greetz, Lynch ^{(talk|contribs)} 17:20, 11 November 2008 (UTC)

Greetings,

IMHO, it is not a good practice to make the promotion of a particular merchant on the Wiki, even by pointing to one of their free products (there is a link to "all this merchant's products" on the page you were pointing to): this is unfair towards the other merchants. That is why I replaced your link with another, pointing to search results for free mega prims on SL Exchange. Note that I don't find this solution quite satisfactory either, because then it's free promotion for SL Exchange... But to get search results, you have to use a search engine (be it a specialized engine or a generic one such as Google, Yahoo, MSN, etc, which are all commercial sites as well), so...

Another, probably better solution would simply to say on the Wiki that many free mega-prims packages are available in SL and to recommend to the user to make a search for "mega prims" and "megaprims" in the search engine of the viewer itself.

Henri Beauchamp.

Hm... that is true. So i checked the View all by this merchant link and found 3 items. A free collection of mega prims (this is the collection he's also offering via the HUD, but all items at once), the mentioned Salt HUD freebie, as well as the same Salt HUD for L$50. The L$50 version clearly states in bold letters at the bottom, that the same tool is also available for free and that this version is just thought for people who'd like to place a donation to him in that way. Besides that, he has no items for sale. Though I'm aware that this is no indication that there won't ever be other (non-free) items upcoming. But at least at the moment there are none.

I'm happy that we can more freely decide on the contents of the Wiki than for example Wikipedia can, since we don't claim to be an encyclopedia and since furthermore - in contrary to the wikimedia foundation - Linden Lab is profit orientated. So we are already pointing to contributions like the QAvimator (in a Video by Torley) or - as you well know - the Resident created alternate viewers (to just pick two products). The only difference in these software contributions and the HUD seems to be, that software is more easily uploadable on a private site and linkable at this Wiki, while the HUD needs a service like the one which is offered by SLX (or onrez etc) or an inworld location/shop. So it's not a huge difference from my point of view. The QAvimator contributors could also exploit that by pointing to their products on the download page.

For now, I tend to value the benefit higher than the possible risk.

Lynch ^{(talk|contribs)} 20:28, 12 November 2008 (UTC)

Hello,

QAvimator is free and opensource, so I don't see any problem with pointing to its website (and I could not find any link to a commercial site on QAvimator page either)... Same thing with alternate viewers. I myself provide such a viewer (the Cool SL Viewer), but as you can see when visiting my site, I don't point to any commercial site of mine either from the viewer site (I only say I'm the creator of the "Cool Products" in SL, but give no link to my SL Exchange page).

I stand my point about the mega prims: citing only one merchant (even if they don't sell a lot of things) while dozens of them provide equivalent products is simply favouring that merchant over the others, and is not the business of a Wiki such as this one. Either you should cite nobody in particular, or you should cite everyone to be fair.

As for the HUD itself... I tested it and I'm less than impressed. I mean, it's not a package of mega prims you will be able to use at any time, it's an object that calls another in-world object pertaining to the merchant in question so to get particular prims delivered on demand: what will happen when the said merchant will go off business, or when the server object will get derezed, or when the sim it is in goes down ?... The HUD simply becomes non-functional. I personally prefer packages with all the prims in them.

Henri Beauchamp 08:58, 14 November 2008 (UTC)

Yes, I know that both softwares are provided for free use - like the HUD - and that both - QAvimator and you - don't point to commercial products (maybe just ask for donations) - like the creator of the HUD too -. That is why I tried to compare these. The only difference from my point of view is, that an inworld object is more difficult to offer than a software. It is hard to link to it whithout one of the web stores. That is why I would generally pledge for linking to (free!) products which got a benefit for the community.

To the HUD itself: Hm... It might be that he has more than one backup server-prim to handle the "sim down" scenario but that's just speculation... You're right, once the server-prim is offline (due to whatever reason), the product isn't usable anymore... He is also offering his sorted library for free over there but that would then really be favouring one package over the other (although all are free and I can't really see a benefit for him since he's not actually selling anything for money). But I got doubts now...

I removed the SLX link from the article and just asked the reader to search for mega prims either inworld or in webstores. Maybe that's really the best solution... dunno.

Greetz, Lynch ^{(talk|contribs)} 09:40, 14 November 2008 (UTC)

If I may say something, I'm a bit puzzled about the wiki policy on mentioning commercial products. I mean, if I look up How to create animationsI find a whole section on Poser, and if I want to know about making sculpted prims, I can find entire pages devoted to a Sculpted Prims: 3d Software Guide and to Sculpted Prims: Resident-made Tools respectively. These last two have lots of convenient links to residents' shops, xl street pages, commercial companies' websites and all manner of things, and very useful I (and doubtless others) find them, too.

What's the difference between including links there to sculpting tools and here to a free hud? Or shouldn't the pages I mention be there in their present form?

Innula Zenovka 17:23, 22 November 2008 (UTC)

To point that out: There is no official policy on linking of commercial (or non-commercial) products in the Wiki. The only official editing guidelines we got are stored here. However, we can suggest and discuss new guidelines at Project:Editing Discussion.

At the moment, we only got different oppinions. The reason for me to remove the HUD was not that it is linked at xstreet but it was Henries argument that all HUDs are going to be useless once the server prim(s?) vanished (for whatever reason). I still think that linking useful products is a benefit although we need to take care that the Wiki isn't abused for free advertisement. That might lead into lengthy discussions at various talkpages but I think it's worth it.

Lynch ^{(talk|contribs)} 17:37, 22 November 2008 (UTC)