bzconehead tank /models etc..
-
- Private First Class
- Posts: 57
- Joined: Thu Dec 12, 2002 2:28 am
- Location: MN USA
bzconehead tank /models etc..
I've been monkeying around with the model stuff.. I did the castle blender tutorial and decided to throw the model into bzflag. So is all the lighting on the tank model also in the code (vs. in like turret.c body.c etc), like it seems to be?
http://www.visi.com/~michaelh/bzconehead.jpg
http://www.visi.com/~michaelh/bzconehead.jpg
-
- Private First Class
- Posts: 57
- Joined: Thu Dec 12, 2002 2:28 am
- Location: MN USA
- CobraA1
- Dev Monkey
- Posts: 124
- Joined: Fri Dec 06, 2002 7:19 pm
- Location: Above the Arctic Circle, below Canada: Minnesota
- Contact:
BZFlag has two options - with and without lighting.
Without lighting, the colors are pre-computed to look like there's lighting. Yes, this hardcoded.
With lighting, the lighting is calculated dynamically based on the position of the sun.
If you can work out a way to use arbitrary models in BZFlag, that would be awesome. Doing collision detection bewteen arbitrary models would be the hardest part, but if you're willing to give it a try, go ahead. Right now, tanks, cubes, and pyramids are all we've got.
Without lighting, the colors are pre-computed to look like there's lighting. Yes, this hardcoded.
With lighting, the lighting is calculated dynamically based on the position of the sun.
If you can work out a way to use arbitrary models in BZFlag, that would be awesome. Doing collision detection bewteen arbitrary models would be the hardest part, but if you're willing to give it a try, go ahead. Right now, tanks, cubes, and pyramids are all we've got.
-CobraA1
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
My avatar symbol © 2002 Jeremiah Moss. All rights reserved.
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
My avatar symbol © 2002 Jeremiah Moss. All rights reserved.
Yes it's is the normals that tell OpenGL what direction each face ( or vert on that face) is pointing. THis lets the system calculate how much light hits that face, and altering it's color. The normals must point out for this to work right. If you are puting your models in code you need to call the glNormal3f() function at least once for each face that has a difrent normal ( for flat shading ), or optimaly onece for each vert that has a difrent normal ( for smooth shading ).
CobraA1: There is also dynamic lights based on passing shots. No mater what you need normals. I have a system to replace the tanks with external model files, I'm just waiting for G2 before I put it in. I've had good long talks with Tim about how he wants to implement it. I have allready used the classes in my GM missile replacement patch, so I know they work.
Derv: Yes, but I dont think this post has anythign to do with that. That can not be changed untill a non e6 compatable version is released.
Dave: Your drive thu walls are a bug, they will be fixed in the next Non compatable release, proabalby then when pyrmaids are also made solid. A new feature will proabably be added to let the map specify if walls are shot thru and/or drive thu. This is the better solution, then the effects are explicid, not based on some magic combination of hights and scales. I have also talked to Tim about this.
CobraA1: There is also dynamic lights based on passing shots. No mater what you need normals. I have a system to replace the tanks with external model files, I'm just waiting for G2 before I put it in. I've had good long talks with Tim about how he wants to implement it. I have allready used the classes in my GM missile replacement patch, so I know they work.
Derv: Yes, but I dont think this post has anythign to do with that. That can not be changed untill a non e6 compatable version is released.
Dave: Your drive thu walls are a bug, they will be fixed in the next Non compatable release, proabalby then when pyrmaids are also made solid. A new feature will proabably be added to let the map specify if walls are shot thru and/or drive thu. This is the better solution, then the effects are explicid, not based on some magic combination of hights and scales. I have also talked to Tim about this.
JeffM
-
- Private First Class
- Posts: 57
- Joined: Thu Dec 12, 2002 2:28 am
- Location: MN USA
CobraA1 wrote:BZFlag has two options - with and without lighting.
Without lighting, the colors are pre-computed to look like there's lighting. Yes, this hardcoded.
Would this be an example of that bit of code?
Code: Select all
void TankSceneNode::TankRenderNode::renderLights()
{
static const GLfloat lights[3][6] = {
{ 1.0f, 1.0f, 1.0f, -1.53f, 0.00f, 2.1f },
{ 1.0f, 0.0f, 0.0f, 0.10f, 0.75f, 2.1f },
{ 0.0f, 1.0f, 0.0f, 0.10f, -0.75f, 2.1f }
};
sceneNode->lightsGState.setState();
glPointSize(2.0f);
glBegin(GL_POINTS);
myColor3fv(lights[0]);
glVertex3f(lights[0][3]*styleFactors[sceneNode->style][0], lights[0][4]*styleFactors[sceneNode->style][1], lights[0][5]*styleFactors[sceneNode->style][2]);
myColor3fv(lights[1]);
glVertex3f(lights[1][3]*styleFactors[sceneNode->style][0], lights[1][4]*styleFactors[sceneNode->style][1], lights[1][5]*styleFactors[sceneNode->style][2]);
myColor3fv(lights[2]);
glVertex3f(lights[2][3]*styleFactors[sceneNode->style][0], lights[2][4]*styleFactors[sceneNode->style][1], lights[2][5]*styleFactors[sceneNode->style][2]);
glEnd();
glPointSize(1.0f);
no that just draws the 3 points on top of the tank that look like running lighs ( you can tell by the GL_POINTS part of the glBegin function ), I don't think there are any precomputed lights in the code. I think when you turn lighting off it just uses the normals with a single light source, and dosn't do the dynamic lights on the world.
Just give your model nomrals and bz will compute the lighitng values ( norma shading ).
Most people run with lighting on as is. I think when you don't have lighting on
Just give your model nomrals and bz will compute the lighitng values ( norma shading ).
Most people run with lighting on as is. I think when you don't have lighting on
JeffM
- CobraA1
- Dev Monkey
- Posts: 124
- Joined: Fri Dec 06, 2002 7:19 pm
- Location: Above the Arctic Circle, below Canada: Minnesota
- Contact:
With lighting off, it uses pre-defined colors - I remember having to tweak the color of the bottom of the box manually until I got a nice-looking bottom.Patlabor221 wrote:. I think when you turn lighting off it just uses the normals with a single light source, and dosn't do the dynamic lights on the world.
-CobraA1
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
My avatar symbol © 2002 Jeremiah Moss. All rights reserved.
"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau
My avatar symbol © 2002 Jeremiah Moss. All rights reserved.
that may be for the boxes, but there are no glColor3() calls in the tank code. And that is what would be required to have hardcoded (or burned in ) lighing on a per vertex level. Looking at the current code, it uses a single light source and does normal shading. Now the light source is static when lighting is off, but but the acutal vertex colors are computed by open GL using the normals and the transformed tank position ( aka normal light model). Nothing is hardcoded in the "model", Just take a look at any of the tank c files.
Boxes and other world objects are handaled totaly difrent ,since BZ uses a face subdivision type of dynamic teselation to do it's point light sources. So those are a difrent ball of wax. World objects don't use "models" per say, since they are parmetric based on there input scale.
Tanks use normal gaurad shading for there lighting, so they need normals. The color of the tank is set external based on the team.
Boxes and other world objects are handaled totaly difrent ,since BZ uses a face subdivision type of dynamic teselation to do it's point light sources. So those are a difrent ball of wax. World objects don't use "models" per say, since they are parmetric based on there input scale.
Tanks use normal gaurad shading for there lighting, so they need normals. The color of the tank is set external based on the team.
JeffM
collision detection
Anyone ever looked at using real collision detection software in bzflag? I've used PQP in some of my programming -- pretty easy to interface with, and allows for collision detection for arbitrary models (just give it a set of triangles, and let it go). You can download it from:
http://www.cs.unc.edu/~geom/SSV/index.html
It's free for noncommercial use, and can be downloaded with only a little headache (must email the maintainers to receive the password).
http://www.cs.unc.edu/~geom/SSV/index.html
It's free for noncommercial use, and can be downloaded with only a little headache (must email the maintainers to receive the password).
I am looking at ColDet as well. It is full GPL and seems decent enough.
Tho having it do BZ style suportive collisions seems to be interesting ( but dooable ).
The bigest problem I'm seeing in my "how to put arbitrary models in maps" is geting them to work properly with BZS lighing structre.
The current map objects are dynamicly teselated as moving light sources get close to them. This is not easaly doable with arbitrary messhes ( well and still be fast ). So I am looking at other methods.
Tho having it do BZ style suportive collisions seems to be interesting ( but dooable ).
The bigest problem I'm seeing in my "how to put arbitrary models in maps" is geting them to work properly with BZS lighing structre.
The current map objects are dynamicly teselated as moving light sources get close to them. This is not easaly doable with arbitrary messhes ( well and still be fast ). So I am looking at other methods.
JeffM
wow
wow, reading all this stuff about lighting, code, pixel maps........just makes me want to give up my hardware background and plunge deeper into software.......
good job all, glad to see that someone out there is actively working on this thing....
(wish i could help, but perl/python/forth/e are as close as i get to anything similar. )
good job all, glad to see that someone out there is actively working on this thing....
(wish i could help, but perl/python/forth/e are as close as i get to anything similar. )