Official forums for BZFlag.org

As I may actually commit some code this time around,
here's a map with 8 million triangles running at ~190fps
on a GeForce 3. Note that both radar and shadows are
enabled.

P.S. The enhancements are useless for arc/cone/sphere
type objects, and will require a preprocessing step server-
side.

wow

How does it work?

Commit! Commit! Commit!



Finally, some major graphic improvements to BZFlag! Now we can make 20 million polygon maps!

Even better, with this much free time, I suggest that we keep the maps closer to only a measly 1 million polygons, and instead use up the rest of the processing time with some particle effects like smoke, fire, etc. Jumpjets should make smoke! Map-defined smoke sources would look really cool! 3D particle Lasers... hmmm....

could you give me the map to try on my computer?

This'll be good when implemented.

Is this the same thing as the Windows optimizations in the 17+ build? Or is it something different that I NEED to get that will work on Linux?

The changes that permit more rendered polygons were just
committed. You can render 100K triangles at 100FPS on a
GeForce 3. Here are some of the other changes:

New Material Properties:

nolighting
GL lights are not taken into account while drawing.
This allows you to use dynamic colors with the effect
of emissive (glowing lights). The teleporter link material
has been modified to use 'nolighting' so that it looks the
same regardless of your point of view, and time of day.

occluder
Occluders are now explicit. This specificity makes the
occluding capability much more efficient. As well, two
separate sets of occluders are used if the mirror is
enabled.

noshadow
Much like noradar.

groupAlpha
Translucent faces with this property with be back-to-front
sorted as a group. This means that large translucent meshes
(say a 20K sphere), will take much less time to process. It
still isn't as accurate as a proper BSP split mesh would be,
be with some smart cutting, it can be reasonable.

Note

The higher polygon counts require the use of a drawInfo
object within a mesh. The utility to facilitate the generation of
stripified LODs has not yet been released.

Yipee!

But with this many polygons, maps could take forever to load. We need either a better compression algorithm, or a separate server to get the map off of. I think the latter is already implemented, but I don't remember how to do it. I think it is -cache or something.

Try before you make statements like that.

the maps are compressed, that map there takes only a couple seconds to load.

That server does use the -cache option.

The compressed world is somewhere around 1.4 MBytes.
If it wasn't for the use of grouping, it would be closer to 1GB.

The bzfs -cache option is very easy to use, and is highly
recommend for large worlds. All that is required is to be able
to host your cache file on a web server, there's even a
bzfs -cacheout option to help make the cache file server-side.

Note that compared to the default transfer mechanism, -cache
will speed up the file transfer even if the web server is being
hosted on the same machine.

So -cache points to a location (http)? And how do we get that cache? And can we use this on all maps so they load faster? Sorry if I missed anything...

hmmm skittles

Okay, I have to ask. drawInfo? What is it and how do I use it?

Also, I was blown away by rotating objects in your demo servers trepan - how in the world was this done? I downloaded the map and saw a few parameters/instructions I had never seen before - corner? extents? angvel? tristrip? lod? lengthPerPixel? dlist?

How were these generated? Will there be some sort of guide published? Am I asking enough questions? Should I ask more?

drawInfo blocks are used to pipe information to the
client that can be used with glDrawElements(), and
that can be organized to increase the rendering
efficiency (read: triangle strips). They also contain
information that can be used to build Levels of Detail
(LODs). LODs draw fewer elements for an object if
it is further away.

In addition to those features, I've also added the
ability to dynamically rotate the elements within a
drawInfo about the Z axis at the origin. The dynamic
rotation is performed before any object transformations.

DrawInfo corners relate to the elements sent to a
glDrawElements() call. A corner specifies an element
consisting of a vertex, a normal, and a texture coordinate.
If there are any vertices, normals, or texcoords within the
drawInfo block, then the corners will refer to internal data.
Otherwise, the corners will use the v/n/t data in the normal
part of the mesh block.

The dlist keyword is used to indicate that the client should
attempt to use a GL display list to render that part of the
object. dlist at the beginning of a drawInfo block indicates
that the client should try to use display lists for all members.

lengthPerPixel is used to control which LOD is rendered,
for both the main viewport and the radar. For the viewport, it is
affected by the field of view, the pixel resolution, and the distance
between the eye and the object. For the radar, it's derived
straight from the viewed distance and the number of pixels across
the radar (ex: seeing 800m world distance across with 400 pixels
gives a value of 2).

decorative indicates that you don't want older clients to see
this mesh at all. Large drawInfos can easy eat all of the memory
on older clients when used with groups. Vertices, normals, and
texcoords are replicated for each copy of a mesh in the older
clients even if no faces are specified. The is a check is bzfs to
make sure that you aren't tyring to apply 'decorative' to meshes
that might affect the physics of the game.

angvel specifies the dynamic angular velocity
(degres per second).


Quick notes:
- the drawInfo block is documented in the bzw man page
- there are 10 different drawing modes (points, lines, tris, quads, etc...)
- the extents and sphere values are automatically
calculated by bzfs if they aren't specified. They control the culling
and the back-to-front sorting of the object. There are cases when
you might need two drawInfo, but still want them sorted using the
same data.


P.S.
The figure eight animation of the ball was done using two copies
of a group definition containing a mesh that uses a drawInfo block.
It also uses two dynamic colors and a texture matrix to invert on
one side of the figure eight.

P.P.S.
There are two other new features that are related to drawInfos:
1. I added a time syncing feature so that all 2.0.4 clients will
have the same view on their screen at any given time. It's even
been lag compensated (esp. good for animated meshes).
2. Got another feature in today, matswap old new. Unlike
matref used in group instances, matswap is a one-to-one
swap. This should make managing materials for complicated
meshes a little easier.

So can you actualy "move" stuff in 2.0.2???

angvel specifies the dynamic angular velocity
(degres per second).

So this tells how fast you want to rotate persecond? and is this in 2.0.2?

BinarySpike wrote:So can you actualy "move" stuff in 2.0.2???

angvel specifies the dynamic angular velocity
(degres per second).

So this tells how fast you want to rotate persecond? and is this in 2.0.2?

Yes, but not in 2.0.2, in 2.0.5.

All 2.0.4 clients are synced? Awesome!
Are physics calculated in the rotating objects? I don't know where your demo servers are.

EDIT: Whoops, make that 2.0.5/2.0.6.

Sounds like we just might get full linear and angular movement in 2.0.4! This will be AWESOME!

Awwww, I'm looking forward to my bugfix.

Do we need latest 1.0.6 to make things spin? Also, how do you tell something to move along from one place to another. Like the ball going around the spinning hoops through that other thing, and through another hoop and back and then repeat? On trepan.bzflag.bz:5432

Punkus wrote:Do we need latest 1.0.6 to make things spin? Also, how do you tell something to move along from one place to another. Like the ball going around the spinning hoops through that other thing, and through another hoop and back and then repeat? On trepan.bzflag.bz:5432

One thing... we're in the 2.x line not 1.0.6.

Go to bzflag.org and download the latest one.

Haha, I made the same mistake yesterday, I mean 2.0.6

Punkus wrote:Haha, I made the same mistake yesterday, I mean 2.0.6

Hmmm... yes, I beleive it's in 2.0.4. This thread was made before it was released. (oh, it's 2.0.4 and not 2.0.6 )

Bumping a very old thread because it needs bumped. Very Disappointed no one has done much with this. Here is the map file. If you feel like it, load it up and see some moving BZobjects.
http://www.garrettsites.net/bzmaps/inde ... ail&id=212

I still have one question. How does it work?