Talk:Mega Prim

From Second Life Wiki
Revision as of 10:20, 11 November 2008 by Zai Lynch (talk | contribs) (two new discussions)
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)


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)