Freezing Prims to Improve Rendering

This suggestions aims at improving resource retrieval and rendering efficiency, by giving the builder the chance to tag her prims as 'frozen', which guarantees non-modification, in turn giving the server a chance to apply several optimizations, which in turn may be passed to the client.

In-world, non-attached prims (and complete linksets) may be assigned a 'to-be-frozen' status, and are thereby scheduled to be frozen. As an immediate consequence, they would behave as if they were locked. However, the sim may now take this 'to-be-frozen' state as a guarantee (by the builder) that the prims wont be needing modifications for a long time, apply several optimizations (see below), and in turn freeze the prims for good. At this point, the builder would need to ask for these prims 'to-be-thawed' again, before editing is possible once more; depending on the sim load and the nature of the scheduling for optimization tasks, this could take several hours.

There are now many potential optimizations, given that the frozen prims can be considered static, persistent in-world object objects: Cache performance may be improved, BSP trees may be build and given to the client, or any other technique that other (mostly game) 3D environments use to make world rendering so darn fast compared to SL.

I want to add this as a feature to vote on, but beforehand I would like to gather constructive criticism from all of you out there, so that this concept can be improved upon and/or spelled out more explicitly before submission.


Various remarks and thoughts:

- freezing is only possible on land that you can have persistent builds on

- the scheduling of the freezing could be continous, or one big round every N hours

- thawing would be guaranteed to take place after, lets say, 8 hours

- it is unclear wether scripts would have to be frozen as well, certainly all texture, transparency, location etc functions would have to be suspended

- as long as the frozen state has not been assigned by the sim, the 'to-be-frozen' state can be released immediately

- upon sim entry, the frozen/persistent data would need to be transferred to the client, which could potentially result in a big, initial lag (depending on the cached data), but then roaming around on a mostly frozen sim should be faster.

- land could be frozen as well, but probably only by a sim owner

- to encourage freezing, frozen prims would only count half for alloted prim quota.

OK, let's explore...
Which means... either the object is in the land group or there is no autoreturn on the land? Or do you have to be a landowner?

It could be a daily thing, during one of the sweeps the Lindens do anyway... like updating the World Map.

Thawing could be immediate if the object is taken out of the world completely by deletion, return, or taking. This would invalidate the trees it was in, but that's probably better than having something in-world that you couldn't get rid of.

Why not by a landowner?

Hmm, based on my limited experience who actually builds persistent world objects, all builders that are part of the land group could freeze and thaw an object, based on the same permissions that allow editing.



Yes, exactly.


I guess this depends on the effect it would have on the optimization, but from the top of my head I would say that immediate thawing would be difficult. Also, why do you see it as a problem that you can't get rid of an object immediately? After all, that is the whole point of this freezing suggestion, to give the sim the possibility to optimize, with the downside that removal cannot be immediate.


Isn't it so that the polygons that cross the parcel boundaries are affected by both sides? Ah well, you are probably right, the majority of the land would not be affected, and thus could safely be frozen as well.

SL uses parametric mesh with static LODs (only the non-default values for the parametric equations are streamed). BSP would be less efficiant then the current method (or really, the current LOD are just very simple BSP trees). LOD is controled by camera distance to root prim or object (and prim size).

Considering this, freezing prims wouldn't actualy do anything.

Frezing objects would be a way for some kind of program to make "zones", but it would be too complicted to have SL calculate the zones so lets just ask for them to add a setting for one.

/13/91/92793/1.html

Edit: I would also ask for seting the Zone type.
"See Inside objects only"
"See Outside objects only"
"See Neither" As in origional thread.

Edit agin:
Imagine a phantom hollow sphere with an invisible texture on the inside.
You can see anything outside the sphere, but no one outside of it can see anything inside the sphere.

Many cards support the GL ARB occlusion query extension these days:

http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_occlusion_query

This extension lets you rapidly calculate which objects have been clipped from the scene using simple algorithms. For a dynamic world like SL it's probably a better route to go than a BSP tree, even though it isn't supported by my card

It would be nice if more technical Lindens (Steve, Andrew, James, etc) would participate in these technical discussions...

The slave drivers have chained them to their oars.