UVW map exporting to FBX

Rhino Rhino for Windows
1

Hi! I’ll try to summarize my plight as much as possible, here goes:
I’m trying to export geometry from Rhino to Unreal Editor 4 by Epic, and I’m trying this by means of the FBX export.
The problem is that the UVWs are weird, and inside UE4 I have to re-do every single UVW to be used as tex-map and, more importantly, light-map.
First efficient semi-solution was applying a box-mapping in Rhino prior to exporting, which cleared up the stretching/scaling issue that probably was a result of the Rhino-surface-mapping. I used one of those numbered checkered textures to see if it’s straight and it works fine, it’s no longer distorted. BUT!
But, somehow the unwrap or whatever the box mapping generates is bigger than the rectangle which (i think) represents (0…1,0…1) UV space and that creates problems still with the lightmap.

So, is there a way to “reparameterize” whatever box-mapping in rhino generates as UV space for the objects?
Can I apply this to all objects at once?
I tried exporting manually unwrapped objects from Rhino to UE4 and it works like a charm, all problems gone, but doing that for hundreds of objects is impossible.

Also, it would be really cool if I could set Z-up / Y-up in the Rhino export options, since UE4/Unity/etc all lack that option upon import, and I have to rotate everything there.

And last but not least, does anyone know of a script that exports each layer as a separate fbx-file? So that I can have different material layers, export directly to a miriad of files inside a folder, then grab them in UE4 as a combined mesh. Or if it’s doable, that i might try it, pointers much appreciated :smile:

Thank you very much!
Andrei

2

Without being a user of UE4 I’m guessing a lot here as the issue may be on FBX export from Rhino or FBX import to UE4. My thought and question is if you have tried OBJ instead. This would at least provide the Y axis up option on export from Rhino.

Can you provide a sample 3dm and the associated texture maps too? I’d like to test FBX using your mapping to some other programs to see if this is isolated to UE. Surface mapping from Rhino exported as FBX is working here to Blender as one test so I’ll need to try one of your files too for comparison to tell if it’s anything Rhino can account for.

3

Thank you Brian for the quick reply!
Unfortunately obj is not supported within UE4, it only eats fbx. There are some workarounds, but it’s quite manual and complicated.

One of the big issues concerns materials - I need a way to differentiate between materials upon importing in UE4 - so I’ve made layers for each material and group of objects (e.g. “1st-floor-doors-handles” or “GroundFloor-walls-concrete” and so on).
The problem is that i have to individually make a new material for each layer so that it doesn’t mix them up upon importing, which is why i was asking about the possibility of writing a script to export each layer into a different FBX, so that UE4 picks up that layer’s contents as a “combined mesh” FBX, becoming a single object with a specific material. That was actually a problem when using 3dsMax and Lumion as well.

Regarding the UVW mapping on export, which is the real issue here, the way that the mesh uvw-s are unwrapped is very chaotic, faces overlap and/or fall out of what-i-believe-to-be the 0…1/0…1 rectangle. I have to edit that in UE4 individually for each object, and it sets them up neatly and packed. Also by passing through Blender, the issue gets fixed, but other issues appear (scale etc).

Anyway, here’s some of my geometry, but I’m convinced it doesn’t actually matter, since it does this with everything https://www.dropbox.com/s/uqyuj9yluxb8uo0/UPDATE%2001%20ANDREI.3dm
Thanks again!

4

Thanks for the sample file. I didn’t have any of your textures in the 3dm but I assigned some of my own to test as FBX to Blender. I’m not seeing the material mix up on import but one thought I did have was that some of your materials have no name or start with the same word e.g. New. A common OBJ material issue is that each material must have a unique name and not have spaces in it. Try this to see if it helps the material mix up part of the issue.

I did find that the mapping repeat values do not carry over in FBX if you set the tiling in the material. Instead, use the texture mapping repeats in Object Properties and the FBX will maintain those values… at least in Blender. I’m thinking that you should try asking the UE4 users or support if they know a workaround as well.

Good luck.

5

Thanks again for being such a great and helpful dude :smile:
What do you mean by mapping repeat values? The tiling?
One thing i did before exporting to fbx was selecting all and applying a box mapping 1x1x1m or such- and indeed the fbx does inherit that mapping in unreal.
The problem lies with the unwrapping. I’m not sure if the Rhino fbx exporter sends off an unwrapping of the mesh as well, which would mean that the bug resides there, but it looks that way, because geometry coming from various modelers gets screwed up differently when imported into unreal.
For example, stuff coming from 3ds max has problems with vertex normals, which jumbles up the vertex smoothing, so you have to rebuild the normals to fix it.
Stuff coming from Rhino has problems with unwrapping, so you have to redo the unwrapping in unreal, to fix that.
Stuff coming from Blender has scale issues and various others bugs.
Now ideally for me, i’d do the export directly from Rhino, and cut the middle-man, which is why i’m pushing for a solution on Rhino’s end. In the mean time, rest assured, i’m banging at the unreal devs’ doors as well, hoping to solve this on the other end too. Such is life :smile:
One more question, I keep asking - do you have any recommendations on how to automate the making of unique materials per layer in a Rhino file? I’ve found a script that is kind of useless, since it only does this for one layer at a time (deriving from the layer’s color) - http://neoarchaic.net/2011/02/layer-color-to-layer-material-color/

