Hi, I seem to be getting hard edges appearing in the engine where the UV seams are on my models.

I’m not sure if its down to the MD5 Exporter I’m using or if its down to the whey the file is set up.

My current workflow is model and animate in Maya 2011 export out as FBX open in Max 2010 export out as MD5. The UVs are all laid out in one tile and are applied to one material with a normal, diffuse and spec map plugged in. The mesh looks great in both 3D apps with no hard edges where the UV seams are.

Can anybody shed any light on this issue

Any help/guidance would be very much appreciated.

cheers

Wayne

In this example http://videometry.blogspot.com/2011/05/mocap-to-molehill-via-3d-studio-max-and.html  I found UV’s to be flipped on the X axis, compared to MAX, though it may depend on the MD5 exporter you use. Easy to test this, just put some text into your diffuse map and check it shows correctly.

I’ve found normal maps seem to accentuate seams generally. Maybe try without?

Also, be aware that Normal maps run as normalBump maps in the current 4.0 library, and must therefore be calculated relative to the surface, rather than world coordinates as Max’s normalMap baker makes them.

Good luck!

It could be related to the MD5 file format. I’m not sure that it supports vertex normals. There should be no technical reason why edges with UV seams would get incorrect vertex normals, unless they are calculated automatically by the engine (and not exported as part of the geometry definition.) Are you using skeletal animation, or why are you using MD5? Try with another file format and see if it works better, e.g. AWD2 using the pre-release Maya exporter available at http://awd.googlecode.com

I found out yesterday that it’s not do much UV coords, but also vectors that are mirrored on the x-axis when exporting from Max and importing to Away3D. I will try fixing that.

@Peter, I was referring to the original poster’s issue. I don’t believe yours is at all related.

OK RIchard, I’m going to try editing the importer. Seems different exporters give different results. Is the MD5 tested against anything particular? E.g blender exporter?

I noticed all my animations are mirrored on the x-axis.

UV seems can be greatly improved by using a larger models. (i.e. scale by 100, or 1000, can always shrink again in Away
It appears the values get rounded off otherwise, creating holes at seams if vertices aren’t welded together.

If your models suffer from rounding errors then that’s probably related to the exporter in Blender (and Python’s default way of dealing with float-to-string conversion which includes six decimals.) This happens a lot with plaintext formats, but would not be an issue if you were using a binary file format instead of MD5.

Re the mirroring issue, MD5 does not specify an orientation of axes, which probably means (depending on the exporter) that whatever you have in Blender will be directly transferred into the file. Using the same philosophy, the Away3D importer will just take exactly what’s in the file, and yes, that is likely not to align nicely with the Away3D coordinate system.

You’ll need to edit the Blender exporter (unless it has user-editable options) to make sure that it exports the file into a left-handed coordinate system with positive Y axis pointing up, or use another file format. I’m working on an AWD2 exporter for Blender right now, so if you don’t have anything against working with pre-release software like AWD2, I would recommend taking a look at that in a week or two from now.

Hi RIchard, I’d love to give it a shot if I may. I’m a MAX man primarily, but a round trip through Blender would be OK.

I could change the MAX exporter (MD5), but it seems to make more sense to change the importer, so as to be able to use models made for Doom, as appose to only models specifically generated to match Away/Flash.

I look forward to being able to use the AWD2 format. Is there any workflow from Max to AWD2 with boned animation, or is that still a work in progress?

Cheers!

There is no AWD2 exporter for Max. One will hopefully be built during the last quarter of this year if no sooner. The blender exporter will hopefully be stable in about a month or two from now.

I was experiencing this problem (hard edges on md5mesh at UV seams), and here is how I solved it. I’m using Blender 2.59 and the md5mesh/md5anim exporter from katsbits.com. In Away3D, I thought to check out the vertex normals with:

and what I found was that vertexes along UV seams had two normals pointing in different directions, and that’s what was causing the hard edge. So, I looked into the md5mesh exporter from katsbits, and found this comment for vertexes with different uv coordinates:

# This vertex can be shared for Blender, but not for MD5
# MD5 does not support vertex sharing for 2 vertices with
# different UV texture coodinates.
# => we must clone the vertex.

So, the exporter is giving you two vertexes along uv seams. One thing I tried was to re-weld these vertexes using the Weld command:

With this command, it was able to weld the overlapping vertexes, but this messed up my uv mapping. I even tried the new version of the Weld library in the repository, and different values for keepUVs / keep Normals, but if it welds the vertexes, I just don’t think it will work, because what I needed was either one vertex with two different uv coordinates (not sure if this is even possible), or two vertexes at the same position with different uv coordinates, but the same normal. So, based on code from the Weld class, I wrote a class with a function that takes any overlapping vertexes, averages their normals, then applies this normal to both vertexes.

It is attached to this post. You can use it like this:

It assumes that your mesh is a single mesh with a single subgeometry. It could be updated to handle objects with more than one submesh, but I didn’t do this. I hope someone finds this helpful. I also really hope there isn’t an easy way to do this that I missed.

I am necroing this thread because I too am getting hard seams. However, it happens with more than just MD5 for me. I tried exporting as OBJ and using that, and also converting the OBJ into an AS3 via PreFab 2. Still, the hard seams.

Then as Mark suggested, I tried the Weld class. No change at all. Then I tried his Normals class. No change at all.

I then tried baking the normal map with the “world space” setting rather than “tangent”. Obviously not the right solution. Normals all messed up and STILL the hard seams.

Then I tried exporting a giant version of the model as Atom suggested (in OBJ format). No luck.

In Blender, there are no hard seams. What am I missing here?

hi

have you tried to figure out if the imported normalData is valid?

sounds a lot like the vertexNormalData is constructed using SubGeometry.autoDeriveNormals=true

if your imported normalData is valid (same length as vertexData), than the
SubGeometry.autoDeriveNormals should be false

hope that helps

That’s interesting. I just ran a trace and it’s true. I’m using the Katsbits keless Blender 2.61-compatible MD5 exporter. I guess I’ll try another MD5 exporter or look into AWD2.

Alright. I tried the other popular Blender MD5 exporter. No luck. Then I reread what Richard said above about MD5 not storing vertex normals. So I tried some other Blender export formats: OBJ, DAE, 3DS. The results? None of them get rid of the hard seams. Am I missing something? What am I doing wrong? I’ll post my .blend file if need be.

hi

cant help you much there, because i dont know much about blender.

i took a look at the normals.as posted before, and it should really do the job.
maybe you should try again with that.
be aware that the normals.as might smooth out any hard edges on your mesh too. (if a hard edge is a uv-seam too, it will no longer be a hard edge, because the normals get “welded”)

hope that helps

keep in mind that what you see is not perse what it is… I mean, are you sure the vertices at seams are at same position? Visually they are, but would you see a 0.00000001 diff in position? If there is a diff, even the slightest, they will never weld. not in Prefab, not In Blender.
I would try to either force snap to grid (and possibly reedit after a weld) or weld by distance.