The Holodeck

Before I show the XML I am going to introduce the concept of a sub-cell grid. In order to be realistically load a scene at 60Hz the scene is transferred to from the datacentre to the Ppv via fibre optical cable. There is a certain threshold of information that can be processed at a fraction of a second so since the fastest connection speed in 2014 was about 34TBytes per second. I chose to have a volume of 1*1012 voxels to represent the information that needs to be sent down the fibre optical cable on a fraction of a second level. So I have to do some math here 8*1015/(10*1000)3 = 8,000 a personal physical volume broken down into 1Tera Voxels needs 8,000 optical cables to move data from RAM in datacentre to/from RAM in the volumetric display unit Ppv at about 60Hz. That means that each strand is capable of Tera bytes per fraction of a second. For the optical core configuration the buffer on the core will hold the thread level information shown here in XML. Where each thread has a fiber link to its own memory locations within the buffer so each thread can save its data concurrently. Force point number, solidness, x,y,z moment angles, moment magnitude Force point number, solidness, x,y,z moment angles, moment magnitude …. …. Note from above if a force point is turned off as it might not be needed to simulate a particular material then the tri-state switch connecting the thread to the buffer is turned off (dark). If the thread/force point is used then the tri-state switch can be either high or low. It is important to remember that 10 force points are dealt with per thread thus if only some are used the thread information is only the used information. Also note only changes are sent/received. For the core that deals with the sub-cell grid number 1 of the 8,000 sub-cell grid numbers the buffer there is filled with core level information. XML shown below. What I mean by core level is that each core concurrently adds its core level information to the buffer to build the sub-cell grid number packet before it is send to the Ppv number for rendering. Thread level info as before … N u,v ….. … .. I mentioned above that for the testcase scene on the main simulation node (datacentre) is 100Km by 100Km by 100Km. On this scene each Ppv can move virtually through the scene incrementing in any given direction a step equivalent to 10,000 the sub-cell grid number of voxels in any given axis. 10,000 * 10,000 * 10,000 = 1*1012 which is the number of voxels within the sub-cell grid. Getting back to the 10,000 * 20*10-6 = 0.2 meters approx. 7 7/8 inches. This happens to be about a step. So it works out very well for snapping the Ppv to the sub-cell-grid as it scrolls the datacentres scene. This could be adjusted to an integer number of sub-cell grids (0.2m) if your step is larger. The texture image is the Ppv sphere which is on all multi-user simulations in the Ppv it is automatically generated on the fly and if the sub-grid in question lies on part of the Ppv sphere the auto generated and level of detailed texture is referenced with coordinated like North, South, East ,West ,Top, Bottom and then the UV coordinates. The directions refer to the part of the voxel to be faced with the texture. Now that all of that is covered I am going to cover what happens when you load a simulation. Firstly I have the scene fragmented into sub-cell grids so it loads 1*1012 voxels of information at a time from optical storage disks and since the scene is so large the disks are RAID controlled Fig.1.17.1.3 shows the core with the RAID controlled optical disks. This is similar to the multi-user setup described above where for quick loading I chose 1 Tera Voxels as a magic number to load into the Holodecks RAM sub-cell grid at a time. Each sub-cell grid has a similar setup and the full scene is the combined efforts of the loading of each sub-cell grid concurrently thus the full scene should load in the matter of minutes.(datacentre scene 100Km by 100Km by 100Km).