PS: Regarding the materials, you’re saying that because of the length of their names (all are unique though), they may be chopped up to a sort of “EXAMP~1” (say, from “EXAMPLE_TRALALA_ETC”) upon exporting? And that may cause the problems, too many characters in the name?

6

Yes.

A custom (unwrapped) UV does export from Rhino with FBX. I tested this going to Blender to confirm.

I’d post a new topic asking just for that in a script. Keep it very simply put and I bet one of the scripting gurus here will make it for you. I’m sure it’s possible using any of the scripting languages in Rhino 5.

Not the length (although there is some limit I think) so much as the spaces have been known to cause an issue with OBJ. For instance, if you have three materials “new mat 1” “new mat 2” and “new mat 3” they will all be seen as the same material because the mtl file that travels with the obj assigns them all to the first “new…” material name. Use underscores to solve that issue. I’m guessing it might be an issue with UE4.

7

Update - i’ve polished my rhino-python skills and made the script happen. NEver underestimate the power of “i need this NOW” :smile:
The script also parses the layer names and replaces " " with “_”, and the material names are in fact the same as the layer names. I guess it should work.
Right now I’m updating my UE to 4.0.2, we’ll se how that goes now.
I’m thinking of ways to somehow automate in UE the generation of nice UVWs for each geometry that I import, because I have the feeling that I’m barking at the wrong tree here, since Rhino and UVWs are always gonna be a problem, especially passed through fbx…
I’ll keep this post alive with my conclusions, thanks for everything Brian!

8

Hi,

I’m interested in clean UV for baking per AIR too. It’s looks like the pack texture function works much better than some months before, at my current test I don’t see stretched UV anymore. Attached a screenshot from Unfold3D that shows the Rhino UV:

@Brain: could there added gaps between the UV islands please? If the lighting is baked to the texture the baked light could cause artefacts between the islands. Here a screenshot of repacked UV by Unfold3D with clean gaps:

I hope it’s not much work and easy added.

@Andrei: for baking the light to the objects the box mapping works? But on this way you could get the same UV space for different parts of an object. For baking per AIR it wouldn’t work. I think the pack texture function of Rhino could be the better way.
If you post a 3dm example I could check it on the OBJ-Unfold3D-way. Also maybe OBJ better works than FBX, you could test it.

Ciao,
Micha

1 Like
9

Micha, that’s an interesting point you raise, with box mapping generating same UV space for different parts.
I’m not sure, actually, if that is the case - in theory you’re right, but UE doesn’t seem to have a big problem with that.
I mean, even if you leave it to surface UV mapping, it still cries over overlapping UVs.
One thing that caught my attention, the gaps between the textures - that MIGHT just do the trick. How do you access the pack texture function in Rhino you mentioned? I’ll give it a try. Do you mean the unwrapUV? Beacuse for me that doesn’t exactly work, since I have thousands of objects to export, most of them more-or-less box-like. Something automated would be required.

10

Rhino automatic pack textures (of polysurfaces) to the UV space and there are two commads - _unpacktextures to switch back to the surface UV and _packtexture to get the UV packed to one UV space (for each polysurface). So, this function should do the job you need done, but only the missing gaps could be the problem.

The missing gaps are reported since years, but I hope it could be implemented now, since UE4 is an interesting possibility for a wide range of users, not only me and baking per AIR. I hope this is the right time for the little enhancement. :wink:

3 Likes
11

Hey ivanescu_andrei: Have you solved any more of the mysteries related to exporting Rhino Geometries (texture-mapped) to the Unreal Engine? I am having difficulty accomplishing this even though I know solutions exist. Right now, I am exporting .OBJ files and “packing the textures” thinking that this at least embeds the UVW values I’ve assigned within Rhino. Is this still the workflow that you follow? As far as scripts go, is the goal to search-and-replace all " "s within material & layer names with some acceptable characters, e.g. “_” “-”, etc.? Please let me know, because this problem is consuming me…I’m sure you can sympathize with this! Thanks

12

Hi there. Well it seems that in the latest version of UE4 (which is also free, as luck may have it) they solved the issue. There are some things to be aware of when exporting geometry from rhino to UE4. I’ll try to detail them as they come to mind:

First and most importantly: when modeling architecture in rhino, people usually make a lot of touching solids. Think of a 20 cm concrete floor slab, which is basically a box, or an extrusion, and on top of it you have another extruded polysurface, say 5 cm tall, which is the floor finish (like wood or tiles or whatever). They are usually both capped, top and bottom.
Now when I take that to UE4, it gives me a lot of headache, because UE4 really hates touching surfaces (because of the way it projects lightmaps). The touching surfaces here are the underside of the 5cm wood floor and the top side of the concrete slab. You know what I mean, right? When you spin around in a rhino model and two surfaces flicker between them, because they’re on top of each other? That’s what you need to avoid.

