Meshboxes and Performance issues.

Questions and answers about the how and why of making maps.
Post Reply
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Meshboxes and Performance issues.

Post by L4m3r »

While testing a new version of the Planet MoFo map, Darth Vader (I Died Once) and I discovered a map bug in which a tank could fall through and get stuck in a thin glass floor made from a meshbox object.Vader didn't really care for the glass floors to begin with, so they were removed for the next version and I didn't think anything more of it.

However, yesterday, I went to re-insert the glass floors into the revised map as a favor for OpticDelusion. with the changes I had already made, I *thought* that the bug wouldn't occur anymore. I was wrong...

Okay, so some background on the map. the affected area is atop four boxes oriented to make a four-way hallway with each other, like this:

Code: Select all

   | |
___| |___
___   ___
   | |
   | |
Each of these boxes has a fairly thin (0.5 in hieght) meshbox on top. This is used to texture the top of the boxes. Over the hallways are more meshboxes with a transparent texture.

Now, in testing the map, I found that on occasion I would fall into one of the meshboxes on top of the four boxes, thus ending up slightly lower, atop the box underneath. Obviously, being inside the meshbox made it hard to drive over the seams in the floor.

At the time I was using a very slow computer, and I noticed that the problem stopped when textures were turned off in the client (and thus the framerate increased). On my home PC (much better suited for the game) I don't seem to have the problem either.

So, can anyone explain this for me? I'm stumped. Is it just that slow computers like to fall through thin meshboxes? Anyone else had a similar problem?
Optimism is just a milder alternative to denial.
User avatar
BIYA
Corporal
Corporal
Posts: 891
Joined: Fri Dec 03, 2004 1:43 am
Location: Fredericksburg, Virginia
Contact:

Post by BIYA »

I hav'nt seen this bug yet but I have done some weird things with meshes like for instance on my Hide-N-Seek map I was able to sqeeze half of my tank into a crack in between 2 hills. Also on my platforms there I was able to impale my tank.
Guest

Post by Guest »

Why do you need to make a small meshbox, to go ontop of the others?
That doesn't seem to make any sense... :/
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

CannonBallGuy wrote:Why do you need to make a small meshbox, to go ontop of the others?
That doesn't seem to make any sense... :/
First, Windows BZFS is stupid and doesn't seem to recognize the "top" parameter for texturing.

Second, in other places (and in other versions o the map), these meshboxes also span gaps and float over drive-through boxes... in other words, they also provide a necessary driving surface in certain places.
Optimism is just a milder alternative to denial.
Guest

Post by Guest »

Okay. :) Gotcha. :wink:
User avatar
ClayOgre
Private First Class
Private First Class
Posts: 227
Joined: Mon Apr 18, 2005 3:17 am
Location: Southern Indiana (originally from Alaska)

Post by ClayOgre »

Why not just make mesh object boxes and code the faces you want to be drivethrough individually and leave the tops of the boxes regular?
Respectfully,
I Beg to Remain,
Cordially Yours,
Regards....

Image
dango
Private First Class
Private First Class
Posts: 1400
Joined: Sun Feb 06, 2005 5:40 pm
Location: Somewhere over there.

Post by dango »

ClayOgre wrote:Why not just make mesh object boxes and code the faces you want to be drivethrough individually and leave the tops of the boxes regular?
wha?
do you mean make the parts you need the "glass" thingy for drivethrough?
Image
User avatar
BIYA
Corporal
Corporal
Posts: 891
Joined: Fri Dec 03, 2004 1:43 am
Location: Fredericksburg, Virginia
Contact:

Post by BIYA »

He means Well my version of the way he would do it is. Go into wings make a box the way you want it. Set a certain texture to tell you want faces need to be drivethrough. Export it and replace the regular boxes with that one.

But, see clay is saying hand code it then make the faces that you want to be drivethrough.
User avatar
ClayOgre
Private First Class
Private First Class
Posts: 227
Joined: Mon Apr 18, 2005 3:17 am
Location: Southern Indiana (originally from Alaska)

one of ClayOgre's long winded and didactic pontifications

Post by ClayOgre »

Here is code for a box with all the faces except the top set to drivethrough.
One interesting feature is that since the bottom of the box is
drivethrough, you can actually jump up through it, fall back down
and land on the top face. This is LouMan's jump through the floor
trick. Since you jump up *inside* the box, from the inside the faces
don't exist, you pass right through the top face from the inside. Once
outside, it exists underneath you, so you land on it.

Also, notice the face statement in the mesh below. See where it says
"vertices n n n n"? You need at least three vertices to make a face,
you can have as many vertices as you want in a given face statement,
but you can't make shapes that are concave, i.e. a face shaped like a
rectangle/parallellogram will work, but if you take that same shape
and yer pet poodle "Fluffy", comes up and takes a bite out of it, it won't.

The vertices also have to be "co-planar". Example: You can't
have three vertices that are at ground level and one up in the air.
In addition, the order in which you specify the vertices in the
face statement determine which way the face "faces". If your
tank is to the south of the box in the code below, facing north
and looking at the "back" face, the below statment of
"vertices 7 6 2 3" make it appear to be in front of you. But if you were to change the statment to say "vertices 3 2 6 7" (the exact reverse), then
the face wouldn't be visible except from inside the box. From your
point of view, it wouldn't exist. This "order of vertices specification"
thing is what is meant by the expression "face winding".

