Having an issue exporting to Unity to produce a VR walkaround type thing for client.
Unity supports two major formats: OBJ and FBX. Problem is Rhino has a small problem exporting useful FBX and Unity has a problem importing useful OBJ so that leaves me without any options really.
Unity won’t read material assignments from OBJ files. So, to make material assignments transition, I would need to name my objects their desired material assignment in Rhino. Then Unity will pick up the name, append Mat to that and then look for a Unity material as object_nameMat.
The FBX exporter doesn’t have the automated welding functionality that OBJ does, which is necessary for useful meshes in Unity.
So… I guess I’m looking for either
easiest and most likely OBJ exporter “hack” that takes the material assignment and plugs that in as the object name.
OR
More preferably adding welding to FBX mesh exports… Also map Rhino Z to FBX Y axis would be necessary.
OR
Some other out of the box solution.
There will be so many iterations I really don’t want to have to add a 2nd step to the export process… i.e. open exported file and manually weld it.
I’ll look at this next Monday. It would probably be easier to do something to OBJ export rather than FBX since OBJ is completely our code and we’re not dependent on a library. Please give me more details about what you want. On import a combination of obj "g"s, "o"sand "usemtl"s is used to distinguish objects. Something to keep in mind. If you only export I guess it’s no biggie but if you roundtrip you may get objects being merged if they all share the same name, ie. “red_paint”.
So, in terms of an OBJ hack if we can put the material name in the “g” field this seems to work.
g red_paint
o object_1
v -3167 4183 3621
etc
g red_paint
o object_2
v -7767 4183 3621
etc
the usemtl lines just get ignored. I deleted them and it made no difference.
Note that I’m also using object names with a custom script to automate light generation in Unity. This hack will mean adding a second step and exporting lights separately. Not ideal but I’ll take it if it makes this work.
The bigger picture however… If you want to focus your energy on making an improvement that will actually be useful to a broader audience might look something like this.
Backstory being that VR is obviously on the cusp of an explosion. I think we’re going to start seeing increased importance put on a seamless mesh export process. And there is a need for lower polygon counts than you would use for photorealistic rendering. There will be a desire for two meshing settings… One for on-screen and photographic rendering, then another less dense setting with bigger angle tolerances etc for VR, at least until the rendering hardware catches up.
My vision sortof revolves around maintaining Rhino as a single source, and avoiding roundtripping. If the export process is a 1-click type affair, it becomes easy to rely on Rhino as the origin source and have the various outputs flow from there.
So, the way I see an overall sortof update of the mesh exporting scheme might look something like this:
This would give us more control on where we spend polygons. Use different settings for more important or focal objects (or problematic shapes) and then dial down the density on background noise.
Would be super nice eventually to be able to specify an output file and settings somewhere and have a 1-click output that just overwrites the target.
In my case, Unity picks up the file update automatically and refreshes the scene with no additional action required by me.
When you say welding, what exactly do you mean? Like what we do in OBJ if someone checks that option? That option writes out a single vertex or any given 3d location, even corners of a cube. It can potentially screw up texture coordinates and also normals to a lesser extent. Let me know exactly what you mean.
If it were to happen though it would be in the WIP. New development for V5 has ceased and all effort for the past several years has gone into the WIP.
For me personally, with Unity it causes lighting issues when I have two unjoined faces sharing an edge. Having the two pairs of vertices which define that edge coincident, resulting in two meshes that look seamless (visually on screen) isn’t good enough. It needs to be a real edge of a single mesh with a single vertex at each end. (or however many vertices)
I find there’s a lot of cases in Rhino where it’s better for workflow if things aren’t joined up. But on export it would be nice if coincident vertices are merged… Providing they’re on the same layer and therefore generally share the same material.
Most obvious example is that I work on boats which are largely symmetrical. It’s a nuisance having to continually explode mirror join every time I want to change something. Would be nice to leave the nurbs loose and have the mesh still export as a single piece.
EDIT: Forgot to mention that in my case UV mapping is getting generated after export or ignored entirely. So that’s not a factor for me.
I think “weld” is not the right term here. I’m not sure Rhino has what your’e looking for. When you mesh surfaces that are joined you’re guaranteed (at least that’s the idea) that you will have coincident vertexes along that edge for the mesh faces created from the surfaces that share the edge. If you mesh the surfaces individually the vertexes, along what would be a shared polysurface edge, may not match up (in fact not likely to). You could join the resulting meshes but you’re likely to have naked mesh edges along the path where the surface edge was. That’s probably now what you’re looking for. I’m not sure there’s an automated way to accomplish this. I’ll run it by Pascal and see if he can think of anything.
Hi Ryan - if the thing is indeed symmetrical, you can mesh half the boat and mirror the mesh and join that. But like Tim, I am not 100% clear on what should be welded and what should be joined, to work for you - if vertices are welded, then there is no hard edge possible in shading - is that what you mean?
I just did some experiments and you’re right… doing what I’m asking for destroys the hard edges. I must have a different problem with my lighting setup. And/or need to do more research.
So I guess what I’m really looking for (current thinking) is more like “auto join” of surfaces on same layer at mesh time.
Also sortof separate issue… but seems like it would be really nice to be able to define meshing settings on per-layer basis instead of per-object because they get lost/screwed up when you join surfaces with dissimilar settings or you delete an object and rebuild it completely.
It’s annoying having to re-export after importing at the other end because I missed settings on some part and have to go back and redo it.
Would also be great at export time to be able to use those per-layer settings instead of a single global setting and therefore having to manually extract the render mesh and then export that.
I’m finding for VR also that most time I have to run at least one, maybe several iterations of reducemesh to get things chunky enough to run fast. I don’t know if that means that the normal meshing options don’t have “bad” enough settings in their range or entirely possible I’m just doing it wrong and haven’t figured out the settings yet.
My user experience with the meshing detailed options dialog in general is that changing settings there don’t seem to always make a noticeable or predictable change to the mesh. It seems mysterious and at times nonsensical. Like some of the settings get ignored at times depending on what other settings are. I think maybe it might just need some help making the UI better vs. a problem with the actual bones under the hood. For example, maybe gray out boxes that are being ignored because of other settings or perhaps if for example your aspect ratio drives the resulting density up above the the density setting, then some kind of UI cue that this is happening might help. I assume that this information isn’t known by Rhino until you preview but that would be fine I think.
Of course having to manually enter the numbers each time is a nuisance. Saving meshing profiles would be a big win, which would be easy to implement.
Being able to type in a total number of polygons you’re targeting and auto generate some values that get you close to that would be really nice also. Even if it was slow and iterative… Like go get a coffee or whatever. I still think it would be faster than the amount of guesswork/fumbling I do there. Then further tweak until result is acceptable. Then can apply those same settings on other objects (applied per-object but assigned to layers I think.)