Modifying Model import code
-
- Posts: 3
- Joined: Mon Oct 01, 2007 6:06 pm
- Location: NY
Modifying Model import code
Hey, I didn't know where to put this, so I figured I would put it in the most recently updated area. Anyways, What I am wondering is how to make it so that the wheel placements for the lightcycles are dependent on information from the .mod files, rather than being hardcoded into the program. I am very new to programming, but I know enough to know that the current hard-coded numbers can be replaced with user-defined (ie .mod-file defined) numbers. I looked through the gCycle and rModel files, and it seems like it should be easy enough to get the program to read for another variable (such n for node, in addition to "v" and "f" which it already looks for.)Anyways, thanks for putting up with me, I look forward to the completed 3.0!
-
- Posts: 3
- Joined: Mon Oct 01, 2007 6:06 pm
- Location: NY
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
That depends entirely on how much work you want to do. A quick hack would be fairly trivial, throw some settings in moviepack.cfg that specify where the files should be placed and you're pretty much done (after updating the renderer with the information, of course).
But that's a quick hack, which may or may not be accepted for 0.2.8, but in the trunk we want something more robust. Are you interested in working on something more robust, or just throwing together a quick hack? (Note that you can still do the quick hack to get a taste for the problem and to size it and to start model makers building a good collection of models for the future, the two things are not mutually exclusive)
But that's a quick hack, which may or may not be accepted for 0.2.8, but in the trunk we want something more robust. Are you interested in working on something more robust, or just throwing together a quick hack? (Note that you can still do the quick hack to get a taste for the problem and to size it and to start model makers building a good collection of models for the future, the two things are not mutually exclusive)
-
- Posts: 3
- Joined: Mon Oct 01, 2007 6:06 pm
- Location: NY
I would be interested in both the quick and involved approaches. The problem is that I have almost no programming knowledge (I get how things work, and I can quasi read it, but I don't really know how implement anything yet.) For the quick hack, does that require me modifying things in the source code, or is there a file in the game install folder I can edit? Anyways, part of my asking is simply to get the idea out. I would love to see it implemented in the next release. As far as getting a database of models going, I know edd has several nice models, some of which could be modified easily, and other people have also come up with numerous models. Anyways, thank you for the feedback
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
How's your math? That's what really matters here.
Any quick hack has to provide these things:
* The origin for the file, relative to the cycle. This is a simple mapping, where the wheel's origin (0,0,0) is placed at the coordinates you specify. This allows you to place the wheel where you want it.
* The axis of rotation. It should probably be a vector.
Then you have to implement those things in a file somewhere (I suggest moviepack.cfg), read it somehow (if you use moviepack.cfg, it's read for you automatically), and put it in the renderer. In the renderer, you'll have to basically copy and paste the existing cycle wheel rotation code into the moviepack code, and then generalize it to use the values you read. This last part is going to require some pretty good vector algebra, possibly some vector calculus, and is probably the hardest part.
That's a quick and dirty hack that gets it done in the moviepack.
To do it right, in the trunk, requires a bit more effort. The existing resource system is a little on the primitive side for adapting to a moviepack, and the rendering code for moviepacks and non-moviepack are in two separate places. You first have to combine them (possibly by hardcoding a packed default moviepack as a step). If you've already done the quick and dirty hack, the next step from there is to combine the cycle renderer so that there is one and only one renderer, and it should be the one you hacked together in the previous step.
From there, we have several options. You could proceed to implement the portion of the resource system you need to finish it, and then move on. Or you can resist that piece of work and do this:
Define an xml format that describes a moviepack. Make sure it includes everything that's currently in a moviepack, and change the name from moviepack to something else. This should be primarily visual in nature. In fact, if you ask me, there should be no audio anywhere in this file. The xml format should contain paths to files on disk that contain the actual model and texture data. Implement what I call "installing" a resource, which is really code that just takes a zipped resource and unpacks it into it's own directory. All the files needed should be in there. This is something you can't really avoid doing, no matter how badly you don't want to touch the resource system.
Now subclass tResource and load the moviepack. From here it gets a little tricky, because what the resource system should do, it doesn't, and it's a lot of work (believe me, I've taken several cracks at it already, but in my limited time I haven't managed to get anything working yet). So, if you don't want to make the resource system do that stuff, you need to come up with some way to make the moviepack available to the other classes that do rendering so they can use it, and that mechanism needs to be pretty small, lightweight, and isolated, so it can be easily revamped/removed when the rest of the resource system materializes. (There's actually two subsystems that are too primitively developed to get you the whole way there, but what I've described is a viable step in a certain amount of refactoring that's needed before the other subsystem can be developed)
So, what do you want to do? [/list]
Any quick hack has to provide these things:
* The origin for the file, relative to the cycle. This is a simple mapping, where the wheel's origin (0,0,0) is placed at the coordinates you specify. This allows you to place the wheel where you want it.
* The axis of rotation. It should probably be a vector.
Then you have to implement those things in a file somewhere (I suggest moviepack.cfg), read it somehow (if you use moviepack.cfg, it's read for you automatically), and put it in the renderer. In the renderer, you'll have to basically copy and paste the existing cycle wheel rotation code into the moviepack code, and then generalize it to use the values you read. This last part is going to require some pretty good vector algebra, possibly some vector calculus, and is probably the hardest part.
That's a quick and dirty hack that gets it done in the moviepack.
To do it right, in the trunk, requires a bit more effort. The existing resource system is a little on the primitive side for adapting to a moviepack, and the rendering code for moviepacks and non-moviepack are in two separate places. You first have to combine them (possibly by hardcoding a packed default moviepack as a step). If you've already done the quick and dirty hack, the next step from there is to combine the cycle renderer so that there is one and only one renderer, and it should be the one you hacked together in the previous step.
From there, we have several options. You could proceed to implement the portion of the resource system you need to finish it, and then move on. Or you can resist that piece of work and do this:
Define an xml format that describes a moviepack. Make sure it includes everything that's currently in a moviepack, and change the name from moviepack to something else. This should be primarily visual in nature. In fact, if you ask me, there should be no audio anywhere in this file. The xml format should contain paths to files on disk that contain the actual model and texture data. Implement what I call "installing" a resource, which is really code that just takes a zipped resource and unpacks it into it's own directory. All the files needed should be in there. This is something you can't really avoid doing, no matter how badly you don't want to touch the resource system.
Now subclass tResource and load the moviepack. From here it gets a little tricky, because what the resource system should do, it doesn't, and it's a lot of work (believe me, I've taken several cracks at it already, but in my limited time I haven't managed to get anything working yet). So, if you don't want to make the resource system do that stuff, you need to come up with some way to make the moviepack available to the other classes that do rendering so they can use it, and that mechanism needs to be pretty small, lightweight, and isolated, so it can be easily revamped/removed when the rest of the resource system materializes. (There's actually two subsystems that are too primitively developed to get you the whole way there, but what I've described is a viable step in a certain amount of refactoring that's needed before the other subsystem can be developed)
So, what do you want to do? [/list]
- wrtlprnft
- Reverse Outside Corner Grinder
- Posts: 1679
- Joined: Wed Jan 04, 2006 4:42 am
- Location: 0x08048000
- Contact:
The only somewhat complicated part there is rotating around an arbitrary axis.Lucifer wrote:In the renderer, you'll have to basically copy and paste the existing cycle wheel rotation code into the moviepack code, and then generalize it to use the values you read. This last part is going to require some pretty good vector algebra, possibly some vector calculus, and is probably the hardest part.
You could use glRotatef(angle, axis_x, axis_y, axis_z) if you had the actual angle, but the code that renders the wheels only knows the cos and sin of the angle (rotation(Rear|Front)Wheel.x and rotation(Rear|Front)Wheel.y, respectively).
Something mostly pasted together from other little projects I did:
Code: Select all
//assumes (x,y,z) is normalized
static void RotateAround(float sin_theta, float cos_theta, float x, float y, float z) {
//generate a quaternion
float factor = sin_theta < 0 ? -1 : 1;
sin_theta = sqrtf(1-cos_theta) / M_SQRT2; // = sin(theta/2)
cos_theta = sqrtf(1+cos_theta) / M_SQRT2 * factor; // = cos(theta / 2)
x *= sin_theta;
y *= sin_theta;
z *= sin_theta;
// w = cos_theta;
//convert to a matrix
float xx=2*x*x, xy=2*x*y, xz=2*x*z, xw=2*x*cos_theta,
yy=2*y*y, yz=2*y*z, yw=2*y*cos_theta,
zz=2*z*z, zw=2*z*cos_theta;
float m[16] = {1-yy-zz, xy-zw, xz+yw, 0,
xy+zw, 1-xx-zz, yz-xw, 0,
xz-yw, yz+xw, 1-xx-yy, 0,
0, 0, 0, 1};
glMultMatrixf(m);
}
glRotate2f could actually be faster because it may run on the graphics card, even though it needs at least two trig function calls.
There's no place like ::1
- philippeqc
- Long Poster - Project Developer - Sage
- Posts: 1526
- Joined: Mon Jul 12, 2004 8:55 am
- Location: Stockholm
- Contact:
Hi,earthdragon wrote:One thing I forgot, the reason for not having hardcoded attachment point is so that it is easier for people to make custom models with moving wheels. If there is a way to make the .ase models have moving parts, that would work as well.
Thanks
It is a very nice project you are taking. One think you might want to consider is to use well defined model format rather than to add to our own. This way, modelers will be able to export to a format the game understand without requiring weird plug-ins.
Again, great initiative you took to work on the animation of models!
Good luck
/ph
Canis meus id comedit.