PublicVR Forum

Online discussions of everything having to do with PublicVR, especially current projects, tech support, educational practice and theory. See http://publicvr.org for basic information and send questions to jeff@publicvr.org
It is currently Sat Feb 24, 2018 7:14 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: The Replication Problem
Unread postPosted: Sun Jun 22, 2008 12:21 pm 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
CaveUT functions by attaching multiple spectator views to a single player, and mapping each view to a portion of the composite display. Our key problem is replicating the state of the (virtual) world from the server to the clients at 30 frames per second, especially with respect to the user's location and facing.

This is because the networking code built into the unreal engine employs well-crafted algorithms for minimizing the required number of updates from the server to any spectators. Depending on the activity level, it appears to vary from eight to about fourteen frames per second. The attached file describes the performance testing I did with windows' "PerfMon" tool on the BNAVE. Interestingly, changing the game's "variable net speed" and LAN and NET server tic rates to high values (parameters in ut2004.ini) had not effect. You can see the results in the file attached to this note.

About one year ago, Jonathan Hagewood managed to partially fix the problem by forcing certain variables to replicate from the server at 30 frames per second. The goal was only to fix spectator view updates in the BNAVE, and it worked. For other installations, we often have view-update (screen synch) problems, but we can usually solve them by tweaking the relative speeds of the clients and the server. Not a good a good sign, unfortunately.

This and other random bad behavior elsewhere convince me that there are now race conditions in the CaveUT+UT2004 code. Perhaps other variables are not replicated at 30fps, perhpas they are still under the old regime.

Another side effect of the replication problem is trouble with the "Cross Screen Cursor" CaveUT has a special cursor which travels across the composite display like it was a single desktop. It allows the user to trigger active objects "underneath" the cursor. Actually, the code calculates a targeting vector from the focal point of the display, through the cursor, and to the first active "trigger volume" it encounters. It worked fine, until we added the partial fix to the screen replication speed. Now, we get very erratic behavior, which Jeremy can tell you about. Most likely, the targeting function is getting overrun by the screen updates.

You can see old conversations about this issue in the old forum at:
http://publicvr.org/OldForum/CaveUT_and_VRGL_Development/View%20Synchronization%20In%20CaveUT-p1.htm
http://publicvr.org/OldForum/CaveUT_and_VRGL_Development/View%20Synchronization%20In%20CaveUT-p2.htm
http://publicvr.org/OldForum/CaveUT_and_VRGL_Development/Cross-Screen%20Cursor%20Random%20Freeze%20problem.html


Attachments:
NetPerfUT.zip [124.11 KiB]
Downloaded 418 times
Top
 Profile  
 
Unread postPosted: Mon Jun 23, 2008 8:39 am 
Offline

Joined: Mon Jun 02, 2008 6:47 pm
Posts: 15
Talking points for Virtual Heroes
--------------------------------------------

1.) Cross screen cursor doesn't always work (function replication seems to fix problem)
2.) Replication
a) Player
b) Spectator
c) Logs
3.) Non working levels
4.) Client Connect Problem
5.) Cave Cursor flooding Spectator with information (Pause function)
6.) Odd behavior in copying non working map to a working map


Top
 Profile  
 
Unread postPosted: Mon Jun 23, 2008 1:47 pm 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
Here is the latest CaveUT code drop, version 255 from our SVN server.
Attachment:
CaveUT-v255.zip [764.86 KiB]
Downloaded 464 times

The CaveUT main site is at http://publicvr.org/ut/CaveUT.html It is very out of date, but still provides "the big picture."

Also, this CaveUT distribution contains a DLL, opengl32.dll, which is actually VRGL, our hacked OGL library upon which CaveUT depends. Many of the parameters for CaveUT.ini are actually for VRGL. I don't think you will need to access the VRGL source code, but just in case, here it is:
Attachment:
VRGL-v255.zip [788.12 KiB]
Downloaded 476 times


Top
 Profile  
 
Unread postPosted: Wed Jul 02, 2008 1:56 pm 
Offline

Joined: Mon Jun 02, 2008 6:47 pm
Posts: 15
As I mentioned to Jeff in an email:

CaveUT version 256 contains some excess debugging code and a few functions specific to NatickLabs. More specifically: There is a line in CaveCursor::Tick(double dt) that reads: if(S.bInitd && time > 20). Just remove this line completely. It won't cause any harm but it will hold up the CaveCursor from sending cross screen cursor information to the clients.

The rest of the debugging code is a bunch of global variables in the Spectator class that are used in the CaveCursor class to write debugging information to the screen.

I've uploaded the removal of this excess to the new subversion location:
url: http://www.daksystems.net/publicvr

The login information (IE: usernames and passwords) for this svn location is the same as the older deep.publicvr.org. Also note that this is an http:// protocol, not svn://


Top
 Profile  
 
Unread postPosted: Thu Jul 03, 2008 10:08 am 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
Our entire SVN repository is now at its temporary location. See:
http://forum.publicvr.info/viewtopic.php?p=47#p47
for details.


Top
 Profile  
 
Unread postPosted: Tue Jul 29, 2008 11:15 pm 
Offline

Joined: Tue May 27, 2008 11:29 pm
Posts: 558
Early indications are that Max's new code solves most of the replication problem! Obviously, we will need to test this a whole lot.

Also, thanks to Jeremy, our SVN repository is is back in its permanent location, HTTP://deep.planetjeff.net
See:
viewtopic.php?p=51#p51


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group