bzflag graphics improvements?

All things BZFlag - no [OT] here please
Post Reply
User avatar
Tux
Private First Class
Private First Class
Posts: 17
Joined: Sun Mar 20, 2005 9:07 am

bzflag graphics improvements?

Post by Tux »

Meaning no offense, but bzflag looks almost the same as 20 years ago. Computer graphics have improved a *lot* in the last 20 years, so I wonder if it would be possible to improve bzflag accordingly?
User avatar
tainn
Private First Class
Private First Class
Posts: 278
Joined: Sun Nov 18, 2018 7:25 pm
Location: phantom_zone;

Re: bzflag graphics improvements?

Post by tainn »

Can you elaborate on what could be improved?

Objects can be created using various designer programs and then exported in ways that are compatible with bz, many of which are explained in topics here on the forums. These objects can then have various materials appended to them in order to have them presented at a higher level.

You should note that bzflag is not centralized; it is an open source game where any person can create and host maps. Whether they decide that they will utilize complex approaches towards map creation or not is up to them entirely.

It is true, however, that native objects are not complex. And personally, I like that being the case. Commercial games utilize powerful game engines to create stunning cutting-edge graphics, which, ultimately, require high processing capabilities. Bzflag, on the other hand, can pride itself as a really accessible game. Not only it is cross-platform, but people with old hardware can play it totally fine. I personally never had a separate graphics card, and don't plan on getting one - am totally satisfied with the one inbuilt into my processor - and bzflag likes it, while other games nowadays would start crying.

Besides objects, I could think of 'computer graphics' also meaning lighting. I believe the lighting is done pretty well, where more detail would, again, tax the processing further. But this is just me speculating what you meant in the first place.

I believe the native objects being what they are truly reflects the positive side of bzflag; not being a complex one-sided product that commerical games offer, but rather a jumping platform from where map creators can take it any way they want.

It is a simple start that can be built upon, not a complex and limited whole. That's the essence of bzflag.
User avatar
Zehra
Private First Class
Private First Class
Posts: 915
Joined: Sun Oct 18, 2015 3:36 pm
Location: Within the BZFS API and Beyond it
Contact:

Re: bzflag graphics improvements?

Post by Zehra »

Tux wrote: Thu Feb 21, 2019 12:18 pm Meaning no offense, but bzflag looks almost the same as 20 years ago. Computer graphics have improved a *lot* in the last 20 years, so I wonder if it would be possible to improve bzflag accordingly?
Improvements could certainly be made, but it is another question if someone will do them.
Although there has been some improvements made to the graphics end of BZFlag, most are not readily noticeable.
The texturing side of things would perhaps have the largest impact as well.
I have also looked into the possibility of enhancing the Heads-Up-Display (HUD) for some interface improvements.
(If I get around to planning and testing them in the coming months that is.)
tainn wrote: Thu Feb 21, 2019 5:05 pm Objects can be created using various designer programs and then exported in ways that are compatible with bz, many of which are explained in topics here on the forums. These objects can then have various materials appended to them in order to have them presented at a higher level.
I somewhat doubt that map making is the point of this thread.
While maps do certainly affect the appearance of the game, there is a massive difference from the game itself.
tainn wrote: Thu Feb 21, 2019 5:05 pm You should note that bzflag is not centralized; it is an open source game where any person can create and host maps. Whether they decide that they will utilize complex approaches towards map creation or not is up to them entirely.
It is not the same as improving the interface of the game itself.
tainn wrote: Thu Feb 21, 2019 5:05 pm It is true, however, that native objects are not complex. And personally, I like that being the case. Commercial games utilize powerful game engines to create stunning cutting-edge graphics, which, ultimately, require high processing capabilities. Bzflag, on the other hand, can pride itself as a really accessible game. Not only it is cross-platform, but people with old hardware can play it totally fine. I personally never had a separate graphics card, and don't plan on getting one - am totally satisfied with the one inbuilt into my processor - and bzflag likes it, while other games nowadays would start crying.
For some insights into world objects, see the following thread: Box Vs Mesh
The part of a game being accessible to many, does not mean it will become popular.
Even with being easy to access, a large amount of people will not play the game, simply based on either audio or graphics.
tainn wrote: Thu Feb 21, 2019 5:05 pm Besides objects, I could think of 'computer graphics' also meaning lighting. I believe the lighting is done pretty well, where more detail would, again, tax the processing further. But this is just me speculating what you meant in the first place.
The lighting could have more options and it should not add much to the processing.
Lighting on objects could be improved and more options similar to 'emission' parameter on the '.bzw' file format could be added as well.
tainn wrote: Thu Feb 21, 2019 5:05 pm I believe the native objects being what they are truly reflects the positive side of bzflag; not being a complex one-sided product that commerical games offer, but rather a jumping platform from where map creators can take it any way they want.

