obj-to-drawinfo converter DI_machine_beta 0.3

Discussion, updates, modifications, etc for the various map editors...
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1011
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

obj-to-drawinfo converter DI_machine_beta 0.3

Post by optic delusion »

It's been a long journey...

We have for your enjoyment a little php script that takes obj format files and turns them into drawinfo.bzw. I'm not gonna get scientific, (because i can't). I'll just give a few quick instructions on how to use it.

1.Make an obj file. We've been using Wings3d. It has to be a single object, not a group of several sub-objects. It helps if you UV-map the entire object, but it may not always be necessary to do so.

1a. Also export the same as a bzw, and save that for later.

2. Run the obj file through this script. It will produce a bzw file. It should be able to handle any obj you throw at it. I ran a starship model with 130,000 polygons, it took six hours to complete but the output loaded into bzfs right away.

3. Paste the materials from the wings_exported.bzw into the drawinfo.bzw

4. Load the drawinfo into bzfs.

Here is the script as it stands now. It is currently under development. we will get newer versions out as they occur, so stay on the lookout.
http://bzflag.pastebin.ca/713583
Attachments
DI_Machinephp.txt
this is a php file, converted to txt, because the forum does not accept php files. change the filetype back to php
(8.7 KiB) Downloaded 150 times
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.
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

This works really well, great job!
z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero »

I found a bug, check out these 2 screenshots:
box-drawInfo.png & box-bzw.png
The light-rendering of the surfaces of box-drawInfo.png are wrong! Cause each surface itself should have a consistent lightning, like in box-bzw.png.

I guess the script doesn't calculate the normals correctly.

Apart from this, the php-script is a really good job!

box.wings : wings3D format of the box.
box-wings3D.png : wings3D screenie
box-bzw.png : bzflag-client screenie
box-drawInfo.png : php-drawInfo-script screenie

I added box.wings, so the wings3D user can check out the bug. (If someone wants the obj. file then i will post it. Maximal 4 attachments are allowed :/ )
Attachments
Box-drawInfo.png
Box-drawInfo.png (3.51 KiB) Viewed 5743 times
box.wings
(890 Bytes) Downloaded 137 times
box-bzw.png
box-bzw.png (10.27 KiB) Viewed 5743 times
box-wings3D.png
box-wings3D.png (2.09 KiB) Viewed 5743 times
Last edited by z[h]ero on Thu Sep 27, 2007 2:26 am, edited 1 time in total.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."
User avatar
Tedius
Sergeant First Class
Sergeant First Class
Posts: 142
Joined: Tue Sep 19, 2006 6:10 pm
Contact:

Post by Tedius »

Thanks zhero for giving the script a go.

The script should export normals and texcoords correctly, and does when they are correct in the obj file. For some reason, Wings3d seemed to mess up your normals when it exported the .obj file. I don't know enough about wings to know how to fix this, or if it is possible, but when I imported the obj file back into Wings, it looked like this:
Attachments
box.obj re-imported
box.obj re-imported
Picture 4.png (10.67 KiB) Viewed 5708 times
this signature intentionally left blank
User avatar
Spazzy McGee
Sergeant Major
Sergeant Major
Posts: 1403
Joined: Mon Mar 21, 2005 4:59 pm
Location: Planet MoFo, Sheffield Division; United Kingdom

Post by Spazzy McGee »

Choose view > Use Two Lights
"Life is what happens to you while you're busy making other plans." - John Lennon
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

The script is not calculating the normals, it only gets them from the obj file. Whatever program you use to export the mesh is responsible for the normals. BZFlag will calculate the normals if they are not provided, which might be best in some cases. I have noticed that Wings3D can export some really small numbers sometimes, like -2.03425678e-19, this makes for some interesting results in BZFlag. For all practical purposes the example number should be rounded to zero.
z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero »

Choose view > Use Two Lights
It didn't work, see my description here.

