Problem with Materials when Exporting objects to Blender
1. Simple mesh
I tried exporting a rock from one of the Nature packs from a fresh install of DAZ Studio 4.9n and got some anomalies. The only formats that Blender accepts from DAZ are fbx, dae and obj, although it ignores the mtl file. According to how Blender sees it, the normals are inverted on the dae and obj meshes in the scene below. I wrapped my own material, the exact same material, the exact same quick and dirty UV mapping. The dae object comes up quite well, but the obj is black, a piece of soft coal. That black thing is uv mapped, but it's not reflecting any light at all! Flipping the normals made no difference.
It got worse when I tried to export DAZ Horse 2 into Blender. The fbx file was a disorganized mess of parts and rigging bones. The obj was once again a soul-absorbing black. The dae came through fine for materials (well, it wasn't black but I had to manually set up the node trees) ... but without the pose.
No baking was involved in these exports.
What am I doing wrong?
Comments
I use these .obj export options in DS an have no problem in Blender.
Sorry, those settings made no difference for me. I exported a primrose using your settings, then brought it into Blender and assigned basic colors to the materials.
That's what it looks like through the viewfinder. And here's the render:
That's rendered with a sun set to a decent strength, right overhead.
Which version of Blender?
I haven't had any problems...I'm still using 2.76b and haven't had problems with it and any before that, except something before 2.49.
I'm using 2.78a on an MSi QE62 Apache Pro -- 16 GB RAM and an NVidia GTX960M GPU.
it took a while to get back to you because I've been running some tests. I can get a coherent renderable mesh if I export the obj with original maps,open it in Bryce, export it as a 3ds, and open the 3ds file in Blender! If I export the obj out of Bryce as an obj file, Bryce barfs but soldiers on:
So there is a workaround. Good old Bryce.
Okay...try this.
Go grab my lunchbox
http://www.sharecg.com/v/86567/gallery/21/DAZ-Studio/Lunchbox
Then export the cup. See if it imports to Blender...if not try the attached file (it's the same cup, as exported from Blender, before I imported it to Studio)
For .fbx import in blender 2.78, uncheck all options in the import file window, especially the bottom one(pre-rotate or something like that. That's the one that twists the model all up. You can fix it though by going into pose mode and clearing all pose transforms.). If you're working in cycles in blender, the fbx importer is the only one that imports materials for cycles.
Also for obj export from DAZ use 1% for the scale. Daz default unit is centimeters, and the default in Blender is meters. Fbx and Dae both get the unit conversion "nearly" correct.(Dae exports all characters at the same height ~5'11")
In the daz obj export, if you have 1 or all 3 of the "invert positive direction" boxes checked it will flip the normals inside out.
Hi, forgive me but this is not quite correct
To the thread starter:
Hello, you seem to trying to export props from Daz studio to render stills in blender.
If so my question is... why bother with FBX at all??
the FREE MCJ teleblender script will send your Daz scenes to blender
with all materials converted to cycle nodes.
The attached image is of some props I tossed into a Daz scene and
ran the teleblender export script.
This may save you alot of time and frustration
Point taken. I was not familiar with that script. I was speaking about the default export/import options.
The error in the output, "ValueError: could not convert string to float: b'1.#QNAN0'", indicates that the OBJ file contains data that blender isn't expecting. That could be as a result of bad geometry in the model within DS, an error in DS's OBJ exporter or an issue with blender's OBJ import script.
You might be able to fix it with a quick edit in a text editor. I've had to do that sometimes with OBJ exports from at least Garibaldi, possibly LAMH as well, as the OBJ files contained similar garbage.
If you don't want to use mjc's Teleblender I'd just do a global search and replace of "#QNAN0" with "0" (0 is digit zero in both strings), save the file and then import into blender. If that fixes the problem, there are various ways of automating the search and replace if you need to do it frequently enough that you'd benefit from automation.
Hi everyone, thanks for the comments and suggestions.
@mjc1016, I have successfully imported obj and 3ds files from other venues, although Blender simply doesn't recognize .mtl files. I've learned enough about cycles and the node editor to rebuild the materials from maps (or else roll my own).
@skpfx, interesting about the checkboxes for "invert positive direction"; I will look into that as soon as I have a chance to get back to the apps.
@Wolf359, yes: I like to make my own stuff now that I'm getting into Blender, but I have a repository of ready-made stuff from Daz that I want to port into my own scenes. Flowers, animals, other props... I'll gladly look into the script you suggest if I can link the desired props into my own scenes.
I'll post results later today.
Hey zaz, we simulposted. I appreciate your explanation of the error message I got from Blender; your suggestion is just a little bit above my Blender skill level, though. I am a (long) retired programmer, but I haven't yet tried to learn Python -- the box modeling and other stuff has been too damn much fun! I will however come back to this.
That's why I suggested the lunchbox...you could compare the obj from 'before' Studio and the one that is exported from Studio.
No blender nor python knowledge is required to implement the fix I mentioned.
OBJ files are simply text files and the OBJ file you tried to import in blender had data in it that blender didn't expect and didn't recover from.
The unexpected part of the input was the "#QNAN0" after a "1.", probably on a vertice of some sort. It is simply bad data and blender is blowing up on seeing it. That should be a normal floating point number, i.e. something like "1.0" or "3.1459" , etc. If you look through the file, you may only see the one instance of #QNAN0 or many of them.
No python would be required to manually fix that problem, just a text editor to edit the OBJ file before you import it into blender. I use Notepad++ or Emacs under windows, but any decent text editor will work. The editor simply needs to be able to deal with potentially large files and have a basic search and replace function.
So, grab a decent text editor, load the OBJ file and replace all "#QNAN0" strings with "0" (again digit zero in both quoted strings).
A bigger question is why are you getting bad data in the export. It might mean that you either have bad data in the model within DS that you're trying to export or there's a bug in DS's OBJ export that you're tickling for some reason.
#QNAN0 might imply a divide by zero. Do you have an object scaled to zero that you're trying to export ?
BTW, the black render you show in your second post simply looks like a lighting issue. That plant is huge relative to blender's normal expectation of size and there is either no, or a very minimal, light source in your scene or its hidden inside the geometry of the plant. Try scaling it down to 1%, yes to 1/100th of its size, and render again.
Blender units are fluid as they have no fixed real world size, but a common paradigm is to consider 1 blender unit equal to 1 meter. DAZ Studio's units are normally considered to be 1 centimeter.
skpFX's comment about checking the "invert positive direction" boxes has fixed the problem! Of the suggestions given here it was the first thing I tried... because it was the easiest to implement. And when I checked all three boxes, in addition to Ben98...'s configuration, the mesh rendered quite nicely. Thank you all, ladies, gentlemen, and entities, for helping me sort this out.