The below mesh is completely hand coded, so there are no normals
or tex coords. (I haven't gotten into the tex coord thing, as I have
absolutely no idea what they are for). The only thing I can say
about normals is that they are a theoretical line that is perpendicular
to a face. Example: Imagine a pole sticking straight out from the
center of each face of the box. That is a normal. In Blender, normals
appear to be used to keep track of which way the faces are facing.
I had a terrible time at first with Blender because I would export my
.obj file and run it through modeltool only to discover that some of
my faces weren't there. Then I discovered the UV face select mode
in Blender (still have absolutely no idea what UV means...)and was able to
"see" my missing faces and fix the problem by flipping the normal for the
missing face so it pointed the opposite way.

You can also have a "matref" statement inside each face statement.

Here is a wireframe of the box, with the vertices labeled:

Image

The code:


options
-j
+r
end

world
size 50
end

define box

# front = north

mesh

vertex -10 10 0 # 0 lower left corner front
vertex -10 10 10 # 1 upper left corner front
vertex -10 -10 10 # 2 upper left corner rear
vertex -10 -10 0 # 3 lower left corner rear
vertex 10 10 0 # 4 lower right corner front
vertex 10 10 10 # 5 upper right corner front
vertex 10 -10 10 # 6 upper right corner rear
vertex 10 -10 0 # 7 lower right corner rear

# left side of box

face
vertices 3 2 1 0
drivethrough
endface

# front of box

face
vertices 0 1 5 4
drivethrough
endface

# right side of box

face
vertices 4 5 6 7
drivethrough
endface

# back of box

face
vertices 7 6 2 3
drivethrough
endface

# top of box
# NOT drivethrough

face
vertices 1 2 6 5
endface

# bottom of box - leave this part off to save
# a wasted face if the box is going to be on
# the ground

face
vertices 7 3 0 4
drivethrough
endface

end

enddef

# make a group of the box
# right now the box is 20 units by 20 units by 10 high
# use shift, spin and scale to put it where you want

group box
shift 0 0 5 # this puts it five units in the air
spin 45 0 0 1 # this spins it 45 degrees around the z axis
Scale .5 .5 .5 # make it 1/4 it's original size
end
Respectfully,
I Beg to Remain,
Cordially Yours,
Regards....

Image
trepan
Dev Wizard
Dev Wizard
Posts: 704
Joined: Fri Feb 21, 2003 7:50 pm

Post by trepan »

Normals are used for lighting calculations (aka lighting normals).
When a light hits an objects, its diffuse light value is based on the
angle between the incident ray and the normal on the object. In
OpenGL (without some trickery), the lighting components are
calculated at the vertices and interpolated across the rest of the
face.

UV coords (texcoords) are the X/Y type coordinates that define
how a texture is mapped to a face. Think of a blanket that has
been gridded along its edges as U and V. Throw it over a mesh,
and see which blanket coordinates touch each of the vertices on
the mesh...

The meshboxes that bzflag generates are wasteful, they use 14
triangles instead of the minimum 12 (2 x 6 faces). If you code a
meshbox (as ClayOgre did), it will actually render faster the normal
box object. I ran a test on learner's AntEscher map (~1000 boxes),
on my GeForce3 + AMD 1.53GHz + 1GB setup:

Code: Select all

standard bzflag boxes: 116 FPS
12 triangle meshboxes: 149 FPS
NOTE:
FPS rates are not linear indicators, there is overhead to consider.
My maximum FPS on an empty map is somewhere around 350 FPS.

The mesh box performance could easily be improved by grouping the
meshboxes into larger meshes, thus saving some OpenGL commands.

There are a couple of improvements coming down the pipe that
should significantly improve mesh rendering performance. If all goes
well, they should be ready for 2.0.4.

Hopefully, these improvements will be enough to keep mappers happy
until a real graphics engine is swapped into BZFlag (or whatever its
successor may be).
User avatar
ClayOgre
Private First Class
Private First Class
Posts: 227
Joined: Mon Apr 18, 2005 3:17 am
Location: Southern Indiana (originally from Alaska)

Post by ClayOgre »

So if I understand you correctly, one is actually better off coding something as a single monolithic mesh, rather than doing each individual object as its own mesh and then adding it into a map piece by piece?
Respectfully,
I Beg to Remain,
Cordially Yours,
Regards....

Image
trepan
Dev Wizard
Dev Wizard
Posts: 704
Joined: Fri Feb 21, 2003 7:50 pm

Post by trepan »

No. An octree is generated that helps cull objects that are completely
out of view. If you make one large mesh that always has some part of
it visible, then no parts of it will ever be culled. There's a fine balance
between the two. It depends on the spatial density of the polygons.

P.S. There are also occluders objects that can be used for culling. They
have recently been improved enough to be useful. As an example, let's
say you've got a 25K tri mesh in the middle of the map in a courtyard. If
you are outside the courtyard, you can't see the mesh. Occluders can be
erected around the courtyard that will keep the mesh from being rendered.
User avatar
L4m3r
Hater of Everything
Hater of Everything
Posts: 724
Joined: Tue Feb 08, 2005 5:15 am
Location: Los Angeles

Post by L4m3r »

Eh... the problem I'm having is that tanks fall through objects that aren't supposed to be drive-through. I know how to do meshes... the performance part of it stems from the fact that it doesn't seem to happen on fast machines.

A-Delusion said that when he ran it himself, if there were more than three people on the server, they would fall through much more easily.

Sure, it could all be done in mesh, but that would make it hard for most of the MoFo community to work on the map. Not to mention, BIYA already did it.
Optimism is just a milder alternative to denial.
Post Reply