It is a simple start that can be built upon, not a complex and limited whole. That's the essence of bzflag.
Nicely said overall.
Although perhaps most are looking for this game to be brought a bit more up to date.

-Zehra
Those who are critical of me, I'll likely be the same of them. ~Zehra
The decisions we make are the ones we look forward too and the ones we regret. ~Zehra
There's a difference between knowing my name and knowing me, one shows respect to my name and the other is to who I am. ~Zehra

See where I've last been active at Strayers.
Visit BZList.net for a modern HTML5 server stats site.

Click here to view the 101 Leaderboard & Score Summaries Last updated 2021-01-12 (YYYY-MM-DD)
Latest 101 thread
User avatar
Tux
Private First Class
Private First Class
Posts: 17
Joined: Sun Mar 20, 2005 9:07 am

Re: bzflag graphics improvements?

Post by Tux »

tainn wrote: Thu Feb 21, 2019 5:05 pm Can you elaborate on what could be improved?
I am not sure about the terminology, but I saw a launch trailer of Dirt Rally 2. The graphics is spectacular.
User avatar
tainn
Private First Class
Private First Class
Posts: 278
Joined: Sun Nov 18, 2018 7:25 pm
Location: phantom_zone;

Re: bzflag graphics improvements?

Post by tainn »

Dirt Rally 2.0 is using the EGO engine and is made by Codemasters which features around 400 employees; not all worked on this single entry, of course, but the point remains that they are being paid full-time for what they do.

Bzflag hosts only a few active developers, all of which work on this project in their free time for no financial gain.

I'll be honest, I would love Bzflag to look and function like Dirt Rally 2.0, but there's at least one major reason out there why this will hardly happen at our current state. We would need more good and experienced people actively working on the project to push through a complex upgrade such as this, which would be a miracle if we got at one point soon. Don't get me wrong, I am hopeful, but the situation as of right now is how it is.
User avatar
blast
General
General
Posts: 4931
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: bzflag graphics improvements?

Post by blast »

Yeah... that game also recommends having an AMD Ryzen 5 2600X or Intel Core i5-8600K paired with an AMD RX Vega 56 or nVidia GTX 1070. Complete other end of the spectrum. That isn't to say that a future version of BZFlag won't require better hardware than we currently do, but I don't foresee requirements ever being quite that far. A while back we had been discussing if we wanted to target a newer OpenGL version for BZFlag 2.6.x or 2.8.x, and it seems like it would likely be OpenGL 3.2 and OpenGL ES 3.0. GeForce 8 and AMD Radeon HD 2000 cards from around ~2007 support OpenGL 3.2.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image
User avatar
tainn
Private First Class
Private First Class
Posts: 278
Joined: Sun Nov 18, 2018 7:25 pm
Location: phantom_zone;

Re: bzflag graphics improvements?

Post by tainn »

I should note that there are players right now who do use old hardware and appreciate the game performing so well in consideration to what they can or are willing to afford.

