It’s hard to define what people use more. I know that GTKRadiant is very popular in Quake related community. GTKRadiant based on QERadiant, editor that was used to create original maps and mission packs for all Quake engine based games.
I would say Blender->.map->GTKRadiant (I wonder why .map for GTKr would be different from .map for QuArK ?). I think what ever opens in GTKRadiant, should open in QuArK, since .map created in GTKr is basically original format, format that iD Software designed.
It’s been tested, everything works good so far When I will start making levels, then I would say it will be time for full blown QA
I think with minor additions it’s ready to go to CVS. It exports brushes, patches, lights, “caulk” texture. What I am trying to do is to make a .blend file with grid matched to GTKr grid size, snap set to grid and Quake 3 player model as a reference to scale. This way user can open that scene and basically start mapping without worreing about scale and proportions.
Hi Motorstep, glad you find my script useful (since it was made to your spesifications ), but Vincent has made a great start on his own map exporter and Id like to include him in the process of improving and testing.
If he’s interetsed we could help him improve his, then move some of the features from mine into it.
Looks like he’s done some more level creation then has been done with mine.
I just visited his website and I didn’t see any levels created at all
All he has on his website is Terrain Creator that is compatible with Torque Game Engine (judging from screenshots).
Ok. I got one screenshot from Garage Games forum. Now I see, the target engine he chose is Torque Game Engine. It has a little tool to convert .map files to Torque internal format.
Well, we pursue different targets. Since he doesn’t appear here for discussion, I would think that the purpose of Vincent’s exporter is to support Torque Engine.
Yours as I mentioned above kinda universal exporter for Quake 3 based engines.
I haven’t tested Vincent’s exporter, but I wonder if .map generated by his exporter will be opened by GTKr ?
I really don’t know if we should spread energy on two exporters. I think we should improve yours and add missing features and Vincent can help with that if he would like to.
EDIT: Just noticed next thing: “This script add Valve 200 (.map) export to blender’s export menu”. So it’s not Quake 3 .map file. And AFAIK Quake 3 doesn’t support portals.
Found a bug in your exporter Cambo It doesn’t export lights properly. When I export scene with light and then open it in GTKRadiant, I get error about wrong type of primitive
That script is exploding for me with Blender 2.42a on Ubuntu Etchy.
Map Exporter 0.0
writing cubes from meshes
Traceback (most recent call last):
File “export_map.py”, line 281, in export_map
AttributeError: ‘module’ object has no attribute ‘mesh2linkedFaces’
Saved session recovery to /home/user-new/.blender/quit.blend
I guess I’m missing something. Motorsep told me to use a CVS version, but that didn’t did the trick either (20ish of December).
Ideas?
Btw, as lead maintainer of Nexuiz I highly appreciate your work on a .map exporter plugin. We could use .ase for terrain, but q3map2 generates collision planes that sometimes fail to work in our engine (it needs to regenerate brushes for non-axial collisions - something Q3 doesn’t do). Your export scripts sounds like the perfect workaround - and it’s a very nice workflow to avoid GTKRadiant for most of the work, too
Yeah, that’s how it works. .MAP file contain misc_model entity, which refers to external .ase file. Something like that (a model can be in ase or obj formats):
{
“classname” “misc_model”
“origin” “40 -8 0”
“model” “models/mapobjects/ase/ase5.ase”
“spawnflags” “2”
}
And then when you compile level with q3map2 tool, it will embed .ase/.obj file into final .bsp level.
So yeah, it would be cool if we could flag mesh in Blender to export it as ASE or OBJ. or if not flagged at all, to export mesh as brush (if it’s cube, if not, to turn each face into a brush… just like you did it before with Suzanne )
xref objects, sounds like a plan. is there any preference for obj/ase?
Since I wrote most of the OBJ i/o Id prefer to use what alredy works ;), but ase supports vertex color and perhaps q3map2 can make use of this too.
Ah, okay, got it running now. The CVS build I downloaded didn’t create a ~/.blender directory on itself. I copied over the scripts from CVS and it works.
I like what I see there. Sure, it seems to be at an early stage and most vertex-positions seem to be off… but I can definately see a use for this concept as q3map2 and external models (.ase or .obj, doesn’t matter) are somewhat troublesome collision-wise at times.
Awesome output I must admit
The only issue is that 3-4 faces has been exported with mirrored and rotated UV coordinates. You can those 3-4 brushes in .map file, I put light source right above them to mark the spot. ideasman42 said he will look into it.
motorstep, the exporter dosnt even export UV coords, converting UV coords from blender to a brush isnt straightfwd, but probably can be done well enough to use.
Might terrain be better done as a patch?
Can radiant do mapping well enough to replace Blenders, your only using a projection anyway.
Not really… I use sculpt tool to make terrain. I can’t use Sculpt on NURBS. And collision calculations are slower on patch than on brushes.
I tried using GTKr to fix the problem, but it’s a pain. GTKr doesn’t even have proper tools to work with selection. In other words it can be done, but it takes alot of time.
If I export from Blender, I can just type name of the texture instead of NULL and get terrain textured.
I actually though that we are going to have nice 90% replacement for GTKr, because alot of folks don’t like the way GTKr works and don’t like it’s workflow. GTKr is not really bad, but Blender is much easier to work with.
hey motorstep, Im still not sure how much this exporter is supposed to be able to do. seems to depend on how good GTK.r i, however implimenting mapping is next on the list, Im probably going to copy some of Vinces work if he dosnt mind. Brush tex coords baffel me and he seemed to have it working so it may not take that Long,
Vince, if you interested/reading, Im happy to merge either way still. neither will be in 2.43 release.
I think texture mapping isn’t necessary. It’s not hard to apply textures to walls/ceilings in GTKr/QuArK (well, don’t know about QuArK). But when you have 100s small brushes combining terrain - that’s a pain
So all we really need right now is a fix for that specific problem. If you noticed, everything textured fine except those few faces.
The only option I would add for textures to tile. On export you can add an option “tile:X” and “tile:Y” (if it’s easy, you can add other options as translate, rotate, etc.). So basically those numbers will be written upon export. No WYSIWYG
The major problem with GTKr is that I can’t select all faces with NULL textures at once and assign new texture with reseted tex. coords.
(yeah, it’s written in Java as I’m not fluent in Python or C, sorry if it gives you eye cancer - oh, and it’s written in really old language style to give GCJ a chance to compile it)
), but Vincent has made a great start on his own map exporter and Id like to include him in the process of improving and testing.
It doesn’t export lights properly. When I export scene with light and then open it in GTKRadiant, I get error about wrong type of primitive 
![[img=http://img186.imageshack.us/img186/8084/bildschirmfotodk8.th.png]](http://img186.imageshack.us/my.php?image=bildschirmfotodk8.png){kind=link}