bzconehead tank /models etc..

michaelh20 · Post by **michaelh20** » Tue Mar 25, 2003 3:33 am

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

JeffM · Post by **JeffM** » Tue Mar 25, 2003 4:51 pm

Yes the lighting is done in OpenGL. No lighting can be done in the model itself since you can't know what direction the tank will be facing when you model it.

michaelh20 · Post by **michaelh20** » Wed Mar 26, 2003 1:44 am

why is it then that it appears when looking at the tank that it is shaded in some sort of way? Is this the effect of lighting or is it something simpler than that? Is this the "normals" that create this effect?

CobraA1 · Post by **CobraA1** » Wed Mar 26, 2003 4:08 am

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.

Dervish · Post by **Dervish** » Wed Mar 26, 2003 4:14 am

My major complaint for BZFlag's design...

Make the collision detection of tanks based upon a 3D box, not a flat rectangle.

hehehehe, others and I have been complaining about this for a while.

Dave · Post by **Dave** » Wed Mar 26, 2003 4:22 am

long live the flat rectangle!, it enables us to make "fake" walls, and, umm, I guess that's all

JeffM · Post by **JeffM** » Wed Mar 26, 2003 4:47 am

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.

michaelh20 · Post by **michaelh20** » Wed Mar 26, 2003 9:05 pm

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

JeffM · Post by **JeffM** » Wed Mar 26, 2003 10:37 pm

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

CobraA1 · Post by **CobraA1** » Thu Mar 27, 2003 4:40 am

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.

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.

JeffM · Post by **JeffM** » Thu Mar 27, 2003 6:12 pm

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.

Zwei · Post by **Zwei** » Thu Apr 03, 2003 3:31 am

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

JeffM · Post by **JeffM** » Thu Apr 03, 2003 6:00 pm

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.

Guest · Post by **Guest** » Fri Apr 04, 2003 1:58 pm

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