Likewise, some map makers such as ahs3 and myself are thinking of that same matter as well, usually taking some actions to keep performance in mind, including but not limited to not drawing mountains/clouds/etc. when not necessary, be economic at the amount of sides used on objects, and so on.

Point is, if we would make the game more taxing in the future, we might consider the change be optional in the settings due to players like that existing, especially if the changes would be major enough.
User avatar
Zehra
Private First Class
Private First Class
Posts: 915
Joined: Sun Oct 18, 2015 3:36 pm
Location: Within the BZFS API and Beyond it
Contact:

Re: bzflag graphics improvements?

Post by Zehra »

If you wish to improve the appearance of the game slightly on your end, there is a couple things which can be done.
Such as replacing the default texturing on your end or if you are good with code, making a few client changes.
A couple players, such as myself, have replaced the default texturing and a few others have replaced the audio as well.

-Zehra
Those who are critical of me, I'll likely be the same of them. ~Zehra
The decisions we make are the ones we look forward too and the ones we regret. ~Zehra
There's a difference between knowing my name and knowing me, one shows respect to my name and the other is to who I am. ~Zehra

See where I've last been active at Strayers.
Visit BZList.net for a modern HTML5 server stats site.

Click here to view the 101 Leaderboard & Score Summaries Last updated 2021-01-12 (YYYY-MM-DD)
Latest 101 thread
User avatar
macsforme
General
General
Posts: 2069
Joined: Wed Mar 01, 2006 5:43 am

Re: bzflag graphics improvements?

Post by macsforme »

We have a general idea for how we would like to improve the graphics of the game. However, there are many challenges; namely: 1) the existing graphics code is based on old methodologies and is difficult to work with; 2) there are very few developers still around who are familiar with OpenGL; and 3) there are very few or no remaining skilled artists in our community interested in creating new artwork for the game.

All of these things can be done by anyone with enough research and effort, but this requires for people to be willing to develop their own knowledge and then to volunteer that knowledge and their time to help improve this game. For those who are unhappy with the current pace of development, only you have the power to change that. Otherwise, we will continue improving the game within the current abilities and motivation levels of our existing developers.
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1052
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Re: bzflag graphics improvements?

Post by optic delusion »

As I see it, here is the problem...
BZ has no problem displaying high polygon counts. That's displaying them.
It is collision detection (coldet) which greatly slows the client. Checking to see if each and every polygon has a bullet or tank hitting it is the cause of reduced frame rates.

My solution is...
Use modeltool to convert your high-poly object to pure drawinfo. Drawinfo does not interact with coldet at all.
Make a low-poly version of the same object, and use modeltool to convert that to a regular BZ map object.
Add an invisible material to the low-poly object.
Combine the low and high poly objects inside a map "define" statement.
You now have a beautiful high polygon object which displays smoothly in the client.

Using this technique, I have found there is near-zero penalty to client frame rates until the total polygon count approaches 30,000.
Using regular BZ map objects, that number is reduced to less than 8000. You can have three and a half times more eye candy with drawinfo.

Yes, it's a lot of extra steps to do, but modeltool isn't nearly as hard to use as you might think.
I'm willing to help anybody who asks, so please ask.
Take a look at my Defender game mode concept.

Thinking is not an automatic process. A man can choose to think or to let his mind stagnate, or he can choose actively to turn against his intelligence, to evade his knowledge, to subvert his reason. If he refuses to think, he courts disaster: he cannot with impunity reject his means of perceiving reality.
User avatar
blast
General
General
Posts: 4931
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: bzflag graphics improvements?

Post by blast »

I think just making the detailed mesh drivethrough would do the same thing as converting it to drawinfo.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image
User avatar
tainn
Private First Class
Private First Class
Posts: 278
Joined: Sun Nov 18, 2018 7:25 pm
Location: phantom_zone;

Re: bzflag graphics improvements?

Post by tainn »

And shootthrough, or simply passable. Assuming shots are also a part of collision detection.
User avatar
blast
General
General
Posts: 4931
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: bzflag graphics improvements?

