Converting FBX models with textures?
Community Forums/General Help/Converting FBX models with textures?
| ||
| Hi all, I bought this nice little pack last night, knowing some conversion would be involved, just for messing around... https://www.cgtrader.com/3d-models/architectural-exterior/cityscape/simplepoly-city-low-poly-assets I can import the .fbx files into Blender, Milkshape3D and UltimateUnwrap demo, but none of them show the textures. I basically want to be able to export to ANY format -- I don't care which -- that could be loaded into Blitz3D, MiniB3D, OpenB3DWrapper, etc, with the textures present. (No animation needed.) The archive, stripped down to a vehicle plus its texture, is laid out like so (all are folder names, except for the two .fbx and .png files):
+---FBX Model
| +---Vehicles
| +---Vehicle with Static Wheels
| Ambulance.fbx
|
\---Textures
\---Vehicle
Ambulance.png
... or:  Any idea how I would go about at least loading the textures into Blender or MS3D? I'm trying to do this for free/cheap (I own MS3D from years ago) so would prefer to stick to free/MS3D if possible! In Blender, selecting the textured rendering view doesn't show any textures, so no idea if this should actually work by default... Any pointers gratefully accepted! |
| ||
| Fragmotion has the best compatibility for blitz. For the most formats supported, noesis is better. Btw: There is something wrong with the b3d loader in Openb3d, it will import models mangled up that are fine everywhere else. |
| ||
| @BP You just need to retarget the textures in fragmotion, not that hard. If you need help with the model, post it here or send me a copy via dropbox or any media uploader. I'll be glad to help out for a change. :-) For the openb3d issue, that depends on the exporter tool. Fragmotion is still ok. |
| ||
| Thanks, guys -- I'm basically looking for free options, though -- I can't justify $60 for something I'm just playing around with (and, more to the point, I can't afford it at this point in time!). I have managed to get textures to show in Blender by dragging onto the model (hardly a fluid process for dozens of models!), though really struggling to get anything to output a textured version of the model -- got a B3D exporter that gets the mesh out, but no textures. Just tried noesis 4.177, which can show the model with material (again, after manually dragging it onto the mesh), and exports the mesh, though struggling to load it with textures. It always seems to output .pcx texture files despite selecting manual jpg/png/bmp/whatever... This definitely hasn't been fun so far! I do feel like I'll get there, though, somehow... |
| ||
| Woo! Got something that works! Turns out that exporting to .3ds or .b3d in Blender and just loading the texture via LoadTexture/EntityTexture within Blitz3D works great. (Er, it's been a while... ) I'm using this Blender exporter with Blender 2.77a: http://www.rtsoft.com/forums/showthread.php?7509-Blender-B3D-2-6x-Export-script Mirror here -- original by Diego "GaNDaLDF" Parisi and licensed under GPL: http://www.hi-toro.com/blitz/b3dexport.zip Thanks, all! |
| ||
| Good to hear! :) |
| ||
| Back again! I can export the model and apply its texture manually, but using the following program, I seem to have some weird problem with surface normals, as far as I can tell:  Blender (inset) looks absolutely fine, while Blitz3D has weird dark triangles that change as the model rotates; even the wheels have strange offset angles. (Ignore the colour differences here.) I've tried a couple of Code Archives entries that should update surface normals, but they either crash or make no visible difference. Any ideas as to what might be wrong here, or how I might fix it? This happens regardless of exported model type, as in .3ds or .b3d. |
| ||
| Hey BP, try opening the mesh in fragmotion and selecting it then Face -> Reverse Vertex Normals or Vertex Order. This happens a lot in most exporting tools and I found that solution to fix the problem. I forgot the blender equivalent but try Flip Normals. Post the model if you like me to try fix it and confirm the steps. :-) |
| ||
| Does the Blender exporter export smoothing groups? It looks suspiciously similar to a model whose smoothing groups have been lost. Or it could be unwelding all of the vertices. You could check that by comparing the triangle count with the vertex count in B3D. |
| ||
Not sure about smoothing groups, Gabriel -- it is using flat-shading here, so maybe that's why it looks as it does, though obviously the lighting angles are still messed up. Using this code:For surf = 1 To CountSurfaces (mesh) ; Ow! This is 1-based! tris = tris + CountTriangles (GetSurface (mesh, surf)) verts = verts + CountVertices (GetSurface (mesh, surf)) Next ... I get tris = 624 and verts = 552, so what would that mean in terms of unwelded vertices? (It's hurting me just to think about how the count would look as welded versus unwelded. Maybe it's simpler than I'm imagining, though?) (Thanks, RK, but I don't have Fragmotion -- I'd like to think this ought to be do-able with free software in this day and age, so am clinging to this idea for as long as I can! Besides, I simply can't afford to spend the $$$.) |
| ||
| Hmm, just tried exporting again, and now I have 1492 vertices with 624 tris. Still looks awful either way! These are my current export settings:  Reckon you're probably right about the unwelded thing, though no idea how to fix that in Blender. |
| ||
| 1492 and 624 sounds like they're unwelded. 624 and 552 sounds much better though. Smoothing groups are just a method that a lot of 3D applications use to determine how vertex normals are calculated. For instance, two triangles which share a smoothing group will be calculated so that their surface normals are averaged to create a smooth surface. So you wouldn't get those hard edges that you're getting where two triangles meet. I'm not overly familiar with blender though so it may or may not have the concept. (Possibly) stupid question: What results do you get if you call UpdateNormals in B3D? With an organic model, the results will probably be horrendous, but with a hard surface model, they might be OK? |
| ||
| UpdateNormals actually makes no visible difference, unfortunately. With the types of models involved, I basically don't want any smoothing, so that's not really a problem. I found some mesh/vertex/'face' options in Blender, including a Recalculate (face) Normals, but the results are still exactly the same :/ |
| ||
| Here are my observations, based on my experience with 3D tools ( nil ) and numbers ( a lot ). Imagine building up a simple mesh, and counting vertices V and triangles T as we go. Start with one triangle. V = 3 and T = 1. Now add a vertex and connect it to the existing mesh by drawing two edges to existing vertices. Now V = 4 and T = 2. Continuing in this manner at each step V and T each increase by 1. At 100 triangles we would have V = 102 and T = 100. Thus V is always T + 2 for such a "piece". ( I'm just making up terminology ). Now consider a mesh which consists of a collection of such pieces and look at V - T. Each piece contributes 2 to this number. If V - T was 20 then the mesh would contain 10 pieces. What does this say about the SUV? V = 1492 and T = 624 gives V - T = 868, so that would be 434 pieces, if it indeed had my imagined "built from pieces" form. That seems excessive. It suggests that most of the pieces consist of one or two triangles. What about the 624,552 case? If it is "tris = 624 and verts = 552" then I don't know what to think. It is possible to have T > V. Simple example, start with three vertices. Add one triangle, consisting of these three. Now add the same triangle again. In fact you can have as many as you like, making T arbitrarily large while V is always 3. A less goofy example, start with five vertices, the corners of a pentagon. You can draw ten different triangles using them. So T = 10 and V = 5. There are no duplicates, but a lot of overlap. Maybe the numbers got transposed and it was T = 552 and V = 624. Then V - T = 72 and we have 36 pieces, which sounds more plausible. |
| ||
| Here's another idea to play with. Use textures that let you more easily easily see how they are being applied to the model. For example horizontal lines which fade from bright at the top to dark at the bottom. Or vertical stripes fading right to left. I'm thinking about this due to, for example, the left side of the SUV, below the windows. Or the tires. |
| ||
| Thanks, Floyd, some good ideas there -- I'm going to start by the OMG-why-didn't-I-think-of-that texture idea and see what I can see! |
| ||
| OK, the texture thing didn't make me any wiser. I have been playing with a program called MeshLab, using a .dae mesh exported from Blender. Interestingly, it renders fine by default, but when I select to render textures -- there are none here -- it produces a similar effect to Blitz3D, ie. light/dark triangles that are next to each other/on the same plane. More interestingly, the normals can be seen to be correct: look at the left-front wing/fender and wheel here -- the little blue lines show the correct orientation for each one:  I guess that's showing the normals for each triangle, but given that enabling texture rendering shows the weird shading (see top of wheel and compare shading to normal projection), that seems to suggest that the texture normals are messed up somehow. (Does that make sense, given in Blitz3D I get this shading even without applying the texture?) Does any of this this mean anything to anyone? Something to do with vertex normals versus vertex u/v/w? |
| ||
| Another idea, examine the values for the various triangles and hope for inspiration. You could look at x,y,z nx,ny,nz u,v and perhaps vertex colors. The first challenge would be to cut down the amount of data to be examined. Looking at the red MeshLab image the front bumper gets my attention. Notice the two triangles at the very front of the vehicle. It looks like the Y-axis is forward for the vehicle, so these two triangles could be easily picked out because they have the largest Y values. In the early days of Blitz3D I was trying learn how to build my own meshes and wrote a function to examine them. It showed only position and normals, but you could easily beef it up to do more. http://www.blitzbasic.com/Community/post.php?topic=105172&post=1279694 And I just spotted this in that DumpVertices example: Graphics3D 800,600,16,2Yeah, that's old code. |
| ||
| I had another look at the MeshLab image and noticed the information at the bottom. How did vertex count get down to 344? And what about Faces: 1248? Just what is a face? |
| ||
| No worries. There are lots of tutorials and related info about this issue, maybe you can look at this thread or just google search for Blender Reverse Vertex Order. :-) http://blenderartists.org/forum/showthread.php?107802-Reverse-Vertex-Order-Possible |
| ||
| Most modelling applications will render a hard line between triangles which are not precisely coplanar and do not share a smoothing group. They will adjust the data they export to match this. So I know you said you don't want smoothing but you do. You just want selective smoothing and not between all triangles. That's what smoothing groups are about. It's telling the modelling app that you want no hard lines between this group of triangles. And that you DO want hard lines between triangles in any other smoothing group. I'm not familiar with Blender but I imagine you could fix this in Blender by applying smoothing groups correctly. However, that doesn't solve the problem of why it's happening. You have an existing FBX model which should already have its smoothing and normals correct. Blender must be dropping this info when you load it. A forum search came up with this advice : After the import open your static mesh and enable Recompute Normals and Recompute Tangents Under LOD0 and save it. That should fix it. If that works, you won't need to set the smoothing groups. You should be able to just re-export to B3D with the original settings you had set. |
| ||
| Thanks again, all. Off to stock up on beer for inspiration, then I'll have another go with this all in mind! (Floyd, no idea about the vertex/faces count there, but I had to use a .dae mesh to get it into MeshLab, so maybe it's different in some way, but it does at least exhibit the same problems.) |
| ||
| Had a look at the commment about recomputing normals/tangents under "LOD0", but on searching for that string, it sounds like that is something within Unreal rather than Blender. I have tried some options within Blender that supposedly recompute normals, but to no avail. Clearly, 3D modelling still sucks :/ |
| ||
| Clearly, 3D modelling still sucks :/ I'm no expert but I have some experience with those issues. Maybe there's still a problem with the exporter as I find some outdated or custom Blender plugins rather unstable. Send a very low poly version, we could probably give it a go using Blender. |
| ||
| Sent you email, RK! |
| ||
| ... |
| ||
| sorry, I forgot to enable my email add at my profile page. It was hidden when I first signed up. Send it again or maybe just upload it on cloud, so we can all try and figure this out :-) |
| ||
| Cheers, RK... I should probably try contacting the author before uploading anything publicly, though, will see if I can get in contact with them. |
| ||
| Ok no problem. :-) |
   |