After a false start or two, I was able to get some of the Gladius examples working. Tonight I hope to being understanding the pieces.
I am going to start with two files provided by the examples:
procedural-mesh.js
and procedural-material.js
. These two files are shared by the cube example I used last night as well as the camera example also provided by gladius:It's a "camera" example because the camera rotates around 360° looking out at a field of cubes:
The "procedural material" file contains a function named
proc
that describes the reddish color of the cubes: function proc( options ) {
return {
color: [1, 0.2, 0]
};
}
Similarly, the "procedural mesh" also defines a proc()
function. So it seems that the "procedural" refers to the manner in which the Gladius engine loads the data. Based how the mesh and material is reference, that would seem to be the case: engine.get(
[
// ...
{
type: engine["gladius-cubicvr"].MaterialDefinition,
url: '../assets/procedural-material.js',
load: engine.loaders.procedural,
// ...
}
],
// ...
);
Both are JSON data structure, but the mesh is calculated (the size determines the x,y,z coordinated of the cube corners). So static JSON would not suffice. Well, it might for simple examples, but not for real work. It might be possible to use templates instead of procedure functions, but that would require a loading strategy other than engine.loaders.procedural
.It is interesting that
MaterialDefinition
is stored in the "gladius-cubicvr" property of the Gladius engine. I am not quite sure what the "cubicvr" is (I'll leave that question for tomorrow), so I am not questioning it being appropriate, just interesting that the engine drives so much. Then again, I suppose that's why it's an engine.Anyhow, brilliant deductive reasoning aside, I conclude tonight by mucking with settings:
Up tomorrow, I fiddle with cubicvr and the "UV" settings in the mesh definition.
Day #406
No comments:
Post a Comment