Post by blast »

Ah, right, sorry.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1052
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Re: bzflag graphics improvements?

Post by optic delusion »

That didn't work in my tests.
Take a look at my Defender game mode concept.

Thinking is not an automatic process. A man can choose to think or to let his mind stagnate, or he can choose actively to turn against his intelligence, to evade his knowledge, to subvert his reason. If he refuses to think, he courts disaster: he cannot with impunity reject his means of perceiving reality.
User avatar
tainn
Private First Class
Private First Class
Posts: 278
Joined: Sun Nov 18, 2018 7:25 pm
Location: phantom_zone;

Re: bzflag graphics improvements?

Post by tainn »

I'll check that as well in that case, as if that doesn't work, then that's likely some redundant collision detection in place. Passable objects could just be generated as such, unless I'm missing some additional functionality they offer here.
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1052
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Re: bzflag graphics improvements?

Post by optic delusion »

I had various models of the starship enterprise at 10,000, 25,000, 40,000, and 100,000 polygons.
Take a look at my Defender game mode concept.

Thinking is not an automatic process. A man can choose to think or to let his mind stagnate, or he can choose actively to turn against his intelligence, to evade his knowledge, to subvert his reason. If he refuses to think, he courts disaster: he cannot with impunity reject his means of perceiving reality.
User avatar
ahs3
Private First Class
Private First Class
Posts: 327
Joined: Sun Mar 04, 2007 8:33 pm
Location: Press '/' to search
Contact:

Re: bzflag graphics improvements?

Post by ahs3 »

Is there any new documentation on modeltool, as this no longer works on the current version. -> https://wiki.bzflag.org/Modeltool

It will convert a object file to bzw, just will no load a diconf file.
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1052
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Re: bzflag graphics improvements?

Post by optic delusion »

if you have materials, they should be in a seoerate .mtl file.

I always like to make a copy of modeltool and put it in the same folder as the diconf, and the obj file, and the .mtl file. That way I don't have to worry about paths.

// comment lines should use this format, not #

oh... and the wiki shows a dash - in front of each command. You don't need that.



// This is a sample draw info config file
// you use them to define a complex mesh that uses more then
// one input model ( obj file ).

// all file names should be relitive to the current working dir
// and must be in double quotes (") if they contain a space

// The first option is for static geometry
// all faces and materials in the static file
// will be added as normal mesh faces to the resulting
// bzw file. They can not be animated.

// static cone.obj

// the next option is for bounding geometry
// all faces in this file will be added
// as 'invisible' faces used for collisions only
// like the static geometry, they will be done
// as standard faces, and can not be animated.

// bounding pac3.obj

// you can also give the draw info anim commands
// right here in the config
// they will simply be copied to the file
// they must be in double quotes (")
// you can have more then one, just put each on it's own
// line starting with the anim keyword
//anim "angvel .3"

// lastly you can add a list of models to be used as the LOD
// geometric representations. the first model you define as
// an LOD will be the "top" or "0" LOD, and will be used to
// compute visibility extents. LOD meshes are used for drawing
// only, and are not collideable. They will be sorted into
// openGL display lists for speed.

lod 0 face.obj

// lod 0.2 "lowerResFile.obj"

// The numeric paramater after the LOD word is the pixel distance
// used by the LOD

// Note due to how LODs work, only the material of the first face in each
// obj group will be used for all faces in that group if the OBJ is used
// as an LOD
Take a look at my Defender game mode concept.

Thinking is not an automatic process. A man can choose to think or to let his mind stagnate, or he can choose actively to turn against his intelligence, to evade his knowledge, to subvert his reason. If he refuses to think, he courts disaster: he cannot with impunity reject his means of perceiving reality.
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1052
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Re: bzflag graphics improvements?

Post by optic delusion »

Let me see if I can explain this in a way everyone can understand.

If you simply add "passable" to your object you get an object that tanks and shots don't interact with. If that's what you want, then it's fine.

