Game Development Reference
In-Depth Information
mi.pts[vindex].x = x;
mi.pts[vindex].y =y;
mi.pts[vindex].z = z;
//If value is relative then add base value
if (relative){
mi.pts[vindex].x += pts[vindex].x;
mi.pts[vindex].y += pts[vindex].y;
mi.pts[vindex].z += pts[vindex].z;
}
//Each vertex uses 14 bytes = 2 (index) + 4(x) + 4(y) + 4(z)
bytesread += 14;
}
//Add to morph controller
morph->AddMorph(mi, name);
delete [] oi.pts;
return TRUE;
}
The final part of the code above uses a call to a CMorph class to store
the actual read data within the morph member variable of the object class.
We will look at how this class works in the next section.
Storing a morph target
The CMorph class stores the base object vertex locations and up to MAX_
MORPH_TARGETS morph targets. Each morph target is stored inside a
'MORPHITEM' structure, which is used to access the vertex locations and
also to offer a friendly user name for a development interface and a
current blend level. The function ' AddMorph ' is used to allocate the vertex
data. The member variable 'objcount' stores the number of morph targets
that have been added. A call to ' AddMorph ' will fail if a controller has not
been created first. A controller stores the base level vertex locations and
points to the vertices that define the object, so the morph object can alter
these base vertices; this means that a morph object can deform the mesh
before any other transformations are executed. As far as the object is
concerned, the new vertex locations are as modelled. A controller is
created using the constructor shown in the code below. After a controller
is created, ' AddMorph ' ensures that new memory is allocated for existing
morph targets and one additional. The previous targets are copied to the
Search Nedrilad ::




Custom Search