I tested diffrent combinations:
If i activate "2 lights" and export to obj, and do import obj then again, the surfaces arn't consistent, too. But yes, this way the surfaces are much less inconsistent compared to "1 light" activated. (For the folks outside: U need activate "smooth shading in Wings3D, else u dont see a diffrence)
When i did run the php script with the exportet obj ("2 light activated") the inconsitence of the surface-lightning got even much more worse in the bz-client, it seemed to look exact same like Box-drawInfo.png in my post above.
It wasn't surprisingly for me that no matter if i activate 1 or 2 lights, the exported obj always is exactly same messed up. Cause the lighning settings just do visualize the model in another way, but the obj-file that contains only the physical 3D model is independent of the light settings.

(Btw, my Wings3D version is 0.98.32a, its just 3 months old.
Edit: My wings3D version is still the official latest stable release)
Last edited by z[h]ero on Fri Sep 28, 2007 4:26 pm, edited 1 time in total.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1011
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

DO NOT use 2 lights..

Post by optic delusion »

What you want to do is DON'T use 2 lights in wings. BZFlag has one sun. The normals are still messed  up whether you are using 2 lights or not, but 2-lights is never recommended for BZFlag.

There is a very complex agglomeration of things going on here. The next version is going to be a major re-write. For instance... the placement of drawinfo and dlist in the bzw will be very different, and we are hoping to add "face" definitions.
Let's hold off on the bug reports for now, the 0.3 release was just to get you used to using the script. We know that texcoords are not processing correctly.

ALSO, it was a major oversight not to mention Tedius in my original post, I said "we" several times but didn't say who "we" are. It's Tedius's script, I'm helping where I can, but I can't write php at all. Sorry about that Ted.
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.
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Re: DO NOT use 2 lights..

Post by anomaly »

Optic Delusion wrote:We know that texcoords are not processing correctly.
In the script?
User avatar
Tedius
Sergeant First Class
Sergeant First Class
Posts: 142
Joined: Tue Sep 19, 2006 6:10 pm
Contact:

Re: DO NOT use 2 lights..

Post by Tedius »

anomaly wrote:
Optic Delusion wrote:We know that texcoords are not processing correctly.
In the script?
I guess a more accurate way to put it is that texcoords have not been tested very thoroughly. They should work, but some have seemed to have trouble with it, and it might not be consistent yet. If you have a textured mesh in .obj format, we'd love to see how well it works for you.

Edit: Also, it won't create pretty default texcoords for you like bzfs does, see http://my.bzflag.org/bb/viewtopic.php?t=11518. If you want textures, you have to UV Map it yourself.
this signature intentionally left blank
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

You may have an 'off by one' bug. I noticed that the corner defs start at 1 (one) and they should start at 0 (zero), I think. All the .objs I ran did that. This would mean that you are missing the first corner definition. That might account for the texcoord issue. I could be wrong though...

EDIT:
also the order of corner defs is wrong, it is v/n/t in your code and should be v/t/n

i know its a bit presumptuous of me but here is my corrected copy of the script...
Note that this version requires normals and texcoords.
Attachments
di_machine_php.txt
(9.28 KiB) Downloaded 117 times
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1011
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Re: DO NOT use 2 lights..

Post by optic delusion »

Optic Delusion wrote:
The next version is going to be a major re-write.

Jeff has added drawinfo support to modeltool. You can get it with SVN.
There will probably be no further updates to this Drawinfo Machine.

See the new sticky post in this forum section.
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.
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

I saw that, I'm going with the Machine for now, works great! I can't get modeltool v1.8 to create a single LOD drawInfo.
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM »

anomaly
why not? the sample I made is a single, just do one lod line at 0
ImageJeffM
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

Not sure, nothing is output. Maybe I need to study the config a little better. This is what I did last:
lod 0 "/path/to/object_file.obj"

all other lines are commented out. I tried using static and bounding with the same obj file. Both, then one at a time, always using LOD line though. What am I doing wrong?
User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM »

that should work. can you ether post the file and config in the thread for the model tool, or send it to me.
ImageJeffM
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

files are in the modeltool thread. It's gotta be some bonehead mistake i'm making...
User avatar
Tedius
Sergeant First Class
Sergeant First Class
Posts: 142
Joined: Tue Sep 19, 2006 6:10 pm
Contact:

Post by Tedius »

anomaly wrote:I noticed that the corner defs start at 1 (one) and they should start at 0 (zero), I think.