If you have a high-poly object and you do want coldet interaction, now you need the invisible low-poly version of the same object.

The true power of drawinfo comes with level of detail (LOD). You can have a high-poly version of an object when a player is close enough to see the details, and a second version to display when the player is halfway across the map. ....And other tricks.

Modeltool does have the "bounding" function. This is OK for low-poly objects, but I don't see it's value for high-poly objects. You still have the exact same number of (now invisible) faces for coldet to compute. Hence you need the low-poly version as a second export. You could use the "static" function of modeltool, but I always liked to keep the two objects seperate and combine them in the .bzw file with "define"

The biggest trick I've found is to always ALWAYS build your object in the 3d editor centered on point 0 0 0.
Much much easier to move them around with shift in the group. And easy to make copies of it.
And if it's not on 0 0 0, and later you decide the whole thing needs to move a few units in any direction, you need to start over.

Actually, that's not entirely correct... If you are definitely going to have coldet use the object, center it on point 0 0, but put the bottom of the object at Z=0.
Take a look at my Defender game mode concept.

Thinking is not an automatic process. A man can choose to think or to let his mind stagnate, or he can choose actively to turn against his intelligence, to evade his knowledge, to subvert his reason. If he refuses to think, he courts disaster: he cannot with impunity reject his means of perceiving reality.
User avatar
tainn
Private First Class
Private First Class
Posts: 278
Joined: Sun Nov 18, 2018 7:25 pm
Location: phantom_zone;

Re: bzflag graphics improvements?

Post by tainn »

Either 0 0 0 as you mentioned, or -size -size 0, where size is the world size. This way, all shift values/arguments are always positive.
User avatar
Zehra
Private First Class
Private First Class
Posts: 915
Joined: Sun Oct 18, 2015 3:36 pm
Location: Within the BZFS API and Beyond it
Contact:

Re: bzflag graphics improvements?

Post by Zehra »

The insights provided in this thread would be useful for creating a readme for Modeltool, along with appropriate documentation.

-Zehra
Those who are critical of me, I'll likely be the same of them. ~Zehra
The decisions we make are the ones we look forward too and the ones we regret. ~Zehra
There's a difference between knowing my name and knowing me, one shows respect to my name and the other is to who I am. ~Zehra

See where I've last been active at Strayers.
Visit BZList.net for a modern HTML5 server stats site.

Click here to view the 101 Leaderboard & Score Summaries Last updated 2021-01-12 (YYYY-MM-DD)
Latest 101 thread
User avatar
gnu-sense
Private First Class
Private First Class
Posts: 78
Joined: Wed Nov 22, 2006 1:21 am

Re: bzflag graphics improvements?

Post by gnu-sense »

Sorry I'm late to the party, but...
I never fully understood LOD; the concept is one thing, but the execution is entirely another. But here's a question about how far it might go.

Take a tetrahedron. This has four polygons (triangles, just to be simple). Now scale the tetrahedron and place four copies, each at the corners of a tetrahedron, so that the points touch and define that as a group, That's 4*4 triangles. Do this again with the 4 tetra group, and again, etc. The number of tris increases by powers of 4: at the seventh level of group you have 16384 triangles, and at the eighth, 65536. The group definitions are deceptively short for something this nasty, which is basically a tetrahedral Sierpinski gasket. When I tried this in a bzw (quite a few years ago), I found that 6 levels was okay-ish, but 7 lagged the client every time most of the gasket swung into view (it is impressive to sit inside or under a giant Sierpinski gasket, though). Maybe I tried 8, but that number is pretty big, so I doubt it.

(I have a really old bzw file with these group definitions somewhere.)

My question: to what extent can this be improved by LOD? I'm imagining that the basic tetras might have triangle/gasket textures drawn on them to further the illusion at close ranges, and that the actual collision objects would be something around 1/2 tank-size, meaning one could probably do with six levels for a fairly large gasket. Can LOD make the far-away parts not be rendered (perhaps they would seem to disappear into the fog), so as to not lag the client? And for collision, is there any benefit to breaking up the object? Or conversely is there a penalty for grouping? That didn't seem to be the case.

