Difference between revisions of "Talk:Mega Prim"

From Second Life Wiki
Jump to navigation Jump to search
Line 24: Line 24:
''Not being as good as you are with Wiki formatting, I will just put this reply in italics.''
''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 prims 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)...''
''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 (600 faces instead of 6 for the 100x100 floor in my example). 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).''
''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.''
''Henri Beauchamp.''

Revision as of 03:26, 12 November 2008

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.

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)