Official forums for BZFlag.org

anomaly wrote:The php script is a good starting point for BZWTools to have drawInfo support. Look at modeltool v1.8.1 as well.

Unfortunately they deal with the part of the "process" I'm most familiar with. There are 5 parts to the software I'm working on:

1a Read mesh data from .bzw file and put into mesh object structures
1b Read mesh data from Blender scene and put into mesh object structures
2 Convert to strips fans etc, put into new mesh object structures

3a Write mesh data back to the bzw file in new format
3b Write mesh data in the right place in the export stream from Blender

1a is done, 1b is 1/2 done, 3a is trivial as is 3b. It's 2 that has me thinking, I'm still not convinced it should be done in an interpreted language, anyway, back to the research...

Yes, an interpreted language would be slow. Maybe too slow for the striping. However converting to tris and/or polys would still be an improvement. You could work out the stripifying later. I would like to see BZWTools have a drawInfo output option.

And for those who are interested, here is another copy of Tedius script with some minor changes that were suggested by this thread.

I've got a fairly simple recursive algorithm for stripping tris written now, it would would work better in PHP than is does now as PHP's recursion limit is much higher. If you want it I'll try and port it.

yeah that would be cool! It could be added to the di_machine.

This will make a cool website add-on someday... upload a map and it gets emailed back to you drawinfo. Written in the right language.... a little heavy on the CPU though.

Tedius says he hasn't stopped working on it, when he can.

I almost forgot... about tristripping...
Teppic and anomaly, did you take a good look here? http://www.cs.sunysb.edu/~stripe/
The more i think about it, the better it seems. It tristrips an obj format file. It tesselates a polygonal model. It runs really fast. All the info you need is on the site. All you have to do is add it's "q" output into our current script.

Actually the script already handles tristrips and continuations correctly. Unfortunately stripe does not output any material info in the .objf file. The script needs to be modified to either read the .mtl or the original .obj file to get the material info. I manually added the matref to the .bzw file produced by the script and it worked fine.

Modeltool could be modified to handle strips as well. Probably in wavefrontOBJ.cxx.

I'll try to add the code to the script unless Tedius wants to do that.

EDIT:
here is the script that will read a .objf file and output default matref. Requires the stripe program from the previous post by Optic Delusion to produce the .objf file.

I uploaded an updated version to the pastebin. It has anomaly's edits as well as support for polygons, which added another level of complexity. It will read Stripe .objf files, but I think a php tristripper would be awesome. We may have a php-bzw class by the time we're finished.

from a few posts on other forums i have read, the guy who wrote stripe will send you source if you ask him.
the website doesnt even say what language it's written in.

umm stripe is written in C. the source code is on the same page as the binary download.

It is not released under a license that is compatible with bzflag ( we use LGPL ) they do a very weak non commerical statement. It would be a very bad idea to use that code.

Striping isn't too hard, it's just walking the lists.

And here is the latest version of the dIMachine, for anyone that is still interested. Sphere and extents are calculated (check my math) and there is improved material support. Thanks Optic Delusion, anomaly, Tanner, JeffM and everyone else that has helped with the details. Let us know if the script is useful to you.

I'm liking di-machine better than modeltool. Version 5 seems seems to be almost a full realization of everything drawinfo can be. Di-machine is much slower, a model with 100,000 faces took six hours to process, but the finished product is better. It can output tristrips and trifans, quadstrips and more. Since we're aiming for as much speed boost as possible, this is preferable to the current modeltool method of listing tris, especially for complex models. Tristrips send 1/3 less data to the renderer than tris. ...took about 5 minutes for modeltool to process it.
So modeltool processes the obj much faster, but the resulting bzw runs slower in bzflag.


With either of them, the devil lies in creating an .obj that will process correctly. I have made objects that crash modeltool, so I tried di-machine on them. Di-machine doesn't crash, but when i load the bzw, bzfs does crash . So people shouldn't think that if modeltool won't export an obj, di-machine is an alternative. I believe the crash happens while processing n-gons, but my evidence is purely anecdotal.

I wish it had an option to clear the current text out of the current bzw, before exporting, instead of appending.

Optic Delusion wrote:I wish it had an option to clear the current text out of the current bzw, before exporting, instead of appending.

If you type on the command-line: instead of: it will replace your original "yourmap.bzw" instead of appending it. However, don't forget that this destroys your original yourmap.bzw irrecoverably, so use it carefully.

...unix...

one > instead of two >>. who'd have guessed?

Wow, I just became aware of a mistake in that last version. This one should be right.