| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
HTTP when all objects loading are done.
|
|
As a viewer architect, I would like to understand how fast each of the components of the texture pipeline can run in isolation
|
|
|
|
range for high res.
|
|
|
|
|
|
|
|
when the camera is still
|
|
that parameter
|
|
|
|
|
|
Reviewed by Simon
|
|
|
|
|
|
|
|
summary metrics out of per-region info. Removed phase stats from avatar appearance change msg.
|
|
some changes that didn't pay of.
|
|
|
|
compression rate as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
implement setting to turn it on or off
|
|
|
|
Had a function call in last checkin that was removed before commit since I thought
it was only used in debug code. Adding it back in as its actually used.
|
|
|
|
|
|
|
|
Prevents the avatar's baked texture UUIDs sent by the server's first objectUpdate
message from being overwritten until the wearable cache results come back.
|
|
|
|
|
|
levels boundaries (test only).
|
|
|
|
|
|
|
|
|
|
|
|
Caching the mapping between baked texture hashes and UUIDs should be
able to be avoided if the initial texture data sent down is accuate.
This patch will use the first objectupdate message sent for your own
avatar to set the baked texture UUIDs for your avatar. These appear
to match the UUIDs sent from the hash lookup.
Testing needed to verify that you can successfully decloud before
the server sends you the hash lookup response, if your bakes are
cached locally.
|
|
|
|
|
|
|
|
|
|
(current, requested, full)
|