Mainly, I'm curious.

gnu-sense
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5196
Joined: Fri Dec 13, 2002 4:11 am

Re: bzflag graphics improvements?

Post by JeffM »

LOD doesn't really work on that low of a polycount item. It's intended for much higher polygon counts.
A tetrahedron can not devolve any further than 4 triangles, so there is no lower level of detail that can be used.

A better example would be the tank model. The base tank model has 256 triangles in it.
With LOD you can create a 100 triangle model (remove the tread, make it more boxy) for a medium level of detail, and a super low detailed version that is just a box (8 triangles). A LOD system then uses distance from the camera to pick the model with the fewest triangles that will look "OK". When a tank is very far away from the camera, there are not a lot of pixels available for rendering details, so a tank half way across the map won't look that different at 100 triangles vs 256 triangles, so may as well render the 100 triangle version. At all the way across the map a tank may not be more than a 4 to 5 pixels wide, so it can just use a simple box model, saving even more triangles. The general idea is to figure out distances where individual triangles in the model start to be rendered as only a few pixels, and then use a model that has fewer triangles.

It is NOT an automatic system that combines polygons, and it is a lossy process. The details of a lower LOD are not the same, they are just so small that you should not be able to see the difference. It's a trade off, imperceptible detail for speed. The trade off is memory, since you have to store the geometry for all the models on the card. Due to instancing it can be a decent trade off if you don't go crazy with your number of levels. In general you balance your LODs with your other card memory needs (buffers, textures, shaders, etc...). It's a little more art than science.

For your tetra case, the only real LOD that can be done would be to LOD them down to billboarded single triangles. So as you got further away, you could construct a single triangle that matched the outline of the tetra and render that, saving you 3 triangles, but again LOD is not intended for that kind of low end reduction, it's job is to allow high detail models to be used close up.

Fog culling is another thing that is not related to LOD, it's just distance culling. The polycount of the model used for an object doesn't matter.

As for collisions, your collision volume is the same for all LODs. Collisions happen in collision/simulation space not rendering space. In general for speed you want your collision volumes to be convex, not concave. It is much better to have multiple convex collision volumes than it is to build a single complex concave volume. A lot of systems can't even do concave volumes. So if you had a mesh that was a slab with a door in it, it's much more efficient to define the collisions using 3 boxes (one on each side of the door, and one above), than it would be to use the rendering mesh for collisions. It's very fast to trivially exclude a point from 3 axis aligned boxes, it is very expensive to do triangle/point tests on the entire mesh. There is no need for the plane equation with Axis Aligned Bounding Boxes for instance. The best collision volumes are made of primitives, boxes, spheres and cylinders.

In short, LOD in the scope of BZFlag would only be useful for mesh objects, allowing high detail models to be used for cameras that are close to them, and lower detail objects when hey are further away. Tanks already support LOD in the codebase, but the polycounts are so low that there is no real speed increase on modern hardware (a few hundred triangles was a lot in 1996, not so much in 2019). LOD is useful if/when you can use it to move the polycounts outside the limit that the hardware can do.
ImageJeffM
User avatar
gnu-sense
Private First Class
Private First Class
Posts: 78
Joined: Wed Nov 22, 2006 1:21 am

Re: bzflag graphics improvements?

Post by gnu-sense »

Thanks for the detailed, interesting and informative reply.

gnu-sense
WorldOfTanks23
Private First Class
Private First Class
Posts: 70
Joined: Sat Jun 20, 2009 8:27 pm

Re: bzflag graphics improvements?

Post by WorldOfTanks23 »

I personally think there's been too much emphasis on the graphics already by way of the "effects."

The gameplay is much more important to me than the graphics. That's why I'm still playing BZFlag and not Crysis or those other impressive console games.
Post Reply