also the order of corner defs is wrong, it is v/n/t in your code and should be v/t/n
The "off by one" thing should be accounted for. Obj files start at one, unlike bzw, so I add a dummy vert, normal, and texcoord in the dI-Machine so that the obj corners are correct.

As for the v/n/t thing, that is awesome that you fixed that. Presume away, my friend. Whoever put "corner v/n/t" in the wiki needs to fix his mistake. ;)
this signature intentionally left blank
User avatar
Teppic
Private First Class
Private First Class
Posts: 576
Joined: Mon Mar 07, 2005 10:00 pm
Location: The North Block

Post by Teppic »

Hmm, interesting thread, is there some kind of useful DI information embedded in a .obj file then, 'cos I can't see any kind of tri/quad strip generation in the scripts?
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

Tedius:

corner v/n/t is correct, the order in the obj file is 'f v/t/n ...'. I didn't say that quite right earlier. Also the dummy verts may have worked this time because the first index needed to be zero. However it is better to decrement the unit offset corner v/n/t values to zero offset values, 'cause they are indexes. The verts, normal, and texcoord arrays don't need to be the same length either. Btw, I thought you did an awesome job with the script, It got the job done!

Teppic:

in the .obj file the 'f v/t/n' lines contain the corners of each poly. A drawInfo does not require strips. each poly can be represented separately as tris, quads, polygons. that is the approach modeltool is taking. Otherwise stripifying would be necessary. There are algorithms on the net that will stripify a properly constructed mesh.
Last edited by anomaly on Sat Sep 29, 2007 8:17 pm, edited 1 time in total.
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1011
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Post by optic delusion »

the reason it requires the dummy verts is because the words "drawinfo" and "dlist" are too early in the generated bzw. move drawinfo to just before the first corner, and dlist can be repeated before each lod.
... at least in the version I have.

last i heard.. jeff was thinking about adding this to modeltool, for stripification.
http://www.cs.sunysb.edu/~stripe/
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.
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

Actually the dlist should be inside the lod if you want that group of polys to be in a display list by itself, otherwise the entire drawinfo will be in the same display list. Using dummy verts is not a good idea. One thing is that the list of verts, normals, texcoords is one element too long in the script. It created an initial set of dummy verts and then proceeded to scan in all the verts in the obj file. Decrementing the indexes is the way to go. Its simply a matter of unit offset vs zero offset indexing.
User avatar
Teppic
Private First Class
Private First Class
Posts: 576
Joined: Mon Mar 07, 2005 10:00 pm
Location: The North Block

Post by Teppic »

anomaly wrote:~~ A drawInfo does not require strips. each poly can be represented separately as tris, quads, polygons. that is the approach modeltool is taking. Otherwise stripifying would be necessary.
So the objective here is not to create more efficient rendering with the use of strips, just to get the added features available through DrawInfo.

Damn, I was gonna steal your code too :wink:.
User avatar
optic delusion
Special Forces
Special Forces
Posts: 1011
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Post by optic delusion »

patches welcome.

It was mostly about getting the drawinfo bzw format correct. We only had a few not-so-good examples until last week. Things have moved quite quickly since then.
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.
anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly »

I would like to see more efficient rendering. Using strips is obviously more efficient. But drawInfo does not require their use. Trepan implemented most, if not all the OGL commands for display lists. Remember that drawInfo uses display lists for rendering which are usually faster than constructs like glBegin(GL_QUADS)... anyway. I hope that modeltool will be able to make strips eventually, or use a third party app that can stripify.

Right now faster rendering and spinning are about the only benefits that drawInfo offers. Collisions need to be implemented. Then we can use drawInfo for maps that make use of meshes for game play. Mystic Valley for instance, drawInfo is great for objects that don't require collision detection like bushes and trees, etc. But not for the mesh we have to drive on! I would also like to see the angvel option moved to the matref level. Since the polys are sorted by material one could spin a part of a mesh. Like the tank turret for example. I had to do that with two meshes. I have not looked at how the code is implemented, it may not be practical (or possible).

I made a tank that drives in a 50 unit circle. You can see the tank only from outside the circular path it takes. I guess inside is the same as being inside a one sided mesh. Of course it's like a ghost tank 'cause you can drive through it, and it can move through objects. Not really very useful.

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