Creation Date: 2003-3-15
AltSci3D Manga Director
Version 0.4.20 ChangeLog 03/15/2003 01:04 PM PST
Curved paths bugs fixed. Now when you drag and drop a cue, it
will continue to be curved with the length of the velocity
constant. It doesn't matter for Manga Director, but means a lot
for Anime Director (not yet released).
A small change in the data format which allows Anime Director (not
yet released) to work. The new attributes are not used by Manga
Director, but are required. Also, animFPS should never be 0. Set
it to 1 and let it be.
Funny how this new tag is compatible with the old tag since it
includes anim and the tag definition is open in AS3DHierarchy.
At t0, it will be at animStart. It will advance at animFPS
frames per second. At animEnd it will freeze or loop depending
on the setting of animLoop=="1"
This is all handled on the update() function of AS3DAD (which
will be released soon).
Version 0.4.19 ChangeLog 05/10/2003
A bunch of decent fixes.
Lighting works. I tried to parse an HTML color (#00FFFF) when it was actually a
4-vector of RGBA. Don't I feel silly? To get lighting correctly, you have to
mess with the <Light> tags quite a bit. It currently works, but you know how it
goes: change it and it breaks, change it back and it's completely broken. Look
in the AS3D File Format documentation "data/as3dv4r16_doc.xml" file and scroll
to the bottom to find out just how to mess around with the tags.
Field of View can be changed using keys E and R and is saved with the camera.
It is currently the x axis of the rotation vector. This makes it impossible to
change the roll rotation of the camera, but what can you do about it?
"F7: Save As XML" works.
The file is saved as "data/as3d_out.xml". This is so that you don't accidentally
overwrite the default file.
Version 0.4.18 ChangeLog 05/04/2003
Serious changes, hooray! I switched over to KDevelop 3.0 (Gideon) and a standard
automake/autoconf system. This means that installation is as easy as:
This is a _good_ thing. KDevelop seems to be a bit obtuse, but it's IDEAL UI is
better than Kate by a mile. Also, automake manager, the shortcut to make,
configure, etc makes it more functional than Kate by another mile. Not to say
that Kate doesn't have its place, but that I like KDevelop for C/C++
The second huge serious (possibly buggy) change is the use of std::vector in the
path system. I plan on using the STL extensively from now on and I also plan to
convert everything currently using inferior C code to STL C++. Why? Because STL
is better, easier, more stable, and cool. I was lost in C code and now I finally
have a system that works with STL. I changed the deletePast seriously because it
doesn't work with new vector system because the number of cues (m_iCues) changes
whereas it did not in the old array of pointers system.
4.18 will not have good documentation even though I promised it in 4.17. Perhaps
I can make the goal of good docs by 4.22. I am planning a few important changes
in 4.19 (which might be out tomorrow) like dynamic field of view, lighting, and
save XML, so check back soon.
Version 0.4.17 ChangeLog 03/15/2003 01:04 PM PST
Version 4.17 implements Tar Archive Interface Library. This means that
AS3DMD can use .tar and .tar.gz files. It cannot use .tar.bz2 files, but if
there is enough demand, I might implement it. The Tar Interface is
especially cool. You put all your files into one basket and as3dmd loads it.
This solves a major bug in that you have to call as3dmd from the directory
below the data directory. Now, no matter where you are, all you have to do
as3dmd -f data.tar.gz
In the tar file, you have an xml file. Since version 4.16, AS3D uses XML
files only. The XML format is very easy to use and is well documented
[see as3dmdv4r17.tar.gz:data/as3dmdv4r16_doc.xml]. The xml file has links to
bitmaps, pngs, and ms3d files. These files need to coincide with the file
names in the tar file.
Calling: "as3dmd" loads the tar file: "data/as3dmdv4r17.tar.gz" and the xml
file inside the tar file named "data/as3dmdv4r16.xml". The xml file is r16
because I try to keep track of what program will read what file. as3dmd-4.16
will read xml files made for as3dmd-4.17, so I don't change the xml file's
If you don't want to name you tar file "data/as3dmdv4r17.tar.gz" and your
xml file "data/as3dmdv4r16.xml", you just pass the correct names to as3dmd:
as3dmd -f mydata.tar.gz data/mydata2.xml
assuming that those two files exist. What if you don't want to use Tar
Archives? There's a good reason for this. If you want to be editing files
and seeing what they're doing immediately, you don't want to tar them
everytime. You'll want the files to be there. So there's a command for that:
as3dmd -n mydata2.xml
as3dmd --notar mydata2.xml
Doing this disallows access to any tar file, so you have to put all the
files in the relative path of the working directory.
The really cool part about the Tar Interface is: AltSci Manga _Reader_.
AltSci Manga Reader is now the first 3d medium manga. If you're able to load
it and you see Jav and EG1, you are witness to the first 3d medium manga.
What that means is that while 3d manga has been done before and Javantea's
Fate was the first real-time 3d manga, AltSci3D Manga Reader is the first
time a person has been able to view a 3d manga in it's original format: 3D.
It has an interactive camera and it loads as3d.tar.gz files. It is the same
as AS3DMD, except that it isn't an editor. It's an actual reader of mangas
written in AS3DMD. While it lacks very important things like: speech,
several boxes on the same page, etc, those things will come. When they do,
AS3D Manga Reader will be released as the first full-functional Manga
Reader. It's historical and stuff.
Also, version 4.17 will be the first version where I plan to have mild
documentation. Future versions may have pdf manuals, man files, and even
automake/autoconf files. But 4.17 will have a README that explains how to
That said, let's get on to the bugs. You will notice that using files in a directory: "as3dmd --notar mydata2.xml" instead of from a tar is about three seconds faster. I know of the bug and I am working on it. The only problem is that each time I call getFile(), requires me to read and decompress the entire file ~2.3MB. That means we have to read: 41*2.3/4=23MB of data. My Hard drive loads 23MB in 5 seconds and decompresses it in a fraction of a second. Opposed to when you load it as seperate files, it's only loading 2.3 MB. This is a serious bug and I am working on it. The library I'm using: gzstream works well except for this one small problem.
Temporary solution to the tar.gz problem: use a tar file instead. That's right. The problem is with the gz loader, so simply gunzipping the tar makes the load faster by about 5 seconds. It loads immediately. In fact, it loads as fast as the directory full of seperate files. It's advantage is that it is a single file rather than multiple files. This way, a person can work on one file rather than forty or one hundred forty.
A better (but still temporary) solution is to load the entire tar into memory. That would avoid the huge reads to the hard drive. It would probably end up using swap on most people's computers as if they aren't using it already. With 192 MB of RAM, running Linux with not too many programs, I have 63 MB in swap and 18 MB free. It's very silly. But I remember in Windows I had 100 MB in swap, mainly the files that I was using while Linux Swap is the stuff that I'm not using. So I'm happy. It's smooth, crispy, and powerful.
The best solution, which I worked on for a few hours is to implement igzstream::seekg(); The idea is that gzseek() will act exactly like seekg() and not have to read data from the hard drive. After a lot of work, I got it implemented. When I tried the function, it acted like I didn't do a seekg(). The funny thing is that when I added a cout << "lalala" << endl; to the function, it didn't show up in the program. So I believe that it is in fact, not running. Thus, perhaps more work would prove fruitful along that path.
Version 0.16 ChangeLog 03/10/03 06:22 pm
XML is good. It's done at a very high level of repeatability. I started by writing a program to parse the entire AS3D Manga Director Data File. It uses libxml2 dom. I chose that because I was unsatisfied with xerces-dom (especially strings). I was right in choosing it because it works perfectly. By using it, I have bought an amazing amount of stability. libxml complies and runs on Win32, but I seriously wonder if adding it won't make Windows users collapse in exhaust. Full documentation of the XML file can be found in as3dmdv4r16_doc.xml. Open it in a text editor (especially a syntax-coloring one like EditPlus for Windows or Kate for Linux KDE) and you can read the comments. Every tag is commented, so you shouldn't have much trouble seeing how to copy them to make your own GUI, AppInfo, AppData, Object, Path, Light, etc. I really like XML because:
- libxml2 is so very easy to use.
- XML is easy because I'm such an XML guru.
- XML is better than tab delimited text almost always.
- Stability and error checking. If you accidentally did one thing wrong in text, no forgivance. Not only would you get an error, but usually a seg fault and all kinds of crashy things. Now, if they do it wrong, it catches it before we are even started loading.
- XML allows you to add multi-purpose inline documentation. Space delimited data (even with #-style comment) is very hard to document correctly. XML is built around documentation and allows comments everywhere.
- XML is based on nesting. While linear data doesn't care about nesting, who ever uses linear data? It is a huge bonus for XML, where Tab delimited data is very hard to nest without getting weird errors. An infinite hierarchy which AltSci3D will soon have is very easy with XML, just put a tag within a tag within a tag.
- reusability is what you get with a global standard. Since XML is a global standard, any of the hundred XML parsers can easily interface with your data. You want a script that changes a certain few of your links from .ms3d files to .blend? No chance if you use space delimited. Python can read and write XML, so there you go.
- interfacing is easy with xml. Interfacing an XML file is very simple, with a very few calls one can do it completely. Space delimited data is hard to do mainly because you have to write all the code yourself.
So I've decided, XML all the way for my data files.
Version 0.15 ChangeLog 03/10/03 06:22 pm
It's probably not cool to get ahead of yourself, but I am already. I wrote
a Tar Archive Interface Static Library and I want to implement it. First I
must add XML support. I am just going to make 0.4.15 be DevIL support,
0.4.16 be tar support, and 0.4.17 be xml support. Anyway, I need a way to
get ascii and binaries from tar_iface, specifically XML, ASD, Milkshape3D
Models, Bitmaps, and PNGs. MS should be okay. I've done that before: make
it input a istream instead of ifstream and then pass an istrstream to it. A
bit of work, but I'll survive. The BMP shouldn't be too hard, same as MS3D.
PNG is another story entirely. I use the bmp2png and png2bmp interface, so
it's not straightforward as the others. Maybe I'll have to rewrite it
myself. The easiest one will be the ASD, which sadly ends its run in
0.4.15. Replace all instances of ifstream with istream and I'm done. I've
even done it before (AS3DMD 0.4.12). XML should work, period.
I've decided to use DevIL aka OpenIL Image Library. While it goes against
my philosophy of doing it myself, doing it right, it appeals to me since it
is not very easy to load png files from memory, which is the only place I
will have it if I use Tar archive files.
Version 0.14 ChangeLog 03/10/03 06:22 pm
Oops, I didn't do the ChangeLog like I should have. I'll do it later. Releasing the source on Source Forge is one huge change. CVS, also.
Version 0.13 ChangeLog 03/10/03 06:22 pm
Oops, I didn't do the ChangeLog like I should have. I'll do it later.
Version 0.12 ChangeLog 03/10/03 06:22 pm
Oops, I didn't do the ChangeLog like I should have. I'll do it later.
Version 0.11 ChangeLog 03/10/03 06:22 pm
Amazing how I keep on producing version after version, isn't it? I can't keep up this pace forever or I'd be doing a mythic man month or some such. I ported AS3D Engine (and thus Manga Director and Terrain Works) to SDL
. What do you know, it only took two hours. It was pretty cool because SDL is awesome and my code just happened to be structured very similar to the SDL tutorials out there. You know what that means, right? A Windows Port is not far away. As soon as I can install MinGW or another open source, free software, SDL compatible compiler, I'll compile it and release the source. Any changes to the functionality of AS3D? Fullscreen may or may not work. I forgot to explain before that resizing the window doesn't work. *shrug* Next version. If you're wondering why I pretty much skipped v0.10, it's because I believe that SDL is worth a major revision change. If I say that 0.10.1 is glX and 0.10.2 is SDL, I'll get strange looks. Probably even stranger than the ones I'm getting for skipping v0.10. I mean, v0.10 was the creation of the AS3D Engine and the porting of Terrain Works, that's good enough by itself. Today's Making Of JF
is good enough to link. EG4 got a really good part in JF. You don't remember him? EG1 (the leader) told him to guard the door and don't smoke. He replies: "OK." He takes out a cigarette and starts smoking. Five seconds later he's hit in the face and has his legs kicked out from under him. Jav knocks him unconscious and then duct tapes him to the ground. What a role! He'll get academy yet. I just saw him lying there on the floor and I thought it would be humorous and topical. Does guarding/trafficking an illegal assault weapons cache deserve the abuse that EG4 got? You say yes, EG4 says no.
Version 0.10.1 ChangeLog 02/14/03 10:55 pm
Small, unnoticable changes to AS3D. Almost no changes to Manga Director itself. Why is a minor revision? Because I wrote Terrain Works and found that it needed a bit of revision.
What is amazing is that I was able to write Terrain Works in 4 hours. Of course, AS3D Engine was written, the Terrain class was written, and I had a working example that took 20 hours to write. But it certainly tells me that writing programs using the AS3D Engine is going to be easy and fun. If you want to use the AS3D, checking the difference between as3dapp.cpp in Terrain Works and Manga Director is a good first step. E-mailing me
at email@example.com is a good second step. The idea that two very different programs can be made with two very similar files. One of the coolest things that I found is that by making AS3DTerrain inherit a few MilkShapeModel attributes, I could make Terrain be accepted as a model for the Hierarchy. This is a big step forward meaning you can actually add a very odd class like a plug-in. If you made an object (say a physics object) that inherited some of Hierarchy classes, you could add it to the heirarchy structure. And remember that Hierarchy is (even it's it current privimitive state) extremely flexible with room for infinite levels of subobjects, with each object having a 3D path and rotation and current matrix. My plan is to allow objects to have subobjects which at attached, for example a weapon that is a subobject of a person's arm which is a subobject of the elbow, shoulder, and finally the person. So then when they move their arm they move the weapon. Then the weapon can be controlled by a specialized object that can be fired, thrown, holstered, etc.
Version 0.10.0 ChangeLog 02/14/03 10:55 pm
It's pretty amazing how quickly I was able to make AltSci3D Engine. Version 0.10.0 of AltSci3D is equivalent to Version 0.10.0 of AltSci3D Manga Director. Why is that? Because the engine really isn't useful without some type of tutorial. In the distance future, I plan to comment my source code well enough that someone can use the Manga Director source as the basis for their program. Actually, that's my exact plan: to use my ASMD source to create two programs this weekend. If I find the AltSci3D Engine lacking in places, I can change it and the the changes will propagate back to AltSci3D Manga Director. What wonders reusable code can give us. Today I was trying to get Xine to work. It won't yet, but I found that it was quite amazing that the software is built as a library with a choice of a dozen user interfaces, all written by different people. So that's almost, kinda sorta what I want to do with AltSci3D. AS3D will be a static library and people will be able to write small programs that are very powerful using the classes and their own data.
Version 0.9.6 ChangeLog 02/14/03 10:55 pm
I started a new project in KDevelop 2.1.5 and did everything like it told me. This is something that has been bugging me for a while. So now it's pretty standard. The only thing missing is the short GPL in every page, but expect to see that soon.
Version 0.9.5 ChangeLog 02/14/03 03:00 pm
Almost invisible to the user, one bug has been fixed and one helpful argument parser class
has been added. The argument parser is very cool. I'm going to use it wherever I go because it is very flexible and easily used. Pretty much, now you can do: AS3DMD -v -v -v to get memory instead of doing AS3DMD -vvv. Not very useful, is it? Wait until there are twenty arguments like AS3DMD -xvvzf -q 8 -type ogg -type png -f data/as3dmdv4r10.asd test.tar.gz. You'll be happy that it works at all with that much crap. More likely, the final version of AS3DMD will look like "AS3DMD -vvvz -f data/as3dmdv4r10.asd test.tar.gz". The "-vvv" is verbosity as it currently is. The "-z" means it's a gzip file. "-f file.asd" picks an asd file out of the tarball file and the "test.tar.gz" is the tarball file with all data in it. Don't ask when I'm going to add tarball and gzip support or you'll see it in the next version.
My current plan for 0.10.0 is to seperate AS3D from AS3DMD. I have a 5 day weekend, so let's see. I may finish Terrain Works and Particle Works by then, too.
Version 0.9.4 ChangeLog 02/09/03 07:06 pm
I decided to implement adding cues. It works really well. Sadly, it's almost invisible to someone who doesn't know what asmd is doing. As usual, click the object you want to add a cue for and then click AddC or press "k". If you didn't select an object, you get an error in the console. Still no way to delete cues, but that's what I said about adding cues two days ago.
Version 0.9.3 ChangeLog 02/09/03 06:33 pm
A few more big changes. The camera is controlled by cues. This is an important part of ASMD, since the box is defined by the point in time, which includes your camera position. How does it work? When you click the vcr controls, the camera will move also. You can still move the camera with wasd, but when you click the vcr, it will snap to that point in the manga.
Version 0.9.2 ChangeLog 02/07/03 07:06 pm
A few usability changes. The major one is the editing tools. Clicking 1stC says that you
are going to be editing the first Cue of the selected object. The shortcut is the "i" key.
NextC ("o" key) changes the edited cue to the next cue. If click next past the end, it will
not edit. It will not loop around. That may change in the future, but not yet. The major
update is the new AddC button ("k" key). This actually adds a cue to the currently
selected object where the camera is. It will not allow you to add a cue between two
existing cues, but again, it may be in future versions. So this may make you wonder: how
do I select an object? Easy, there are three ways. The easiest is to click the name of
the object that you want to edit. There is a list of them on the far right. For example,
to edit Jav's Cues, click the "Jav" button. After you do that, be sure to click 1stC to
start editing the first cue or it will not respond (and might spit an error out at you).
The second way is to press the key that is associated with that button. The top button is
associated with the "1" key, the second button down is the "2" key, etc. The third way is
less stable. That is to click on the screen at the cue. If you move, you will see a line
is be drawn from your position to where you clicked. If it worked, you will have access
to that object and the cue that you clicked.
Important addition: Save now works. Press F7 to save over as3dv4r9.asd. If you get a good
one, _back up_! Just copy it to a new directory underneath data. Really, as3dv4r9.asd is
only a temporary file. Don't rely on it at all. What you are supposed to do when you are
actually using this at production level where an accidental erase is worth several hours,
you can simply give AS3DMD a filename to load from (and not save to). For example, my scene
1 scripts are all in a directory scene1 under data, named b15s01p##t##.asd where b15 means
book 15, s01 is Scene 1 of course, the p## is the page number and t## is the take number.
Depending on how you visualize the hierarchy of your manga, you should also have some type
of directory/file system. Then I type in "AS3DMD ./data/scene1/b15s01p01t24.asd" in the
console and it gives me the correct scene/page/take. When I'm done with the scene, I can
move the directory to another directory entirely and gzip it up. Did I mention that AS3D
files all tar and/or gzip up pretty well? You may see tar and/or gzip integrated into AS3D
in later/different versions just because it's so convenient to use a single tar.gz instead
of a couple dozen asd, ms3d, png, and bmp files.
You might notice that the Logo is different to match my change in Graphics API and
Operating System since the first three versions of AS3D. I run Slackware if you're
interested in where that pipe came from. That's one of the two mascots of Slackware (the
other is an indigo circle S). The Javantea's Fate logo and the AltSci Goggles are
actually both two 3d objects I created in my spare time. Anyway, it should just look
better. Go to http://www.slackware.com/ for info on my favorite Linux Distrobution.