Importing OBJs Oddities
Jason Galterio
Posts: 2,562
I'm just batting 1000 today...
Importing OBJs into DS and seeing behavior that I haven't experienced before.
1. Some import invisible. If the object is highlighted, the surfaces ghost into appearance. Otherwise they will not appear.
2. Images are coming in reversed. Text is backwards, etc.
These both seem to be related; as if the objects are one sided and I am on the wrong side of them.
Has anyone seen this before? And is there an easy way to fix it?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Okay, I resolved #2 by experimenting with the orientation of the import settings. It took three or four import attempts, but I finally found the combination that fixed the backwards images.
Still can't fix the invisible OBJs, but I will come back to that another time.
Edited to Add: I would provide the orientation settings, but I have a feeling that it is different based on the exported OBJs. In my case, I changed the first one to X, Y, and Z. Then changed the second one to one of the remaining ones. And just kept trying different combinations until it clicked. 3! = 6 different possible configurations, it wasn't as time consuming as it sounds.
The answer for the problem 2 is because not all 3d softwares use the self world reference axis orientation:
softwares like Maya put Y as the vertical axe (X and Z are the plain axes), while in 3D studio Max is Z (X and Y in plain).
For invisible parts maybe the problem is the imported material, you can fix it applying a new material to whole object or editing the imported one
Thanks, that's the train of thought that led me to experiment with the import functions. Previous imports I did today had the same problem, only I didn't notice because there was no text in the textures. When the text was there, I realized things were reversed. I was missing the forest for the trees by not going back to the import process to begin with.
I *kind of* noticed that the objects looked flat... but I just assumed that that was texturing changes I needed to make. In reality, it was the texture being inverted, so the bump maps were extruding / intruding the inside of the models.
I'm still puzzling through the invisible surfaces. Changing the surfaces themselves makes no difference, which is why I am thinking the exports might be the problem.
You are a genius...
I would have never noticed what the problem was if you hadn't sniffed out a place to poke.
For whatever insane reason, the OBJs were importing with Opacity set to 0. All of the other materials were fine, but Opacity was set at 0 across the board.
Once again I was looking for a more complicated solution and missing the obvious. Never had anything import like that before.
I see the reverse of that all the time in C4D: since Daz figures have an opacity slot, C4D brings them in with transparency active on all the textures (rather than alpha, which is where opacity maps should go).
The problem is actually more insidious than it seems. Notice that there is no rigid rotation to take you from one reference system to the other, i.e. you need a reflection. For DS to Blender, for example, the transform is x,y,z => x, -z, y
What is so bad about a reflection as opposed to a rigid rotation? It flips the normals. So you also have to know if the importer and exporter try to compensate for that, hopefully in ways that don't interfere with each other.
Man, universal support for USD cannot come fast enough.
Ugh. This is making my brain hurt... It all makes sense to what I have been seeing.
Let me see if this makes sense to anyone.
Essenentially, the OBJs have been importing "inside out." With no obvious reference, and not having made the original models, it was impossible to notice.
The symptom was that the models looked "plain" and "flat." I attributed this to texturing issues that I would have to manually resolve.
When I would apply DS shaders, things would look better, but never "great." This I attributed to low polygon models that needed custom maps.
The import process would come in one of two ways: inside out or inside out and flipped.
"Inside out" is actually over simplfying it as the models were also flipped, making the the inside out state seem normal because the textures were flipped. Kind of like if you have an inside out t-shirt, the design on it would look backwards. Except if you look in a mirror, then everything seems normal?
"Inside out and flipped" is how I noticed the issue because the text in the textures was mirrored. In essence, this was a half way correct import because the models weren't also flipped.
Now that I resolved the import configuration, the Normal and Bump maps are working properly. The models no longer look flat / low polygon.
Does this sound vaguely correct?
There are a few things to be aware of when importing 3rd party models into DS.
First one is that by default DS has "back face lighting" turned on, this means that unless the textures have writing on them then most have no idea the mesh is "inside out", or that it's been "mirrored".
Second is don't be surprised if none of the import settings in DS load the model "correctly", the export settings from the original program can really mess things up in DS, which always means extra work for us to get the mesh looking right.
As an example I have a truck here, the MAX and Blender presets load the model inside out and mirror the mesh, the headlights are also pointing out the back or the scene when they should be pointing out the front. The other presets load the mesh right side out, but the headlights are pointing out the bottom of the scene. Then there's the scale, in the real world the truck is 6.2 meters in length, yet none of the presets come even close, they are either tiny or huge.
So I'm either looking at rotating the mesh, scaling it (up or down) and translating it, or in the case of the MAX and Blender presets using a -100% on one scale axis to un-mirror the mesh, and then scaling and translating the mesh.
I then have to export it as an OBJ to lock those changes into the mesh (use the DS preset), then clear the scene and import the new OBJ (again using the DS preset), before I can save it as an asset.
Easy enough for me as I do this sort of thing all the time, but for most it becomes an unwelcome headache.
It sounds as if you're slowly pickin' the problem apart, but is there some reason you're not posting an image?
Those ARE called "Flipped Polys". Much easier to see that than decypher from just a description.
What program are you using to create the OBJs? There are settings that you probably need check (or uncheck) before exporting.
Nor does Daz recognize all settings, or recognizes some defaults differently.
All packages do that.
Here's how Daz handles it's own OBJ creation. It exports OBJ's and can re-import w/o much issue. Not sure if it was that way before; I'm usually only exporting out of Daz.
But there are other factors. When an OBJ gets exported, an .mtl file gets written too. They're just text files that give info for the mappig and map location. But, they can be in a different form that Daz won't recognize. Here's a clip of the .mtl that Daz exports:
newmtl Face
d 1
Kd 1 1 1
map_Kd ./Maps/FWSAPercyFace_1001.jpg
newmtl Lips
d 1
Kd 1 1 1
map_Kd ./Maps/FWSAPercyFace_1001.jpg
:
:
And an .obj export from from another app:
newmtl Arms
Kd 1 1 1
Ke 0 0 0
Ka 1 1 1
Ks 0 0 0
Ns 0
Tr 0
d 1
Ni 0
Tf 1 1 1
map_Kd DAZ Exports/./Maps/FWSAPercyArms_1004.jpg
newmtl Cornea
Kd 1 1 1
Ke 0 0 0
Ka 1 1 1
Ks 0 0 0
Ns 0
Tr 0.005
d 0.995
Ni 0
Tf 1 1 1
:
:
And Daz won't recognize that structure for mapping so nothing gets assigned.
I'd say you've got your brain around it perfectly, especially the distinctions between inside out, flipped, and rotated.
I avoid using OBJ wherever possible after 16 years of fighting with it, now I use FBX wherever possible and just don't have any issues of this sort at all any more.
Ugh. Okay. I was hoping that I wasn't right. A lot of questions in the recent messages, let me see if I can hit them all...
SOURCE: The OBJs I have been importing come from KitBash3D. So no control over how they were exported.
WHY: Previously I have been DLing the Blender files. I then correct the material references. Then export as a DAE. The models come thru... boring. I was thinking that it had something to do with the export, so I switched to trying the OBJs.
BORING?: I think this is a symptom of the reversed normals (I think). The "boring" factor appeared to have something to do with the materials. I would spend a lot of time tweaking the materials and had a modicum of success. Based on the OBJ experiments, I think this is the same "surfaces on the inside" issue. Where the Bump and Normal maps are being inverted and putting the surfaces on the inside. That makes them only barely visible.
SCREENSHOTS: I haven't been posting any because I didn't think there was much to be seen. And, honestly, I thought I might have been crazy in my observations; seeing issues where there weren't any. Or it was just operator error. Like an onion, it's gotten more complicated as I peeled.
FRUSTRATION: This is why I walked away from DS for a couple of months. It always seems like I sit down to work on something, then get wrapped up in non-productive technical issues. Friday started with the corrupted scene file that I spent hours on. I shifted over to do something that I thought would be simple; import my newest Kitbash files. That turned into a thing all its own.
Up until the "backwards text" I just assumed that it was my eye and I was being overly critical. Or that the models were just not suited for DS... The text issue clued me in on what I thought was going on.
Oh dang, I really do not recommend taking on 3rd party OBJs sight unseen, especially for complex models. So much harder to fix anything in that state than whatever you might get in a blender file. This is not a fault in D|S, you would have problems like this trying to take 3rd party OBJs with any app. For one thing, if you are getting OBJ from different individual creators even from the same broker, it is entirely possible that they'll be using completely different OBJ exporters with their own ideosyncracies of surface naming, normal handling, edge break handling etc.
If you're already fairly comfortable with Blender, imo try using FBX export.
e: also maybe see if you can obtain FBX versions of the models you already bought, a lot of creators post in multiple formats.
Your concerned are true, but in this case not as big an issue.
The KitBash files are EXTREMELY consistent. The exports are almost always the same in configuration. The surface names are minimized across the models and consist across multiple products. The textures are all consistently named as well.
As far as 3rd party models, these are these easiest I've found to work with in years.
The designs also provide a lot of themes are are poorly represented at other stores. I also like having a full set of structures that are consistent in theme and textures. I hate when I only have a handful of buildings and can't use them with any other products because they stick out like sore thumbs.
That being said, I am going to give the FBX option a try. I think there may even be native FBX files. KB offers their models in a bunch of different native formats.
The only thing I'm aware of that D|S is really anal about forcing you to use OBJ for is importing morph targets, I'm pretty sure you can use FBX for everything else.
These are all static structures, buildings and such, so that shouldn't be an issue. I am going to give the FBX route a try tonight.
"SOURCE: The OBJs I have been importing come from KitBash3D. So no control over how they were exported."
Ah. I didn't want to confuse the issue with KitBash. I've picked up a couple In FBX\OBJ format. It uses both.
Notice how the mtl uses \\ to delineate file names. In a text editor I did a simple search and replace, flipped the \\ to // and I could then import with the mapping assigned.
# Blender MTL File: 'KB3D_MidManhattan-Native.blend'
# Material Count: 61
newmtl KB3D_MIM_AsphaltRoofDBlue
Ns 225.000000
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.800000 0.800000
Ks 1.000000 1.000000 1.000000
Ke 0.000000 0.000000 0.000000
Ni 1.450000
d 1.000000
illum 2
map_Bump KB3DTextures\\KB3D_MIM_AsphaltRoofDBlue_normal.png
map_Kd KB3DTextures\\KB3D_MIM_AsphaltRoofDBlue_basecolor.png
map_Ns KB3DTextures\\KB3D_MIM_AsphaltRoofDBlue_roughness.png
refl KB3DTextures\\KB3D_MIM_AsphaltRoofDBlue_metallic.png
...
But those are still for node based materials and I don't think you get options for that.
Assigning the materials hasn't been too much of a headache since the files are named so consistently. It's time consuming, yes, but not too bad if I do the entire OBJ file at once. I like that the surface names are consistent across all of the figures in the model. That speeds things up considerably.
Most of the time the basecolor texture comes across with no issue, except for the base color actually showing a color. So swapping that to white in mass is easy enough.
The normal file tends to end up in the bump channel, so flipping that over is easy enough as well.
The other textures are on a case by case basis since there are usually only a handful.
The main dysfunction I was having is that the models were coming over fake looking even after the shaders are updated. So far this seems to all be associated with the Bump / Normal maps and the affects appearing on the inside surfaces.
It all depends on what you're needing to do, and if that works ...
Out of Daz, I routinely export both. I've had never had much to luck importing, at least so far. See what ZBrush does to the workflow after I bite the bullet & spend some time learning.
I use FBX on "Organics"; usually characters with and animals with morphs as OBJ's don't have that ability. "Inorganics" such structures or is mechanical, are often much easier to work with and lighter in file size.
Yeah the only thing I've found that OBJ is necessary for is importing morph targets (and it's a bit baffling that DAZ has not added FBX morph target import tbh)
Here I am, falling down the rabbit hole of DS technical issues again...
I took your advice and editted the MTL file to change the \\ to //, but that made no difference as (for the most part) DS was finding the textures. (It probably has something to do with where I unzipped the package.)
However I noticed that DS wasn't seeing most of the textures. And the Normal texture was still appearing in the Bump map.
Using your advice as a springboard I delved a little deeper into the MTL file and found:
map_Bump KB3DTextures\\KB3D_MIM_ConcretePolishBlocksGray_normal.png
map_Kd KB3DTextures\\KB3D_MIM_ConcretePolishBlocksGray_basecolor.png
map_Ns KB3DTextures\\KB3D_MIM_ConcretePolishBlocksGray_roughness.png
refl KB3DTextures\\KB3D_MIM_ConcretePolishBlocksGray_metallic.png
"Oh, there it is. This should be easy to fix." > Famous last words.
I tried doing the obvious map_Bump to map_Normal. Nothing.
Okay, DS calls it something other than Normal.
I went back into DS and created a simple cube. I added texture maps to the Normal, Diffuse Roughness, Bump, Metallicty, and Emissive channels. I then exported the cube as an OBJ.
I figured this was the easiest way to find out what DS was calling those channels.
I found that the only texture / channel that DS exported was the Base Color:
map_Kd ./Maps/KB3D_MIM_AsphaltRoofDBlue_basecolor.png
WTF? Is this normal? And if it can only export that one texture, then most likely its not capable of importing anything else either?
I personally would rather not touch .mtl files by hand ever, that is the most tedious and error prone way to review and fix material problems I can imagine, especially since you're going to have to review the materials in each of the iray surfaces at the end. This isn't particularly a fault of DAZ|Studio.
MTL files I can deal with. They remind me of XML files. I've dealt with those for so many years my mind sees them as English now.
But it irritates me if the source MTL file has all of the surfaces defined and DS is disregarding them. There must be some sort of naming convention that DS is looking for and not seeing.
A naming convention would mean that a Search / Replace would fix it in seconds.
that naming convention may be different from model to model and from individual content creators, and in the end you're still going to have to tinker with and tweak your iray shaders anyway. reviewing your original post, this is what happened in the first place (you got a model that for whatever reason had a different set of obj import/export minutiae from what you were used to). I don't want to just keep harping on this but imo this labor of manually editing .mtl files is super unproductive, when you have the option of using a much less idiosyncratic import/export.
I don't mind the harping, but you're actually starting from a false premise.
Almost all of the KitBash models are named consistently. So it doesn't change from model to model. Even just editing a single MTL file is easier than the individual click and find that DS requires to change each channel map.
Every Kitbash texture is named consistently; Set_Type_Subtype_MapType. so MM_MetalGray_BaseColor, etc.
It's much easier than the typical Blue, NotQuiteBlue, SortofBlue guessing game that a lot of image maps are named.