obj-to-drawinfo converter DI_machine_beta 0.3
- optic delusion
- Special Forces
- Posts: 1054
- Joined: Sat Sep 25, 2004 2:29 pm
- Location: Planet MoFo
- Contact:
obj-to-drawinfo converter DI_machine_beta 0.3
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
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 257 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.
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.
-
- Private First Class
- Posts: 204
- Joined: Mon Jan 31, 2005 12:00 am
- Location: hiding behind box...a real Bz coward :/
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 :/ )
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 (3.51 KiB) Viewed 8452 times
-
- box.wings
- (890 Bytes) Downloaded 243 times
-
- box-bzw.png (10.27 KiB) Viewed 8452 times
-
- box-wings3D.png (2.09 KiB) Viewed 8452 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."
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:
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
- Picture 4.png (10.67 KiB) Viewed 8417 times
this signature intentionally left blank
- Spazzy McGee
- Sergeant Major
- Posts: 1405
- Joined: Mon Mar 21, 2005 4:59 pm
- Location: Planet MoFo, Sheffield Division; United Kingdom
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
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.
-
- Private First Class
- Posts: 204
- Joined: Mon Jan 31, 2005 12:00 am
- Location: hiding behind box...a real Bz coward :/
It didn't work, see my description here.Choose view > Use Two Lights
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."
- optic delusion
- Special Forces
- Posts: 1054
- Joined: Sat Sep 25, 2004 2:29 pm
- Location: Planet MoFo
- Contact:
DO NOT use 2 lights..
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.
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.
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.
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
Re: DO NOT use 2 lights..
In the script?Optic Delusion wrote:We know that texcoords are not processing correctly.
Re: DO NOT use 2 lights..
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.anomaly wrote:In the script?Optic Delusion wrote:We know that texcoords are not processing correctly.
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
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
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.
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 226 times
- optic delusion
- Special Forces
- Posts: 1054
- Joined: Sat Sep 25, 2004 2:29 pm
- Location: Planet MoFo
- Contact:
Re: DO NOT use 2 lights..
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.
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.
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
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?
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?
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.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
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
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
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.
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.
- optic delusion
- Special Forces
- Posts: 1054
- Joined: Sat Sep 25, 2004 2:29 pm
- Location: Planet MoFo
- Contact:
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/
... 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.
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.
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
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.
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.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.
Damn, I was gonna steal your code too .
- optic delusion
- Special Forces
- Posts: 1054
- Joined: Sat Sep 25, 2004 2:29 pm
- Location: Planet MoFo
- Contact:
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.
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.
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.
-
- Private First Class
- Posts: 220
- Joined: Tue Jul 26, 2005 10:32 pm
- Location: Gainesville Florida
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.
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.