Fixing the Blender .map export script

[xkvtztvkx]

I've been playing with the Blender .map export script, using the function that exports every face of a mesh to a brush. However it's really buggy and the results are often deformed. I think I've come up with a solution.

Read this post on the Blender Artists forum.

Basically I think that if the vertices of the face were rounded off to whole numbers and were made into a 3D brush by connecting them to a new vertex (also whole numbers) with triangles instead of square faces then this should eliminate any deformation. This would allow meshes made in Blender to be exported to valid brushwork.

Sadly I'm not a python scripter, but hopefully someone on this forum is. Here's the function that needs modifying.

Any volunteers?

Code:

def write_face2brush(file, face):
'''
takes a face and writes it as a brush
each face is a cube/brush
'''

if PREF_GRID_SNAP.val: format_vec= '( %d %d %d ) '
else: format_vec= '( %.8f %.8f %.8f ) '


image_text= PREF_NULL_TEX.val

try: mode= face.mode
except: mode= 0

if mode & Mesh.FaceModes.INVISIBLE:
image_text= PREF_INVIS_TEX.val
else:
try: image= face.image
except: image= None
if image: image_text = sys.splitext(sys.basename(image.filename))[0]

# original verts as tuples for writing
orig_vco= [tuple(v.co) for v in face]

# new verts that give the face a thickness
dist= PREF_SCALE.val * PREF_FACE_THICK.val
new_vco= [round_vec(v.co - (v.no * dist)) for v in face]
#new_vco= [round_vec(v.co - (face.no * dist)) for v in face]

file.write('// brush from face\n{\n')
# front
for co in orig_vco[2::-1]:
file.write(format_vec % co )
file.write(image_text)
# Texture stuff ignored for now
file.write(PREF_DEF_TEX_OPTS.val)


for co in new_vco[:3]:
file.write(format_vec % co )
if mode & Mesh.FaceModes.TWOSIDE:
file.write(image_text)
else:
file.write(PREF_INVIS_TEX.val)

# Texture stuff ignored for now
file.write(PREF_DEF_TEX_OPTS.val)

# sides.
if len(orig_vco)==3: # Tri, it seemms tri brushes are supported.
index_pairs= ((0,1), (1,2), (2,0))
else:
index_pairs= ((0,1), (1,2), (2,3), (3,0))

for i1, i2 in index_pairs:
for co in orig_vco[i1], orig_vco[i2], new_vco[i2]:
file.write( format_vec %  co )
file.write(PREF_INVIS_TEX.val)
file.write(PREF_DEF_TEX_OPTS.val)

file.write('}\n')

[andrewj]

Any approach that merely converts faces into brushes is seriously flawed.

I think the proper way to do this would be to subdivide all the solid areas (the area behind the faces) into convex polytopes which would then serve as the brushes for the .map file.  Who knows what the best way to do that, but personally I'd use BSP node building algorithm.

Also you said "If the 4 vertices are not on a flat plane then you can get different results depending on which 3 vertices are exported" -- but a polygon face is NOT valid unless all its vertices are co-planar.

[xkvtztvkx]

Also you said "If the 4 vertices are not on a flat plane then you can get different results depending on which 3 vertices are exported" -- but a polygon face is NOT valid unless all its vertices are co-planar.

Sorry, I didn't explain that well. When a triangular face is extruded to make a triangular prism the vertices on each 4 sided face are co-planar, but the x,y,z values may have non-whole number values. My point was that rounding the values of the vertices of the extruded second triangle would make them non-planar. Only 3 of these vertices would be exported to the .map file which would give varying results depending on which 3 were sent. The problem here is that because the existing method uses 4 sides faces then you are forced to accept either non whole number vertices or vertices that were not co-planar.

This is why I wanted the script to take a triangle and extrude a single point from the centre and conect it with more triangles. Since triangles are inherently co-planar then all the vertices could be rounded to whole numbers without any side effects. I figured that whole numbers and triangles would be the best bet to get non-deformed brushes.

Any approach that merely converts faces into brushes is seriously flawed.

Quite possibly, I was simply trying to make it work correctly. Mind you, if you had a decent manifold mesh then all the new triangles would be inside it and only the outside ones would end up getting compiled, wouldn't they?

[kernel panic]

xkvtztvkx, I don't know if you'll find it useful (or if you know about this), but hyp3rfocus (some guy) has played quite a bit with Blender and posted in the Rainbow forums several scripts to import/export stuff from/to Blender. Look in the mapping section, there are several posts from him.

[andrewj]

My point was that rounding the values of the vertices of the extruded second triangle would make them non-planar.

Ahhh I see.

BTW why are you quantizing the vertices?

[xkvtztvkx]

kernel panic - I'll take a look. Thanks.

andrewj - It's just guesswork on my part, but I thought that might have something to do with errors creeping in. Zeroradiant's grid system goes in doubles, from 0.25 to 256, so I'm wondering if that's why things go wrong when it gets vertex positions with values like 5.3423. I figured rounding the numbers off might be worth trying.