The idea behind the technology is to search for points in the data cloud.
All the points is stored in a data file indexed according to their position in the 3D space, which is unlike the polygon based data file where in x,y,z coordinated is stored in an array.
With this in mind, the indexing used would be integer.
Let's inclose a 10,000 x 10,000 x 10,000 coordinate. This would contain up to a maximum of 1,000,000,000,000 (1 trillion of atoms ).
While the point cloud data is stored in a disk in the system indexed according to the position, so retrieving a point at a certain X,Y,Z is as simple as using the xyz values as an offset of the datafile or memory address where it is stored.
The basic rendering is to trace 1 ray for each pixel on the screen.
Each pixel has a different unit vector depending on its position from the screen's center point and the camera position and orientation. A unit vector is computed for each of the pixel on the screen.
The search process is for each pixel on the screen, do an increment for each of these vectors to their unit vector(which will give a rounded-off computed x,y,z coordinate).
This would be used to see in the data if an atom of that certain XYZ coordinate exist or not. If a point on the cloud data on that certain coordinate did exist, then that XYZ coordinate is marked for that certain pixel on the screen, else when no atom exist on that coordinate it proceeds to increment a unit vector on that certain ray until in finds one atom. (If transparency is considered, the matching atom will then be investigated to see if it is opaque or not, when opaque it stops the search, else depending on the transparency value, it searches for next atom that could haven been lying on that ray vector.
Vector getXYZatIncrement(Vector unit_vector, int increment){
Vector v = new Vector();
v.x = unit_vector.x * increment;
v.y = unit_vector.y * increment;
v.z = unit_vector.z * increment;
return v;
}
tracePixels(){
for(int u = 0; u < screen.width; u++){
for(int v = 0; v < screen.height; v++){
Vector unit_vector = get_unit_vector(u,v);
}
}
traceUnitVector(vector unit_vector){
for(int i = 0; i < FAR_PRISM_MAX_ITERATION; i++)
Vector trace_coordinate = getXYZatIncrement(unit_vector, increment)
if(hasAtom(trace_coordinate)){
//Get the detail of this atom at XYZ
}
}
boolean hasAtom(Vector coordinate){
//search in the data file
int offset = get_offset_calculation(coordinate.x, coordinate.y, coordinate.z)
//read value at offset in the large atom cloud data set
//has value return true
//else false
}
I have layed my scientific guess on what could have be their algorithm used in Euclideon's technology. These present's a lot of drawback specifically with the dynamic interaction and animation with the 3D world. This is inherent due to the fact that the data is stored in a pre-indexed data file on a disk or in a large memory chunk. Doing such animation would require a full re-indexing of the data stored in the disk. Even with the advent of SSD and huge memory capacity on video cards, moving one atom in the atom cloud data set would require a reindexing, so as to maintain index with respect to 3D point location for each atom.
The animation drawback of Euclideon's technology could be efficiently accomplished using "Transformation Map". Transformation map is an array of points containing the transformation of points in the Point Cloud Data. Points in the Point cloud data that are present in the transformation map will be an exclusion of the search on for the ray tracing. Z buffer with respect to the screen of the Point cloud will be compared to the Z buffer of the Transformation map and paint the final image on the screen.
Transformation map is stored in the RAM or in the videoRAM which is faster to access and is not likely that are as much as the point in the overall 3D Point Cloud Data.
The overall 3D point cloud data will be stored in the Hard Disk, which the total number is enormous.
Point arrangement algorithm:
* arrange the points in such a way the location is the index as well
* make the usage of storage compressed at efficient size
