Talk:Mega Prim

From Second Life Wiki
Jump to navigation Jump to search

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... Zai signature.png Lynch (talk|contribs) 01:50, 5 September 2008 (PDT)

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


Mega Prims and Lag

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!
Zai signature.png 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 Button sig.png). 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?
Zai signature.png 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)

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, Zai signature.png 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.
Zai signature.png Lynch (talk|contribs) 20:28, 12 November 2008 (UTC)