Academic Co-Lab News

"LETSI, the International Federation for Learning, Education, and Training Systems Interoperability, has seen a huge international response to its July solicitation for input on the future of eLearning and the next generation of SCORM."

http://www.prweb.com/releases/2008/09/prweb1362394.htm

S1000D 4.0 has been released and now supports the development
of technical learning objects. S1000D is an international specification for technical publications.

"The new support includes a data module that structures learning content, including lesson plans, learning materials and assessments; new file name conventions that identify instructional and human performance strategies; and a new content aggregation model based on the conceptual structure of a SCORM content package."

http://www.adlnet.gov/news/articles/Index.aspx?ID=482

"The ADL Initiative is pleased to announce the ADL
Guidelines for Creating Reusable Content with SCORM 2004 is available
for public comment. The guide was developed for training development
team members, especially instructional designers, who design
SCORM-complaint e-learning and register metadata content in the ADL
Registry. The guide presents SCORM and the ADL Registry in simple,
non-technical terms and contains tips and examples of how to design and
structure e-learning content so that it can be reused."

http://www.adlnet.gov/news/articles/Index.aspx?ID=482

The deadline was extended until today, giving all the contestants a couple extra days.  We greatly needed the time to finish.
Building the tracks continued to be a difficult endeavor for us.  Having to refresh ourselves on high-school trig consumed some time.  After fighting and having to constantly convert between radians and degrees I now understand how even the government could loose their items.
We ended up having to create multiple groups of code for specific functions, instead of being able to just work with simple function calls.  This development process was tedious and tricky as any simple changes needed had to be duplicated in multiple places.
I feel fortunate that I work with some great developers.  Our Graphic Designer, Orion, in particular completely re-worked the UI today, and it looks great.  He managed to tie together a bunch of different display controls, a virtual 3d environment, and then topped it off with a great logo as he was walking out the door.
We were struggled until the last couple days on what kind of interface mechanism to use to manipulate the track height.  The problem is that computer mice are 2d, and trying to work in a 3d environment is non-intuitive.  We finally got to a good solution by strarting back at the begining (of the track).  As we looked at how to add track, it became pretty obvious that the tracks are connected (obviously).   That meant for us that the height and location of the track had a good boost, it was next to the previous.  You just had to decide if it was going to go left, right or straight.  We then had to figure out how to mange the height.  We decided on "flattening" out the 3d track and showing it from start to finish in a linear manner.  This way it is easy to see if the track is going up or down at any given point, without having to manipulate the entire world.
The next hurdle, was to determine how to edit the track.  How do you edit the middle of the track, since anything but a change in height will then end up turning the who track around.  We decided the easiest was to just delete the track from the end up to the point that you want to change.  This doesn't seem like an elegant solution, however it really does work well.
The project was good, it is complete enough for now.  Unfortunately the project didn't get to far on the requirements list from the beginning.  To finish those pieces would be fairly simplistic, we just got bogged down on the physics and geometry of the track all the way to the end.

The last couple days have had flury of work and code being written.  Unfortunately almost all of it was to fix the previous version of code. The problems have been primarily in the way the wow engine works, and our learning curve of using it.
The first problem we found was in the use of the bend class.  This class will take a papervision object and bend it on the given axis with the given amount of force.  This class does this job very well.  However we were unable to determine how it was bending the object, and therefore couldn't determine where the object would end.  This made it very hard connect multiple segments together.  We ended up have to drop the use of the bend class, and the time lost trying to get it to work.
The second problem is still being worked on, but here is the basics.  When trying to construct the track segments, we found that many times the ball would "fall through" the track.  After a bunch of time verifing that the track polygons were connected properly we still couldn't solve the issue.  This almost became a show stopper.  Fortunately we found a forum post about the normals of the polygons.  It turns out that when we check the normals, some were positive and some were negative.  After changing the sequence of the vertex's used to build the polygons we were able to manipulate the polygons so the normals would all be negative.  This fixed the straight track segments.
The curved track segments are still problem-matic, and the normals seem to flip as the curve is traversed.  This still needs some more research, and may require some runtime manipulation to fix the normals to be negative.
The last problem was performance.  The performance would just drop by a large significance with each curve that was being added.  When the bend class wouldn't work, we marked the polygon vertices with spheres.  Since there are about 20 spheres for each curve, each with 10x10 segments.  While trying to fix some other issues with the curves for the curved segments the spheres got turned off.  During the next test build the performance increase was incredible.  I guess 20x10x10 so about 2000 faces for each segment may be a little high, especially since they didn't really serve any purpose at this time, other than seeing if the curve was correct.

The last couple days have been spent on getting the track structures built.  The track that is being used will consist of 3 "wires" for the track.  This seems like a good trade off between aesthetics, and low polygon count.  There are also some "braces" that are at each end of the segments, these are made of a cube that is "bent" so the curve matches the geometry of the "wires", giving an enhanced look.
In getting the track segments into a "build" function, the track was pretty easy to build, time consuming to get all the curvature and positioning to a style that we liked, but not technically very difficult.
Getting the 4 polygons for the physics engine to match the track proved to be a little tricker.  First of all the coordinate system between wow and papervision seems to be reversed.  Second you can't attach a polygon to a wow particle (or vise-versa) so everything needs to be positioned twice.  Third, the wow particles don't have a container system (at least not that we found) like papervision does, so the calculations all need to be done by hand (back to Trigonomotry).

The SIF Association and the ADL initative officially launched the pilot utilizing SIF and SCORM.

http://www.adlnet.gov/news/articles/Index.aspx?ID=479

Today was the first time that we were able to sit down as a development team since we started.  We kept it to about a 30 minute meeting, since we are all working on other projects as well, and it limits our ability to get stuck on any one issue (if it isn't real clear in a minute or two then we can come back to it later - it is early enough that everything is flexible.)
The goal of today was to look at the specifications as we had them, and to do a little more brain storming about what this could be, and how it could be used as an actual tool
After a little discussion about the specifications about how it will work, and the technical details it became a little more apparent that we were on the right track (pun intended).  As the application is built up and a preliminary UI is put in then more discussion can be had about usability and intuitivity.
The meeting then turned to issues of educational application.  How will a learner be able to get value from "playing" the application.  We didn't come to any specific answer, but we came up with several related ideas that will become essential.  Most of the ideas and issues revolved around creating some constraints (like the amount of attempts allowed), and methods to force math and physics (like using stepper values to adjust the track height that use a step of 10, where the right value would have to be "keyed in" of 7 - so you can't just get it from trial and error, you have to calculate.)
On a technical note, we did end up switching out the Canvas3D class in Flex for a CanvasView3D class.  The Canvas3D was having difficulty actually showing the 3d objects we were using for testing.  It isn't clear if it is a branch of Papervision that is causing the problem, or the version of Canvas3D, comes with the territory of using pre-release code.

The Joint Advanced Distributed Learning Co-Laboratory has announced Implementation Fest 2008. It will take place 25-28 August 2008 in Lake Buena Vista, Florida

http://www.adlnet.gov/news/articles/Index.aspx?ID=478