Purple Panzer does almost all of his work in Visual Basic.
My advice to you would be, since you are familiar with BZEdit, use that to deign the overall shape and playability of the map, then use a 3D editor to apply eye candy.
Using modeltool to convert obj to bzw (including drawinfo) is not difficult at all. Which means any editor that will export as obj format is fine, which is almost all of them. many won't import obj though.
Wings3D is free, open source, definitely easiest, has everything you'll need for BZ, and it does export directly to bzw. Do the house tutorial here, takes about 90 minutes and you'll have about 90 percent of the knowledge you'll need. You don't need the hand tutorial for BZ. Adding textures can come later.
http://www.wings3d.com/?page_id=676
I suggest you do your hand-editing an a separate file which has an include statement referencing the 3D file. Load the hand-edited file into bzfs, and that file loads the mesh file. Once a mesh is complete, paste it into the first file and move to the next mesh.
The biggest difficulty is combining mesh objects and bzw-style objects, and you wind up with what is sometimes called "the floating point bug", where tanks can't drive from object-to-object and looking at the numbers it sure looks like that thing should be drivable.
It's super-frustrating when the same object works fine on your computer, but when you bring players in, someone else's CPU computes the decimals slightly differently, so it's not drivable for them. The tops of all boxes must be perfectly flat, and what looks like perfect when you look at the numbers is not always perfect when out in the wild. _maxBumpHeight does not help. This will drive you nuts.
My method is:
Build the map in bzw, being sure to test the tops of all blocks to be sure they are drivable. Especially around bases.
Convert to obj using /saveworld -o
Apply an invisible texture to the entire bzw map. (modeltool has a bounding function to do this automatically when converting drawinfo, but I never use it, because my model usually has small errors.)
Load the obj file into your editor and apply all the eye candy you could ever want in the 3D editor, export as obj and convert to drawinfo using modeltool.
Once the eye candy is complete, add the mesh to the invisible bzw object, inside a define.
Drawinfo displays much faster and smoother. Small errors in the mesh don't matter because drawinfo doesn't interact with collision detection. You don't end up with extremely hard to fix single-point errors in the mesh because the bzw-type objects are exclusively used in collision detection.
Occlusion and collision detection is what makes maps seem choppy in play.
Another trick I use is (once the bzw is converted and loaded into the editor) I will move objects to point 0 0 0, apply the eye candy, then export back to bzw, and use shift in a group to move them around. Especially if the same object is used in several places. You only have to apply the eye candy once, and the bzw-style object you originally made, tells you exactly where to shift it.
There's a lot of cut and paste, but what you end up with looks like this...
group thing
shift 50 50 0
end
define thing
box
material invisible
size 10 10 10
pos 0 0 0 (this was originally 50 50 0, change when you add shift in the group)
end
mesh
vertices...
normals...
texcoords...
drawinfo
corners...
lod
end
enddef #thing
# invisible material removes item from display, but not collision detection
material
name invisible
color 0 0 0 0
noculling
noshadow
nosorting
nolighting
groupalpha
#noradar
end