How to import .OBJ?
I thought I knew how to do this, but clearly I don't.
Ok, I got a file at ShareCG.
(this is the specific one, but Im looking for general info http://www.sharecg.com/v/49600/)
It unzips and gives me a obj and a mtl file with the same name, in the same folder
crow t robot color.mtl
crow t robot color.objI go to Import, selelct the OBJ file...there are checkmarks next to the "read surfaces" "read material library" options..
I get the model, but it's grey..no materials on it.
So..am I doing something wrong?
(I want to have a discusion on the convert from/scale options at some point too, but that can wait)
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Well...
I've got one program that does bring it in, in color...and everything else ignores it.
Well..that was cryptic....
PropViewer3.2 shows it in color, but saving it back out zeros the materials, so it's kind of useless. \
All the material file is, for this one is a couple of colors on the named material zones. Also, it's not UV mapped...
It might be that Studio is having trouble reading the mtl. I don't know what's needed, but I know I worked on a project once and Studio only read the textures when my client outlined how to specifically do the .mtl.
Here's one of the materials from the mat file...
newmtl black
Ka 0.001000 0.001000 0.001000
Kd 0.001000 0.001000 0.001000
Ks 1.000000 1.000000 1.000000
Ns 100.000001
Ni 1.000000
illum 2
d 1.000000
DS should be able to handle that with no problem. There's 5 materials and all of them are that simple.
So.....my procedure is fine? I'm importing correctly?
i'm afraid the discussion has gone quite a bit over my head as far as my understanding of any of this goes.
Yes, it is coming into DS as best as it can...without color.
There's nothing complicated in the material file that should prevent DS from reading/applying the color information. It should work, but it doesn't. I can't even get it to read in Wings3D, which was what it was created in, without throwing an error. I've tried saving it out in the programs I have that do bring it in colored, but they save it out with either no materials or 'default' which is usually a medium to light grey or white. The nice thing is, the geometry is sound, so it should save colored, if you manually color it, in DS, especially if you save it as a prop file.
Here's the colors
Foam Black 70 70 70
Black 0 0 0
Gold 131 131 0
New Material 255 255 255
PingPong 255 255 87
Those should be close enough to not matter. Use them in the Diffuse color, on the surfaces, for the named materials.
DAZ often loads stuff grey while Carrara, Poser and iClone 3dx5 will all find the textures even if on another drive.
So long as paths are in mtl file.
If they cannot find them at least Poser and Carrara will ask you to browse for them.
DAZ does not, just loads it grey
just a quirk of studio obj import
needs a specific mtl file set up the others do not, having textures in same folder as obj often helps
I find exporting as Bryce format only way to get DAZ to load its own exports coloured and textured.
Maybe study a studio exported mtl file and see what is different in notepad where it is looking for the files.
I looked at that model
there are no maps
but the surface tabs have the names of the materials so I guess were procedurals for the original program
you need to use DAZ equivalents
Even worse...the mtl specifies just Kd...straight up colors!
It shouldn't even blink when loading them, but it doesn't load them in DS or about half the other ones I tried...Blender, yes, but that saves out blanks. Wings3D...nope, MisfitModel...nope, K3d...haven't tried. PropViewer3.2...yes, but saves out blanks. Don't have Hex installed, currently...
*****
Doing the colors manually and saving him out in DS works perfectly...
To hell with the movie, let's just tap those kegs...
It's just DS being a fussy **** as usual, it doesn't like spaces in names so it's not seeing the .MTL files to load them.
Replace the spaces in the OBJ & MTL names with an underscore "_", then open the OBJ in a text editor and change the lines near the start of the file-
mtllib crow t robot color.mtl << becomes >> mtllib crow_t_robot_color.mtl
mtllib tom servo.mtl << becomes >> mtllib tom_servo.mtl
They should load for you after that.
Yep...but it isn't DS only. The others on my list suffer from the same thing.
But, I wonder, is the "_" in the name actually part of the original spec? If so, that means DS is being spec compliant and would explain some other weird behaviors, since the Wavefront obj spec is about as old as dirt...
Shouldn't the colors be #values or RGB or something anyway?
The values in 0.xxxxx format are perfectly legit. DS and all RiSpec renders understand that format. It's just a variant RGB, based on 0 being black and 1 being white, typically used in writing shaders.
Something else for consideration — the first non-comment line in the .obj file should be the folder path/filename of the matching .mtl file. If there are textures in the material definitions, they're all in folder path/filename format as well. If your actual file names and locations relative to wherever the .obj file is don't correspond to this data, then D|S can't read them when it imports the .obj file. The result of this is that your .obj could import properly coloured and textured, or it could have no textures, or it could be all grey or randomly coloured, depending on how confused D|S is about the precise format of the data in the files.
I've come across this fairly often; there's a furniture freebie maker over on Renderosity I always look out for, and their textures are always in a subfolder relative to the obj/mtl pair. I always have to edit the .mtl file and check the .mtl file reference in the .obj file. Once I've done that and copied the files into my content folders, the meshes always import properly coloured and textured. Before I learned this, importing any mesh object was always a coin-toss, because there are so many programs capable of saving an .obj file, and not all of them do it the same way as D|S is expecting.
This is a thread to note as I have a bunch of .obj files I've yet to try out and this information will more than likely come in very handy!
Not sure if it's DS being "spec compliant", or if it's the importer code being so damned tight that you couldn't get a sheet of paper between it's butt cheeks.
It's not the file name so much as the pathway in the file that's the problem, DS has never liked spaces in pathways, take the tom servo.obj, on line 7 you have mtllib tom servo.mtl, this is the pathway to the MTL. What DS actually sees is mtllib tom, as far as DS is concerned the space between tom and servo is the end of the pathway so it ignores the rest of the line.
Now with a Poser file I would have just said add a " to either end of the problem pathways, as that's the "proper" formatting, but I don't know the formatting for pathways in OBJ, so replacing the spaces with underscores is the easiest way.
Wendy there are two sets of RGB values, one gives you access to 16 million colors, while the other has billions of colors. The 0 to 255 you see in DS is the 16 million color version, while the billions is the one Wavefront (and Poser) uses, it runs from 0.000000 to 1.000000. DS probably does the same with those as me, multiply the number by 255 and round up/down the result depending on what side of .5 it comes out at.