Now, there’s no way to actually automate this properly (would be cool though). but you need to process your model for exporting to UE4. Most of the times you’ll still have a few minor UV overlap errors (less than 5-10% of the surface), but nothing noticeable, no blotches or broken shadows, artifacts etc. Those you can ignore.
The point is, make your floor finishes bottomless, make the wall contours uncapped top/bottom.

To give you a general idea - if you have a painting on a wall, the back of the painting should NOT be capped.

oh yeah- and export to obj with the axes unflipped, try different meshings.
If you wanna be a pro, maybe export one with a high poly count as a close-up LOD (level of detail) mesh, and one with lo-poly for distance LOD . The lo-poly, you can also use as collision mesh, but it has to be REALLY lo-poly. Like 10-20 polygons total. Just a sketch of the object, basically.
Let’s see… what else? Oh, texturing ACTUALLY works now, like if you put texture mappings (planar etc) in Rhino they come through in UE4 nicely. Very good for floors, I would recommend doing that in Rhino since in UE it’s harder.
I can’t think of anything else now.
Happy vizzing!

14

actually the export to UE4 could work as an automated thing. Maybe in Rh6 or as a plugin…
Come on you beautiful McNeel people, make it happen, make us happy! :stuck_out_tongue:
I’d say the steps are:

  • automated or manual naming of all exportable objects
  • take each object, explode it into surfaces.Name the surfaces as per the original objects or find another way to keep track of which is what.
  • see if there are overlapping surfaces (i realize this is like 90% or the difficulty). When two are encountered, make a XOR operation.
  • for each named group, join them back together, mesh them and export them to a nice OBJ (maybe same name as before)
    From there on out, it’s peanuts in UE4.
16

This is terrific. Thank you, ivanescu_andrei!

This confirms some of my original notions about exporting to UE4 (and even Max and other programs from Rhino). I have been using OBJ, and this file format seems to be the most reliable (axes and all).

I wasn’t aware of the tangent polysurface faces, however, so thank you for pointing that out to me. The baked in texture mapping is also a great feature now that UE4 supports it!

I have noticed that OBJs are imported at a scale different from the scale at which they were constructed. This has been a recent issue for me. I am doing architectural visualizations with Rhino and UE4, so it is critical that the scale is correct. I have experimented with a workflow that moves from Rhino -> Blender -> UE4 (via *.FBX format) where the objects simply need to be scaled by 100 (Blender Units -> UE4 Units), but this is an undesirable workflow for a few reasons. One reason is that the origin point seems hard to maintain.

Anyway, if you can help me out with the OBJ scaling issue, then I should be able to bypass Blender and import straight from Rhino into UE4. All of these file importing/exporting acrobatics seem so ridiculous sometimes! I like Rhino too much to switch programs, though.

17

shouldn’t be an issue - If i remember correctly, UE4 works in centimeters. Make sure that your Rhino model is in centimeters as well and you’re good. I do believe there is a setting under world setting or something like it, in UE4, to change the units, but I wouldn’t recommend it, honestly.

18

Thank you so much for this thread! I have been playing with the UE4 and a small rhino created house, and trying to figure out why I was getting some strange light artifacts after building (it always looks great if I just play before building except for that pernicious ‘lighting needs to be rebuilt’

I think it must be the tangent surfaces that are everywhere! Max to ue4 seems like a better workflow, though I loathe modeling in max…

19

glad to have helped! I also think Max to UE4 sound easier, but wouldn’t the
same tangent srf problem apply? What would be GREAT is a plugin that makes
the transition between Rhino and UE4. It’s actually not that hard, in
theory: if two surfaces overlap, say surface A and surface B, ten surface A
should become A-B and B should become B-A. Add some UVW mapping and proper
meshing and you’ve got a great plugin I would totally pay for.

20

Maybe an interesting way from NURBS to UE4 could go over MoI3D and OBJ. The quality of low poly meshes is much better, less kinks.

21

Don’t even bother doing UV’s in Rhino. Export to OBJ or FBX and then use a third party UV program like Blender or I use Ultimate Upwrap3D

22

@BrianJ:
I think there are some more problems with FBX export.

Multichannel UV isn’t exported. To replicate:

  • add box
  • add mapping, enable multichannel, add secondary mapping
  • export to fbx
  • import to blender
    Blender sees only one channel, but it imports more for sure (tested with file from 3dsmax).

Same material on two objects is exported as different one with _x suffix. To replicate:

  • add material to object
  • match material to secondary object
  • import to blender and check material name on both

Blocks could be exported as instances (option?). Now they are exported as separate geometry. To replicate:

  • export block and its copy
  • look at meshes inside objects, they will have different name