Map2Dif Plus
by Matt Fairfax · in Game Design and Creative Issues · 07/26/2005 (2:09 am) · 65 replies
Ok, barring any unforeseen bugs, Map2Dif Plus is now considered 1.0!
Get your goodness here:
Map2Dif Plus for TGE
Map2Dif Plus for TSE ;)
For those who will want to know: Yes, the source code for this will be in TGE 1.4 RC2. I'm not sure when it will be in the TSE CVS (as soon as Brian checks it in).
Get your goodness here:
Map2Dif Plus for TGE
Map2Dif Plus for TSE ;)
For those who will want to know: Yes, the source code for this will be in TGE 1.4 RC2. I'm not sure when it will be in the TSE CVS (as soon as Brian checks it in).
About the author
I am a Game Designer at PopCap who has worked on PvZ Adventures, PvZ2, Peggle Blast, and Bejeweled Skies. I am an ex-GarageGames employee who helped ship TGE, TGEA, Torque 3D, and Constructor.
#2
In general you should never have to do more than:
07/26/2005 (2:16 am)
Just run the exe on a commandline without any options and it will give you usage information. Basically, use it the exact same as the previous version (minus a few unused options). It will also spit out a console.log file with a little bit more info...like a list of used textures (something very handy when creating materials for TSE).In general you should never have to do more than:
map2dif_plus.exe myfirst.map
#3
07/26/2005 (2:21 am)
I am interested in what's been improved and changed...
#4
* should be able to load Q1, Q2, Q3 (non-brushdef version), and Valve220 formats
* Brush validator
* tries to insure only good brushes make it into the map conversion
* better error messages
* Upped and/or removed some of map2dif's hardcoded limits
* Allowed completely enclosed interiors
* Console.log outputted for extra information and to help track issues
* Non-power of two texture error reporting (instead of crashing)
* General code cleanup and bugfixes
* No brush limits
* Upped winding limits
07/26/2005 (2:27 am)
* Improved parser* should be able to load Q1, Q2, Q3 (non-brushdef version), and Valve220 formats
* Brush validator
* tries to insure only good brushes make it into the map conversion
* better error messages
* Upped and/or removed some of map2dif's hardcoded limits
* Allowed completely enclosed interiors
* Console.log outputted for extra information and to help track issues
* Non-power of two texture error reporting (instead of crashing)
* General code cleanup and bugfixes
* No brush limits
* Upped winding limits
#5
BTW: This is kind of a neat thing I changed in Map2Dif... it allows us to make hidden clip brushes to smooth out going up/down stairs, guide players around corners, etc:
Edit: code removed, not in private forums..
I just added special collision brushes to the clipping hull.
07/26/2005 (2:34 am)
Great! Looking forward to giving it a whirl... Thanks.BTW: This is kind of a neat thing I changed in Map2Dif... it allows us to make hidden clip brushes to smooth out going up/down stairs, guide players around corners, etc:
Edit: code removed, not in private forums..
I just added special collision brushes to the clipping hull.
#6
Oh, yeah! This should open up a wider variety of editors for people now. :)
07/26/2005 (4:00 am)
"should be able to load Q1, Q2, Q3 (non-brushdef version), and Valve220 formats"Oh, yeah! This should open up a wider variety of editors for people now. :)
#7
@Josh, is there a way we can see your hidden clip brush code via a resource or private forum thread? It's a cool feature for smoothing out the camera for stairs and also to preventing the player on getting stuck to objects when walking.
Nick
07/26/2005 (7:40 am)
@Matthew, Congradulations on getting Map2Dif Plus to ver 1.0.@Josh, is there a way we can see your hidden clip brush code via a resource or private forum thread? It's a cool feature for smoothing out the camera for stairs and also to preventing the player on getting stuck to objects when walking.
Nick
#8
07/26/2005 (10:32 am)
Nice job Matt cant wait to try it out tonight
#9
It doesn't look like it, and doesn't seem useful, but is there any benefit to redoing the sample media that comes with torque?
Ex. the starter.fps difs.
Just curious.
07/26/2005 (11:56 am)
Great job on map2dif plus.It doesn't look like it, and doesn't seem useful, but is there any benefit to redoing the sample media that comes with torque?
Ex. the starter.fps difs.
Just curious.
#10
I had just figured out that not having spaces on both sides of all braces in brushes was crashing the old map2dif. This one reads every file format I generate - Quake, HL and the special torque (with the torque lights)!
I can finally add portal export and all the other entities.
Any new entities from the list currently posted for map2dif?
How do you compile multiple LOD files on the command line?
And how do you get it to search parent directories for textures?
I can still only find textures if they are in the same directory as the map file.
07/26/2005 (12:01 pm)
Finally, my app (ToolBox) can write directly to Torque!I had just figured out that not having spaces on both sides of all braces in brushes was crashing the old map2dif. This one reads every file format I generate - Quake, HL and the special torque (with the torque lights)!
I can finally add portal export and all the other entities.
Any new entities from the list currently posted for map2dif?
How do you compile multiple LOD files on the command line?
And how do you get it to search parent directories for textures?
I can still only find textures if they are in the same directory as the map file.
#11
Just specify the first file (ie myfirst_0.map) and it will find the rest and compile them in.
It does search the parent directories for the textures. This was one of the biggest things to make sure was working correctly for 1.0 and I tested it very thoroughly.
However, it does occur to me that if you're using a Quake3 format and the texture name in the .map includes a directory (like wood/woodgrain) it might have issues finding/loading it. I will take a look and make sure that I am handling that case and update map2dif plus if it needs it.
07/26/2005 (3:49 pm)
Quote:
How do you compile multiple LOD files on the command line?
And how do you get it to search parent directories for textures?
I can still only find textures if they are in the same directory as the map file.
Just specify the first file (ie myfirst_0.map) and it will find the rest and compile them in.
It does search the parent directories for the textures. This was one of the biggest things to make sure was working correctly for 1.0 and I tested it very thoroughly.
However, it does occur to me that if you're using a Quake3 format and the texture name in the .map includes a directory (like wood/woodgrain) it might have issues finding/loading it. I will take a look and make sure that I am handling that case and update map2dif plus if it needs it.
#12
I do have Material.jpg in a parent directory. I'm using 220 format files (but your new version reads my Quake output files too!)
In the file it just has Material for the texture name, but says can't find it unless I have them in the same directory. Is the map2dif location an issue?
My BIG question - tonight I hooked the new map2dif into my exporter, so when I export to Torque map format, it also converts all surfaces (textured or just colors) to jpg files, puts the map in the same directory and then runs map2dif to compile it. Works great! ToolBox to jpgs and dif in one function.
So the question is - what is the relation between geometry size and texture size? I originally setup for 3DGS (frankly, because I could understand it at the time - now I've moved my game to torque) so 1 unit equals 1 pixel and that is the basis for the on the fly uvs (originating from 0,0,0) that I currently display.
How do these relate in TGE? With a 512x512 image, what geometry size will be one repeat of the texture? I see the "geometry scale" converts down, but I can't get the texture to size right. And small settings of "light_geometry_scale" generates errors. That's the one command I don't understand in your file. I assume the default 32 / 32 are for Quark.
My editor, with a 256x256 block and texture scale of .5 .5, gives me a exact 1 repeat per side of a 512x512 texture currently (if one corner is at 0,0,0).
How are uvs calculated for dif files in TGE? (So I can change my editor to match to get WIYSIWYG texturing.)
Looking forward to finally getting my models into my game. The geometry is fine, my issue is with textures and how to export them correctly for torque.
07/26/2005 (8:00 pm)
Thanks Matt!I do have Material.jpg in a parent directory. I'm using 220 format files (but your new version reads my Quake output files too!)
In the file it just has Material for the texture name, but says can't find it unless I have them in the same directory. Is the map2dif location an issue?
My BIG question - tonight I hooked the new map2dif into my exporter, so when I export to Torque map format, it also converts all surfaces (textured or just colors) to jpg files, puts the map in the same directory and then runs map2dif to compile it. Works great! ToolBox to jpgs and dif in one function.
So the question is - what is the relation between geometry size and texture size? I originally setup for 3DGS (frankly, because I could understand it at the time - now I've moved my game to torque) so 1 unit equals 1 pixel and that is the basis for the on the fly uvs (originating from 0,0,0) that I currently display.
How do these relate in TGE? With a 512x512 image, what geometry size will be one repeat of the texture? I see the "geometry scale" converts down, but I can't get the texture to size right. And small settings of "light_geometry_scale" generates errors. That's the one command I don't understand in your file. I assume the default 32 / 32 are for Quark.
My editor, with a 256x256 block and texture scale of .5 .5, gives me a exact 1 repeat per side of a 512x512 texture currently (if one corner is at 0,0,0).
How are uvs calculated for dif files in TGE? (So I can change my editor to match to get WIYSIWYG texturing.)
Looking forward to finally getting my models into my game. The geometry is fine, my issue is with textures and how to export them correctly for torque.
#13
Thank you, thank you, thank you.. my life just got alot easier..
did i mention thank you??
07/27/2005 (1:21 pm)
@MatThank you, thank you, thank you.. my life just got alot easier..
did i mention thank you??
#14
I put the texture and the map file in data/ interiors/TestModels and ran map2dif there.
The log shows no errors and shows it loaded the texture file. (I also put a copy of the texture in
data/interiors.)
When added to a mission, I see only the grey model, no texture.
I'm using a wallblock_01.jpg from the demo to make sure the texture is OK.
Is there more to adding an interior than dropping it in the mission and re-lighting it?
(I couldn't find an answer in the forums - which by the way searching them has been very helpful, I've gotten past several problems that way so far.)
07/27/2005 (1:43 pm)
My test texture was so blurry because it is just shadows, the texture is only grey.I put the texture and the map file in data/ interiors/TestModels and ran map2dif there.
The log shows no errors and shows it loaded the texture file. (I also put a copy of the texture in
data/interiors.)
When added to a mission, I see only the grey model, no texture.
I'm using a wallblock_01.jpg from the demo to make sure the texture is OK.
Is there more to adding an interior than dropping it in the mission and re-lighting it?
(I couldn't find an answer in the forums - which by the way searching them has been very helpful, I've gotten past several problems that way so far.)
#15
I have the TGE 1.3 SDK download. Nothing I complie with map2dif_plus shows a texture, but no problem loading earlier compiled objects with textures.
I just tried swapping my texture copy for the original (in case my jpg output was making a file torque didn't like), but still no texture. The object only goes from black to grey on re-lighting.
One test object is just a cube.
{
"classname" "worldspawn"
"min_pixels" "100"
"geometry_scale" "32.0"
"light_geometry_scale" "32.0"
"ambient_color" "0 0 0"
"emergency_ambient_color" "0 0 0"
"mapversion" "220"
{
( 256.000000 256.000000 256.000000 ) ( 256.000000 0.000000 256.000000 ) ( 0.000000 0.000000 256.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 0.000000 -1.000000 0] 0.000000 0.500000 0.500000
( 0.000000 256.000000 0.000000 ) ( 0.000000 0.000000 0.000000 ) ( 256.000000 0.000000 0.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 0.000000 -1.000000 0] 0.000000 0.500000 0.500000
( 256.000000 0.000000 256.000000 ) ( 256.000000 0.000000 0.000000 ) ( 0.000000 0.000000 0.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
( 256.000000 256.000000 256.000000 ) ( 256.000000 256.000000 0.000000 ) ( 256.000000 0.000000 0.000000 ) New_Material [0.000000 0.000000 1.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
( 0.000000 256.000000 256.000000 ) ( 0.000000 256.000000 0.000000 ) ( 256.000000 256.000000 0.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
( 0.000000 0.000000 256.000000 ) ( 0.000000 0.000000 0.000000 ) ( 0.000000 256.000000 0.000000 ) New_Material [0.000000 0.000000 1.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
}
}
New_Material is a copy of Wall_Block01.
No errors in log file and it says texture loaded. Anything required missing?
07/27/2005 (6:10 pm)
Sorry about the multiple posts! I have the TGE 1.3 SDK download. Nothing I complie with map2dif_plus shows a texture, but no problem loading earlier compiled objects with textures.
I just tried swapping my texture copy for the original (in case my jpg output was making a file torque didn't like), but still no texture. The object only goes from black to grey on re-lighting.
One test object is just a cube.
{
"classname" "worldspawn"
"min_pixels" "100"
"geometry_scale" "32.0"
"light_geometry_scale" "32.0"
"ambient_color" "0 0 0"
"emergency_ambient_color" "0 0 0"
"mapversion" "220"
{
( 256.000000 256.000000 256.000000 ) ( 256.000000 0.000000 256.000000 ) ( 0.000000 0.000000 256.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 0.000000 -1.000000 0] 0.000000 0.500000 0.500000
( 0.000000 256.000000 0.000000 ) ( 0.000000 0.000000 0.000000 ) ( 256.000000 0.000000 0.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 0.000000 -1.000000 0] 0.000000 0.500000 0.500000
( 256.000000 0.000000 256.000000 ) ( 256.000000 0.000000 0.000000 ) ( 0.000000 0.000000 0.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
( 256.000000 256.000000 256.000000 ) ( 256.000000 256.000000 0.000000 ) ( 256.000000 0.000000 0.000000 ) New_Material [0.000000 0.000000 1.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
( 0.000000 256.000000 256.000000 ) ( 0.000000 256.000000 0.000000 ) ( 256.000000 256.000000 0.000000 ) New_Material [1.000000 0.000000 0.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
( 0.000000 0.000000 256.000000 ) ( 0.000000 0.000000 0.000000 ) ( 0.000000 256.000000 0.000000 ) New_Material [0.000000 0.000000 1.000000 0] [0.000000 1.000000 0.000000 0] 0.000000 0.500000 0.500000
}
}
New_Material is a copy of Wall_Block01.
No errors in log file and it says texture loaded. Anything required missing?
#16
to
07/27/2005 (9:23 pm)
Your issue is that there needs to be spaces between the to square braces and the texgen equations. Change[0.000000 0.000000 1.000000 0] [0.000000 1.000000 0.000000 0]
to
[ 0.000000 0.000000 1.000000 0] [0.000000 1.000000 0.000000 0 ]
#17
Does the new map2dif_plus require something other than the 1.3 Torque SDK?
Thanks
07/27/2005 (9:29 pm)
Tried again with the old map2dif and I get textures in the mission (with some faces with incorrect texture vectors I have to change). Does the new map2dif_plus require something other than the 1.3 Torque SDK?
Thanks
#18
I had finally figured out yesterday that not having white space there was making the old version crash (minutes before someone pointed me to your new version), but then the new one could read the files, so I assumed you had changed the parsing. I put in the spaces and I have textures now. Now I have to change the texture vectors to match the z-up pf torque (textures are rotated).
But they also match the scaling in my app, so the textures are WYSIWYG in my editor.
Great to be able to finally run map2dif from inside my app, outputing dif and jpg files directly to my torque folders so I can just export and then place in the mission to test.
Thanks for your help!
07/27/2005 (9:45 pm)
Thanks!I had finally figured out yesterday that not having white space there was making the old version crash (minutes before someone pointed me to your new version), but then the new one could read the files, so I assumed you had changed the parsing. I put in the spaces and I have textures now. Now I have to change the texture vectors to match the z-up pf torque (textures are rotated).
But they also match the scaling in my app, so the textures are WYSIWYG in my editor.
Great to be able to finally run map2dif from inside my app, outputing dif and jpg files directly to my torque folders so I can just export and then place in the mission to test.
Thanks for your help!
#19
The problem that occurs is long thin spikes, where the planes are not resolved back to the original coordinates. The more acute the angle, the longer the spike. but it occurs even on triangulated squares (45 degree angles). What is the best way to limit this issue? I've tried making sure all coordinates are integer. The original floating values create planar faces, since all points are moved the same distance in the same direction.
Is there rounding occuring in the plane calcs? And is there something I can do to minimize it?
(I know this is not the best way to make a game model, but it keeps coming up with folks using reguar 3D modelers. I want to be able to minimize the problem as much as possible.)
07/28/2005 (3:15 pm)
I'm trying to help someone import hollow triangulated meshes. I create a brush for each triangle of the mesh. It is based on the three points of the triangle, plus three points moved in along the average point normals (so each triangular 'tile' fits exactly to its neighbors, regardless of orientation). The distance along the normal (thickness of the brush) is settable by the user.The problem that occurs is long thin spikes, where the planes are not resolved back to the original coordinates. The more acute the angle, the longer the spike. but it occurs even on triangulated squares (45 degree angles). What is the best way to limit this issue? I've tried making sure all coordinates are integer. The original floating values create planar faces, since all points are moved the same distance in the same direction.
Is there rounding occuring in the plane calcs? And is there something I can do to minimize it?
(I know this is not the best way to make a game model, but it keeps coming up with folks using reguar 3D modelers. I want to be able to minimize the problem as much as possible.)
#20
Other than that, you may have to wait till the source code for this comes out and tweak it yourself. At some point down the line I'd like to allow you to specify precision but unfortunately I am completely slammed with work for the next couple of months.
07/28/2005 (4:29 pm)
There is a certain amount of rounding occuring. This helps immensly with the winding issues and bad brushes that the older map2dif struggled with but I can see how it might cause problems with what you are doing. One thing you could try is playing with the "geometry_scale" a little bit (make the mesh bigger but with a higher geometry_scale). That could go a *long* way with helping situations like this.Other than that, you may have to wait till the source code for this comes out and tweak it yourself. At some point down the line I'd like to allow you to specify precision but unfortunately I am completely slammed with work for the next couple of months.
Torque Owner Prairie Games
Prairie Games, Inc.
Edit: Cool on the source code edit :)