Modifying Model import code

For developmental things relating to the graphics of the game.
Post Reply
earthdragon
Posts: 3
Joined: Mon Oct 01, 2007 6:06 pm
Location: NY

Modifying Model import code

Post by earthdragon »

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!
earthdragon
Posts: 3
Joined: Mon Oct 01, 2007 6:06 pm
Location: NY

Post by earthdragon »

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
User avatar
wrtlprnft
Reverse Outside Corner Grinder
Posts: 1679
Joined: Wed Jan 04, 2006 4:42 am
Location: 0x08048000
Contact:

Post by wrtlprnft »

I'd suggest storing an additional set of numbers inside the individual wheels' models that specify where the wheel should be located, a rotation axis and a rotation factor. That way you could abuse the wheels for other things like rotating turrets, too :)
There's no place like ::1
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

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)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
earthdragon
Posts: 3
Joined: Mon Oct 01, 2007 6:06 pm
Location: NY

Post by earthdragon »

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
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

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]
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
wrtlprnft
Reverse Outside Corner Grinder
Posts: 1679
Joined: Wed Jan 04, 2006 4:42 am
Location: 0x08048000
Contact:

Post by wrtlprnft »

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.
The only somewhat complicated part there is rotating around an arbitrary axis.

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);
}
That project had its own quaternion and matrix classes, this is mostly from the quaternion-from-angle-and-vector and the matrix-from-quaternion constructor (plus some stuff to get theta/2). You could get rid of the part that calculates theta/2 by just replacing it by sin_theta=fabs(sin_theta); and rotating the wheels by only half as much as you usually would.

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
User avatar
philippeqc
Long Poster - Project Developer - Sage
Posts: 1526
Joined: Mon Jul 12, 2004 8:55 am
Location: Stockholm
Contact:

Post by philippeqc »

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
Hi,

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.
Post Reply