Hi all, I'm having an odd problem with the camera positioning and/or focal length when exporting from Daz to Blender.
I only noticed it because I was using Freestyle lines to lay on top of my Daz render. The two renders didn't line up, so that sent me down the rabbit-hole.
As far as I know I hadn't changed anything that might cause this. I'm using TeleBlender v15 and BlendBot v16 with Daz 4.9.1.30 Pro (64bit) and Blender 2.78 on the Mac.
You can see my test renders from both Daz and Blender here:
In Blender the camera seems to either zoom in or just move a little closer to the object.
My camera settings between Daz and Blender are close, but not exact. I think that's normal between the two programs, though.
At first I thought it was the discrepancy between the focal length settings, but after experimenting I found it was easier to get closer to the Daz shot by just bumping up the Sensor size a little.
In this case from "32.00" to "32.90". Now here's how the Blender render turns out:
So that's pretty darn close. With that change to the Sensor size, I was able to render my Freestyle lines and get close enough that it wasn't noticeable in Photoshop.
Also, here's my TeleBlender settings out of Daz. I can't see anything in there that would cause this.
Is there a setting anywhere I can use to permanently fix this? I expect most people aren't going back to Daz after exporting to Blender, so this may not be a high priority issue.
Please let me know if anyone has any questions or suggestions.
Hi all, I'm having an odd problem with the camera positioning and/or focal length when exporting from Daz to Blender.
I only noticed it because I was using Freestyle lines to lay on top of my Daz render. The two renders didn't line up, so that sent me down the rabbit-hole.
so if you change the daz studio camera "Frame Width" to 35mm it should be near pixel-perfect
next time i update the Teleblender script i'll try to remember to make it automatic
Sorry about dropping this, I got caught up in some IRL stuff.
But anyway yes that worked perfectly. When I changed that Frame Width setting now the Blender render lines up perfectly with the Daz Studio render. Thanks much for the fix on that.
I finally got around to trying this script on my PC (I used to use a Mac which tended to be very slow).
I have probably forgotten all I used to know about it but I believe the script has changed significantly since I tried it more than year ago. But now, on the PC, I have tried to follow the examples of the options used to export the scene and some of my materials are coming out as purple. Attached is an example. I've also attached screen shots of my export settings. Any help would be appreciated. The scene was set up using IRay materials in case that is significant. I have tried the CPU and also the GPU (CUDA) options.
It would be great if mcjTeleblender could work with IRAY materials!! However, I am pretty sure that it cannot, since (last I looked) it could only use .obj file materials.
It would be great if mcjTeleblender could work with IRAY materials!! However, I am pretty sure that it cannot, since (last I looked) it could only use .obj file materials.
Well, that's what I thought too but I asked in another thread and this was the answer from Wolf359:
Hi it depends on what you consider a true "IRay material"
100 percent Iray procedural materials such the free metals and opaques ,emissives,cloth,rubber etc, that come pre installed with DS 4.8 or higher will not be properly converted by the teleblend script.
But that is not a problem for me as I prefer the native PBR shaders of blender for such non organic materials anyway.
However most of the so called "IRay" versions of newer content such as Hair
skin,clothing and props apparently are still image based and I assume
"Converted" for IRay as they convert just fine to Blender cycle nodes.
The Stonemason Tuscany set image I posted earlier was the"IRay" version.
According to that, the skin should be ok. I tried another render with some different clothes and they came out purple too. If I have to configure all my scenes with 3DL materials (assuming they are available) then IRay is going to be much less work and much quicker for me so there is no point in exporting to Cycles.
I finally got around to trying this script on my PC (I used to use a Mac which tended to be very slow).
I have probably forgotten all I used to know about it but I believe the s
Hi there
The magenta/purple color usually means that Blender could not find one of the texture images
the image filenames and paths are tranfered to Blender from Daz through the .mtl and .py files that are found in the same folder as the .obj file
( so one could look in those files using notepad and look for weird filenames or paths )
usually the fact that you check-marked the "collect maps" option in mcjTeleBlender helps reduce that sort of problem
sometimes the issue is that the .mtl file specifies something like mytexture.tif and the "collected map" is in fact "mytexture.jpg"
the other options affecting the success of this are the "Fix .mtl .... " and the "no quotes in mtl paths"
which are okay in your screen captures
note that the fact that we can see the bearded texture means, that those 2 options are not at fault
-----
now about the iRay materials and other "real" shaders like that
i did valiant efforts to adapt the code so it can extract the same surface properties that i get from the DsDefault material/shader surfaces
but it can fail, notably when subsurface scattering is involved
For mcjTeleBlender those neat iRay shaders are a nuisance. Also, when TeleBlender doesnt really export .obj/.mtl files, it asks Daz Studio to export them. And event there the nifty iray shaders cause problems.
so, ideally you could select all the surfaces in the figure and apply the "shader" named DsDefault, which on my Daz Studio is located in Daz Studio Content/My Daz 3D Library/ Shader Presets / Ds Defaults
then readjust the materials until you get something that looks good when transfered to Blender
the save the set of materials as a Material Preset file (in Daz studio)
=====================
well just to make me lie, i tried a render right now and i had to turn "collect maps" off to get it to render
i'll see what's happening and tell you
oops false alert, the problem was that i used an old version of mcjTeleBlender
the important option was "No leading / in paths" i'll post my settings and the render in a minute or 3
the red iRay velvet color on the chair failed the transfer process
Ok - I think I have an idea why this might be happening but I know very little about the technical details so I could be wrong.
I use a recent product from the DAZ store called Scene Optimizer. This creates smaller texture sizes so that the GPU VRAM is not used up so quickly. As I say - I don't know the details of how or where these are stored and referenced but I suspect that it doesn't play well with your script.
As I understand it, Cycles has the same problem with VRAM that IRAY does so if I go back to using full-sized textures so that I can use Cycles, I can only render smaller scenes. My only reason for wanting to try Cycles was to try to cut the render times. However, the Scene Optimizer does just that in a way because scene load times are much faster - especially if there are any LIE textures in the scene (and I use them quite a lot).
Ok - I think I have an idea why this might be happening but I know very little about the technical details so I could be wrong.
I use a recent product from the DAZ store called Scene Optimizer. This creates smaller texture sizes so that the GPU VRAM is not used up so quickly. As I say - I don't know the details of how or where these are stored and referenced but I suspect that it doesn't play well with your script.
As I understand it, Cycles has the same problem with VRAM that IRAY does so if I go back to using full-sized textures so that I can use Cycles, I can only render smaller scenes. My only reason for wanting to try Cycles was to try to cut the render times. However, the Scene Optimizer does just that in a way because scene load times are much faster - especially if there are any LIE textures in the scene (and I use them quite a lot).
what i do sometimes, in scenes that contains 20 4000x4000 pixel texture images is, i set mcjTeleBlender's "collect maps" option on
i close blender
then i go in the "Maps" subfolder in the folder where teleblender exports the scene as .obj/.mtl/.py/.bat
and i resize all the big ones down to 1024x1024
then i use the scene's .bat file to re-launch and re-load the scene in Blender
---
but remember that some of the texture images did get properly transfered to the blender scene since the figure had its skin/bearded face texture
the missing texture was probably on a channel of the iRay shader that mcjTeleBlender interpreted as being, say, an ambient color map
and when the Daz Studio exported this scene as an .obj/.mtl, it didnt "collect" that map for some reason
but mcjTeleBlender did "tell" blender to import this image, which it said, should be in the /Maps folder
"As I understand it, Cycles has the same problem with VRAM that IRAY does so if I go back to using full-sized textures so that I can use Cycles, I can only render smaller scenes. My only reason for wanting to try Cycles was to try to cut the render times"
Even with these ridiculous 4k textures your rendertimes will be signifigantly shorter
with Cycles in my experience.
There is something about IRay being so purpose built for NVidia Cards that its performance falls of a cliff with non Nvidia cards.
Cycles is GPU agnostic and does not seem to so quickly curl up and die when it cant find its NVDIA built"mommy"
"As I understand it, Cycles has the same problem with VRAM that IRAY does so if I go back to using full-sized textures so that I can use Cycles, I can only render smaller scenes. My only reason for wanting to try Cycles was to try to cut the render times"
Even with these ridiculous 4k textures your rendertimes will be signifigantly shorter
with Cycles in my experience.
There is something about IRay being so purpose built for NVidia Cards that its performance falls of a cliff with non Nvidia cards.
Cycles is GPU agnostic and does not seem to so quickly curl up and die when it cant find its NVDIA built"mommy"
Well, surely that's because IRay will default to CPU if it doesn't find an NVidia GPU and IRay in CPU mode is, as we all know, glacial. Before I bought a PC with an NVidia card I used Reality/Luxrender in CPU mode and despite what some people say, I found it to be much quicker than IRay in CPU mode. It had other problems though and the time I took tweaking materials could negate any time saved on rendering. I'm afraid that migtht also be the case with Cycles and the scary node system doesn't encourage me to dive into that daunting task. Especially if, as mCasual suggests:
ideally you could select all the surfaces in the figure and apply the "shader" named DsDefault, which on my Daz Studio is located in Daz Studio Content/My Daz 3D Library/ Shader Presets / Ds Defaults then readjust the materials until you get something that looks good when transfered to Blender
So that means a lot of switching back and forth between Blender and DAZ Studio and doing multiple test renders ... sorry but it seems to me that any gains in render times would almost certainly be wiped out (and then some) by the time taken to tinker with the materials.
…I believe the script has changed significantly since I tried it more than year ago…
Right. Two more things that have, in this context, changed dramatically this year are
(a) the speed of Cycles: it was fast; now, it’s like, wow!;
(b) the .fbx transfer from DAZ Studio to Blender: it’s very “delicate” and still has some glitches,
but I can transfer a figure, polished, in less than an hour (as opposed to getting a horrible mess).
Interestingly, the .fbx transfer, from, say, DS 4.9.x to Blender 2.78+, automatically converts
DAZ materials to Cycles nodes, in a manner almost identical to the Téléblender procedure.
The following image is a G2f character textured with SkinBuilder for Genesis and G2f,
and I’m not aware of any iRay-specific tricks
(although DS can give me iRay in the Viewport, no problem, all CPU; slow, of course).
On the viewer’s left is the character transferred with .fbx; on the right, with .mcj;
(24 second render on a 4 GHz Intel Core i7 iMac, 8 CPU, no CUDA). I was hoping
that the ears would show a bit of translucency, so, either way, I’ll have to ad that myself.
[Ugly? Okay, but they’ll look a lot prettier with “real” hair and stuff!]
…I believe the script has changed significantly since I tried it more than year ago…
Right. Two more things that have, in this context, changed dramatically this year are
(a) the speed of Cycles: it was fast; now, it’s like, wow!;
(b) the .fbx transfer from DAZ Studio to Blender: it’s very “delicate” and still has some glitches,
but I can transfer a figure, polished, in less than a hour (as opposed to getting a horrible mess).
Interestingly, the .fbx transfer, from, say, DS 4.9.x to Blender 2.78+, automatically converts
DAZ materials to Cycles nodes, in a manner almost identical to the Téléblender procedure.
The following image is a G2f character textured with SkinBuilder for Genesis and G2f,
and I’m not aware of any iRay-specific tricks
(although DS can give me iRay in the Viewport, no problem, all CPU; slow, of course).
On the viewer’s left is the character transferred with .fbx; on the right, with .mcj;
(24 second render on a 4 GHz Intel Core i7 iMac, 8 CPU, no CUDA). I was hoping
that the ears would show a bit of translucency, so, either way, I’ll have to ad that myself.
[Ugly? Okay, but they’ll look a lot prettier with “real” hair and stuff!]
Looking at the two images, I'm guessing that neither transfer method handles transparency/opacity? Is that a problem with the transfer or Cycles? Obviously you wouldn't want a finished render with such eye lashes yet I notice with many of Casual's Aiko renders in this thread and on his site - the hair is left as solid ribbons. Just has me wondering if it is a really difficult task to render hair, etc.
By the way, what do you mean by "polished"? An hour just for the actual transfer seems a long time but I have no experience with FBX.
…Looking at the two images, I’m guessing that neither transfer method handles transparency/opacity?
Is that a problem with the transfer or Cycles?
Transparency per se is not a problem; if it were, the cornea of the eyes would be messed up.
SSS (sub surface scattering) exists in 3Delight, iRay, and Cycles, but I’m not sure that’s coming across.
With respect to the ears, I’ll do a trick on the Cycles side.
Cycles gives me great confidence: it is SO programmable!
…Obviously you wouldn’t want a finished render with such eyelashes…
The .fbx version’s eyelashes are of the “piggy” variety, and very close to what I was aiming for.
They are implemented by standard (and vintage) DAZ technique. Oddly, .mcj went astray on that.
Eyebrows and hair, I intend to accomplish with Blender “hair particles”;
then, of course, I have a small collection of Blender-modeled horns, waiting to be fitted.
Oh yeah: once a DAZ-origin character of mine makes it over to Blender, she ain’t going back!
By the way, what do you mean by “polished”?
An hour just for the actual transfer seems a long time but I have no experience with FBX.
The transfer itself takes seconds; the better part of an hour is me, preparing last-minute details on the DS side,
then fussing over glitches in the armature, on the Blender side.
Next, I intend to try the Khalibloo Panel, to convert the DAZ armature to Pitchipoy Rigify,
which has a face rig and controllers to define expressions and visemes.
June 15: Okay, the Khalibloo does a wonderful and ingenious job of fitting a Rigify rig
to your figure, but not the Pitchipoy version, so, no face rig. Plan B: stick with the G2f rig defined by DAZ, which, on the head,
has a bone for each eye, one for the lower jaw, and seven for the tongue,
and supplement that with a handful of expression morphs, which —hallelujah—
the .fbx export/import, now, is able to transfer (and they show up as shapekeys in Blender).
[Yes, I gave G3f another try, and again, I’m sticking with G2f.]
Fig3. Tada ! the same scene but before running teleblender i ran a script that renames all figure-owned materials with names like "Fig1_skin" ... "Fig2_skin"
i will add the functionnality to teleblender in a few minutes and will post the announcement below
after teleblender exports the scene, i will re-rename the figure materials back to their original names
( in case it would break material preset abilities to leave those new material names )
First: thank you so much for looking into this problem so fast!
Second: I'd like to make two comments about this issue.
1. I believe this is a bug in DAZ 4.10. In previous versions, when two figures shared material names the OBJ would have renamed materials like Fig1_Mat1 and Fig2_Mat2. However, now the second figure doesn't get a material name at all (if you open the OBJ file, the second figure will have an empty "usemat" tag). This can be reproduced by simply exporting a scene with two figures sharing the same material names -- no Teleblend needed. I think we should file a bug against this so that the good guys over at DAZ fix this.
2. I haven't checked your fix; but I would argue that we do *not* want the materials to be renamed back to their original names in Blender. The reason is that in Blender, material names exist in a global namespace and material names in DAZ are local to the figure. In other words -- if I understood correctly -- your fix will rename materials to Fig1_Mat1, Fig2_Mat1 and so on and then rename the materials back to Mat1. I think we do *not* want the materials to get their original names.
To illustrate why imagine two figures, male and female. Let's say G3F and G3M. They will both share the same material names but they would have very different textures. If both figures share the same material names in Blender then we will end up with all the materials from G3F applied to the G3M or viceversa. I think we want to keep them separate.
Anyway, I may be completely wrong in my second point since -- as I said previously -- I haven't checked your fix. But I just wanted to put this idea out there.
when i say i restore the surface names to their original names , i mean in Daz Studio, not in Blender
Blender will receive uniquely named materials. Note that if you looked in the .mtl files before, you could see the duplicated material definitions were corrupted
First: thank you so much for looking into this problem so fast!
Second: I'd like to make two comments about this issue.
1. I believe this is a bug in DAZ 4.10. In previous versions, when two figures shared material names the OBJ would have renamed materials like Fig1_Mat1 and Fig2_Mat2. However, now the second figure doesn't get a material name at all (if you open the OBJ file, the second figure will have an empty "usemat" tag). This can be reproduced by simply exporting a scene with two figures sharing the same material names -- no Teleblend needed. I think we should file a bug against this so that the good guys over at DAZ fix this.
2. I haven't checked your fix; but I would argue that we do *not* want the materials to be renamed back to their original names in Blender. The reason is that in Blender, material names exist in a global namespace and material names in DAZ are local to the figure. In other words -- if I understood correctly -- your fix will rename materials to Fig1_Mat1, Fig2_Mat1 and so on and then rename the materials back to Mat1. I think we do *not* want the materials to get their original names.
To illustrate why imagine two figures, male and female. Let's say G3F and G3M. They will both share the same material names but they would have very different textures. If both figures share the same material names in Blender then we will end up with all the materials from G3F applied to the G3M or viceversa. I think we want to keep them separate.
Anyway, I may be completely wrong in my second point since -- as I said previously -- I haven't checked your fix. But I just wanted to put this idea out there.
OK, nevermind then. I still think we should file a bug against DAZ, though; because this is an issue with exporting OBJ files -- not with Teleblend. But thanks for fixing this for the rest of us mere mortals here!
Say mCasual, I have a questions regarding a few things:
First one I have is about morphs (I apologize if this has already been answered before), but is there a way to get it so that DAZ imported morphs have the same slider values in Blender as they do in DAZ? I only ask because I've experienced some problems regarding facial morphs when it works only in one direction and not the other.
Secondly, is it possible to bring over all the materials used in a DAZ scene over to Blender? I've tried it with one of my characters, but noticed that the materials don't follow suit, only the textures. This character btw is supposed to have slightly tanned skin that I came up with by tweaking the material properties of the model itself.
if the scene was exported/imported through teleblender it has no morphs no skeleton so i suppose you did the export/import through fbx or collada
i have a general idea of how this could be done but dont plan on writing the blender script to do this sorry. I didnt see existing scripts to do this
but i dont follow activities in the blender world, maybe if you search in the big blender forums for words like "morphs" and "combine" or "unify"
if you use mcjTeleblender to export the daz scene, all the materials should be in blender
The main purpose of teleblender is to transfer a frozen daz scene to blender and convert the materials into the type of materials that Blender wants ( ex: cycles materials )
in all versions of Blender, except 2.79 i think, when you exported a scene from Daz using Daz Studio's built-in exporter and imported it in Blender "manually", the materials for the Cycles renderer we basically blank ... that's why teleblender was created
with Blender 2.79 the obj importer now creates usable cycles materials, but not as good as the Teleblender ones , because teleblender transmits to blender more of the material parameters like tiling for instance
Say mCasual, I have a questions regarding a few things:
First one I have is about morphs (I apologize if this has already been answered before), but is there a way to get it so that DAZ imported morphs have the same slider values in Blender as they do in DAZ? I only ask because I've experienced some problems regarding facial morphs when it works only in one direction and not the other.
Secondly, is it possible to bring over all the materials used in a DAZ scene over to Blender? I've tried it with one of my characters, but noticed that the materials don't follow suit, only the textures. This character btw is supposed to have slightly tanned skin that I came up with by tweaking the material properties of the model itself.
Comments
Hi all, I'm having an odd problem with the camera positioning and/or focal length when exporting from Daz to Blender.
I only noticed it because I was using Freestyle lines to lay on top of my Daz render. The two renders didn't line up, so that sent me down the rabbit-hole.
As far as I know I hadn't changed anything that might cause this. I'm using TeleBlender v15 and BlendBot v16 with Daz 4.9.1.30 Pro (64bit) and Blender 2.78 on the Mac.
You can see my test renders from both Daz and Blender here:
In Blender the camera seems to either zoom in or just move a little closer to the object.
My camera settings between Daz and Blender are close, but not exact. I think that's normal between the two programs, though.
At first I thought it was the discrepancy between the focal length settings, but after experimenting I found it was easier to get closer to the Daz shot by just bumping up the Sensor size a little.
In this case from "32.00" to "32.90". Now here's how the Blender render turns out:
So that's pretty darn close. With that change to the Sensor size, I was able to render my Freestyle lines and get close enough that it wasn't noticeable in Photoshop.
Also, here's my TeleBlender settings out of Daz. I can't see anything in there that would cause this.
Is there a setting anywhere I can use to permanently fix this? I expect most people aren't going back to Daz after exporting to Blender, so this may not be a high priority issue.
Please let me know if anyone has any questions or suggestions.
Hello
since Daz Studio version 4.5 i think, the cameras have a parameter named "Frame Width"
in Daz Studio 1,2,3, 4.0 this parameter was not exposed and it had a fixed value of 35mm
the default value in DS|4.9 is 36mm
so if you change the daz studio camera "Frame Width" to 35mm it should be near pixel-perfect
next time i update the Teleblender script i'll try to remember to make it automatic
Sorry about dropping this, I got caught up in some IRL stuff.
But anyway yes that worked perfectly. When I changed that Frame Width setting now the Blender render lines up perfectly with the Daz Studio render. Thanks much for the fix on that.
HI
I finally got around to trying this script on my PC (I used to use a Mac which tended to be very slow).
I have probably forgotten all I used to know about it but I believe the script has changed significantly since I tried it more than year ago. But now, on the PC, I have tried to follow the examples of the options used to export the scene and some of my materials are coming out as purple. Attached is an example. I've also attached screen shots of my export settings. Any help would be appreciated. The scene was set up using IRay materials in case that is significant. I have tried the CPU and also the GPU (CUDA) options.
It would be great if mcjTeleblender could work with IRAY materials!! However, I am pretty sure that it cannot, since (last I looked) it could only use .obj file materials.
Well, that's what I thought too but I asked in another thread and this was the answer from Wolf359:
According to that, the skin should be ok. I tried another render with some different clothes and they came out purple too. If I have to configure all my scenes with 3DL materials (assuming they are available) then IRay is going to be much less work and much quicker for me so there is no point in exporting to Cycles.
Hi there
The magenta/purple color usually means that Blender could not find one of the texture images
the image filenames and paths are tranfered to Blender from Daz through the .mtl and .py files that are found in the same folder as the .obj file
( so one could look in those files using notepad and look for weird filenames or paths )
usually the fact that you check-marked the "collect maps" option in mcjTeleBlender helps reduce that sort of problem
sometimes the issue is that the .mtl file specifies something like mytexture.tif and the "collected map" is in fact "mytexture.jpg"
the other options affecting the success of this are the "Fix .mtl .... " and the "no quotes in mtl paths"
which are okay in your screen captures
note that the fact that we can see the bearded texture means, that those 2 options are not at fault
-----
now about the iRay materials and other "real" shaders like that
i did valiant efforts to adapt the code so it can extract the same surface properties that i get from the DsDefault material/shader surfaces
but it can fail, notably when subsurface scattering is involved
For mcjTeleBlender those neat iRay shaders are a nuisance. Also, when TeleBlender doesnt really export .obj/.mtl files, it asks Daz Studio to export them. And event there the nifty iray shaders cause problems.
so, ideally you could select all the surfaces in the figure and apply the "shader" named DsDefault, which on my Daz Studio is located in Daz Studio Content/My Daz 3D Library/ Shader Presets / Ds Defaults
then readjust the materials until you get something that looks good when transfered to Blender
the save the set of materials as a Material Preset file (in Daz studio)
=====================
well just to make me lie, i tried a render right now and i had to turn "collect maps" off to get it to render
i'll see what's happening and tell you
oops false alert, the problem was that i used an old version of mcjTeleBlender
the important option was "No leading / in paths" i'll post my settings and the render in a minute or 3
the red iRay velvet color on the chair failed the transfer process
only 100 samples per pixel, forgive the render :)
Ok - I think I have an idea why this might be happening but I know very little about the technical details so I could be wrong.
I use a recent product from the DAZ store called Scene Optimizer. This creates smaller texture sizes so that the GPU VRAM is not used up so quickly. As I say - I don't know the details of how or where these are stored and referenced but I suspect that it doesn't play well with your script.
As I understand it, Cycles has the same problem with VRAM that IRAY does so if I go back to using full-sized textures so that I can use Cycles, I can only render smaller scenes. My only reason for wanting to try Cycles was to try to cut the render times. However, the Scene Optimizer does just that in a way because scene load times are much faster - especially if there are any LIE textures in the scene (and I use them quite a lot).
what i do sometimes, in scenes that contains 20 4000x4000 pixel texture images is, i set mcjTeleBlender's "collect maps" option on
i close blender
then i go in the "Maps" subfolder in the folder where teleblender exports the scene as .obj/.mtl/.py/.bat
and i resize all the big ones down to 1024x1024
then i use the scene's .bat file to re-launch and re-load the scene in Blender
---
but remember that some of the texture images did get properly transfered to the blender scene since the figure had its skin/bearded face texture
the missing texture was probably on a channel of the iRay shader that mcjTeleBlender interpreted as being, say, an ambient color map
and when the Daz Studio exported this scene as an .obj/.mtl, it didnt "collect" that map for some reason
but mcjTeleBlender did "tell" blender to import this image, which it said, should be in the /Maps folder
and apply it to the ambient color map of the skin
Even with these ridiculous 4k textures your rendertimes will be signifigantly shorter
with Cycles in my experience.
There is something about IRay being so purpose built for NVidia Cards that its performance falls of a cliff with non Nvidia cards.
Cycles is GPU agnostic and does not seem to so quickly curl up and die when it cant find its NVDIA built"mommy"
Well, surely that's because IRay will default to CPU if it doesn't find an NVidia GPU and IRay in CPU mode is, as we all know, glacial. Before I bought a PC with an NVidia card I used Reality/Luxrender in CPU mode and despite what some people say, I found it to be much quicker than IRay in CPU mode. It had other problems though and the time I took tweaking materials could negate any time saved on rendering. I'm afraid that migtht also be the case with Cycles and the scary node system doesn't encourage me to dive into that daunting task. Especially if, as mCasual suggests:
So that means a lot of switching back and forth between Blender and DAZ Studio and doing multiple test renders ... sorry but it seems to me that any gains in render times would almost certainly be wiped out (and then some) by the time taken to tinker with the materials.
Right. Two more things that have, in this context, changed dramatically this year are
(a) the speed of Cycles: it was fast; now, it’s like, wow!;
(b) the .fbx transfer from DAZ Studio to Blender: it’s very “delicate” and still has some glitches,
but I can transfer a figure, polished, in less than an hour (as opposed to getting a horrible mess).
Interestingly, the .fbx transfer, from, say, DS 4.9.x to Blender 2.78+, automatically converts
DAZ materials to Cycles nodes, in a manner almost identical to the Téléblender procedure.
The following image is a G2f character textured with SkinBuilder for Genesis and G2f,
and I’m not aware of any iRay-specific tricks
(although DS can give me iRay in the Viewport, no problem, all CPU; slow, of course).
On the viewer’s left is the character transferred with .fbx; on the right, with .mcj;
(24 second render on a 4 GHz Intel Core i7 iMac, 8 CPU, no CUDA). I was hoping
that the ears would show a bit of translucency, so, either way, I’ll have to ad that myself.
[Ugly? Okay, but they’ll look a lot prettier with “real” hair and stuff!]
Looking at the two images, I'm guessing that neither transfer method handles transparency/opacity? Is that a problem with the transfer or Cycles? Obviously you wouldn't want a finished render with such eye lashes yet I notice with many of Casual's Aiko renders in this thread and on his site - the hair is left as solid ribbons. Just has me wondering if it is a really difficult task to render hair, etc.
By the way, what do you mean by "polished"? An hour just for the actual transfer seems a long time but I have no experience with FBX.
[ Repeated post; sorry. ]
Transparency per se is not a problem; if it were, the cornea of the eyes would be messed up.
SSS (sub surface scattering) exists in 3Delight, iRay, and Cycles, but I’m not sure that’s coming across.
With respect to the ears, I’ll do a trick on the Cycles side.
Cycles gives me great confidence: it is SO programmable!
The .fbx version’s eyelashes are of the “piggy” variety, and very close to what I was aiming for.
They are implemented by standard (and vintage) DAZ technique. Oddly, .mcj went astray on that.
Eyebrows and hair, I intend to accomplish with Blender “hair particles”;
then, of course, I have a small collection of Blender-modeled horns, waiting to be fitted.
Oh yeah: once a DAZ-origin character of mine makes it over to Blender, she ain’t going back!
The transfer itself takes seconds; the better part of an hour is me, preparing last-minute details on the DS side,
then fussing over glitches in the armature, on the Blender side.
Next, I intend to try the Khalibloo Panel, to convert the DAZ armature to Pitchipoy Rigify,
which has a face rig and controllers to define expressions and visemes.
June 15: Okay, the Khalibloo does a wonderful and ingenious job of fitting a Rigify rig
to your figure, but not the Pitchipoy version, so, no face rig.
Plan B: stick with the G2f rig defined by DAZ, which, on the head,
has a bone for each eye, one for the lower jaw, and seven for the tongue,
and supplement that with a handful of expression morphs, which —hallelujah—
the .fbx export/import, now, is able to transfer (and they show up as shapekeys in Blender).
[Yes, I gave G3f another try, and again, I’m sticking with G2f.]
A future source of temptation will be Manuel Bastioni’s Lab, version 1.6!
important mcj TeleBlender update - version 3.16 - important mcj TeleBlender update - version 3.16
Jul 21, 2017, 11:48 PM
importantmcj TeleBlender update - version 3.16
no need to re-install mcjBlendBot if you have the august 2016 version
fixes: reflection maps were not being transfered
fixes: the extra parameters passed through the python scen-file were missing, normals, glossy parameters, normals, tiling !
https://sites.google.com/site/mcasualsdazscripts4/mcjteleblender3
There is a problem with mcjTeleBlender material conversion on Daz Studio 4.10.0.107.
If there are two figures of the same material name, the conversion is not good. One succeeds but the other fails.
Is there a solution? (I am sorry that my English is not good)
i'll see if renaming the materials before ( and after?) the .obj export fixes the issue
the "rename nodes" option was added for similar issues
also today i'm supposed to complete the Louis XIV penderie below ( iRay render ) and will make it part of the blender render tests
Figure 2 - it's a good start i can reproduce the problem
note that the same phenomenon occurs for the swimsuits since they are figures like the Genesis 2s
swimsuit for Genesis 2 here https://sites.google.com/site/mcasualsdazscripts8/mcjg2onepiece
there's also one for Gen3 https://sites.google.com/site/mcasualsdazscripts8/mcjg3onepiece
---------------------
Fig3. Tada ! the same scene but before running teleblender i ran a script that renames all figure-owned materials with names like "Fig1_skin" ... "Fig2_skin"
i will add the functionnality to teleblender in a few minutes and will post the announcement below
after teleblender exports the scene, i will re-rename the figure materials back to their original names
( in case it would break material preset abilities to leave those new material names )
IT's READY
November 3rd, 2017, 5:44 PM
mcjTeleBlender was updated - version 3.17
There is now an option ( On by default ) named "Make Fig Mat Names Unique"
This solves the problems when 2 figure in the scenes are identical and only one of the figure's materials get exported correctly
Before exporting the scene(s) as obj file(s) mcjTeleblender renames the figure-owned-materials
with names like Fig1_Skin Fig2_Skin. After the export is done, the materials are re-renamed back to their original names;
https://sites.google.com/site/mcasualsdazscripts4/mcjteleblender3
version 3.18
the option that was in version 3.17 for figures, was extended to all surfaces in the scene
November 3rd, 2017, 6:47 PM
mcjTeleBlender was updated - version 3.18
There is now an option ( On by default ) named "Make Mat Names Unique"
This solves the problems when 2 objects in the scene are identical and only one of the object's materials get exported correctly
Before exporting the scene(s) as obj file(s) mcjTeleblender renames the object materials
with names like Fig1_Skin Fig2_Skin. After the export is done, the materials are re-renamed back to their original names;
https://sites.google.com/site/mcasualsdazscripts4/mcjteleblender3
version 3.19
ovember 3rd, 2017, 7:29 PM
mcjTeleBlender was updated - version 3.19
important features like texture tiling and bump, normal map parameters didnt get transfered correctly
( technically : i was "cooking" the python file that transfers parameters not in the .mtl files before performing the material renaming trick )
Hey mCasual
First: thank you so much for looking into this problem so fast!
Second: I'd like to make two comments about this issue.
1. I believe this is a bug in DAZ 4.10. In previous versions, when two figures shared material names the OBJ would have renamed materials like Fig1_Mat1 and Fig2_Mat2. However, now the second figure doesn't get a material name at all (if you open the OBJ file, the second figure will have an empty "usemat" tag). This can be reproduced by simply exporting a scene with two figures sharing the same material names -- no Teleblend needed. I think we should file a bug against this so that the good guys over at DAZ fix this.
2. I haven't checked your fix; but I would argue that we do *not* want the materials to be renamed back to their original names in Blender. The reason is that in Blender, material names exist in a global namespace and material names in DAZ are local to the figure. In other words -- if I understood correctly -- your fix will rename materials to Fig1_Mat1, Fig2_Mat1 and so on and then rename the materials back to Mat1. I think we do *not* want the materials to get their original names.
To illustrate why imagine two figures, male and female. Let's say G3F and G3M. They will both share the same material names but they would have very different textures. If both figures share the same material names in Blender then we will end up with all the materials from G3F applied to the G3M or viceversa. I think we want to keep them separate.
Anyway, I may be completely wrong in my second point since -- as I said previously -- I haven't checked your fix. But I just wanted to put this idea out there.
And, again, thank your for helping us out!
hi there
welcome
make sure you get teleblender 3.19
i posted v3.17, 3.18, 3.19 today, fixing bugs
when i say i restore the surface names to their original names , i mean in Daz Studio, not in Blender
Blender will receive uniquely named materials. Note that if you looked in the .mtl files before, you could see the duplicated material definitions were corrupted
now they all look fine like ...
OK, nevermind then. I still think we should file a bug against DAZ, though; because this is an issue with exporting OBJ files -- not with Teleblend. But thanks for fixing this for the rest of us mere mortals here!
Thank you so much for looking into this problem so fast!
You’ve been very helpful.
Most of all if you started using Blender Version 2.79
it's important to get this mcjTeleBlender AND This mcjBlendBot upfdate
November 7th 2017, 12:58 AM
mcjTeleBlender was updated - version 3.20
Fixed : The fix introduced in teleblender 3.17 could fail for scenes containing shape-less objects
Fixed: The global parameter 'Roughness' passed along to mcjBlendBot was invalid
November 7th 2017, 12:07 AM
mcjBlendBot was updated - version 3.17
Blender 2.79's .obj importer now creates cycles material trees
this prevented mcjBlendBot from creating its own material trees
so we now ask Blender's importer to not do that!
so Blender just creates material tree stumps which mcjBlendBot replaces with its trees
if there's complex trees in the scene, then mcjBlendBot wont bother them
so i didnt break the re-usability of old .blend scenes
https://sites.google.com/site/mcasualsdazscripts4/mcjteleblender3
Hi, mCasual!
I have one question:
Does mcjTeleblender export bones or I am missing something?
I do export from daz but without any bones.
Daz 4.10
Blender 2.79
In addition:
Have you ever heard about bos fbx addon for blender?
It exports daz models' bones very accurately. So it could be useful for mcjTeleblender.
Anyway, thanks for your hard work.
Say mCasual, I have a questions regarding a few things:
First one I have is about morphs (I apologize if this has already been answered before), but is there a way to get it so that DAZ imported morphs have the same slider values in Blender as they do in DAZ? I only ask because I've experienced some problems regarding facial morphs when it works only in one direction and not the other.
Secondly, is it possible to bring over all the materials used in a DAZ scene over to Blender? I've tried it with one of my characters, but noticed that the materials don't follow suit, only the textures. This character btw is supposed to have slightly tanned skin that I came up with by tweaking the material properties of the model itself.
yes it's an .obj exporter which doesnt include bones
a few months ago i noticed that the fbx export in daz studio seem to have improved with the years
but when i tried it ( unless it was collada ) there was a need to fix props and/or clothes after blender's import
so in the future ( 2018 ) i plan to add a FBX and/or Collada way to export in teleblender
not sure if the "weighted" ot tri-ax featires of genesis will make the trip
i'll look at the bos fbx exporter you mentionned
------
note that if you export a frozen bone-less copy of a figure through teleblender
then export the figure as fbx from daz, then import the fbx in blender ..... in the blender scene that was imported by teleblender
then applying the materials from the statue to the fbx figure could be done in a few minutes
---
i'll try to find time in 2017 to try things !
currently working on special effect based on my mcjIsosurface4 plugin, then i have to complete the kinect v2 project
if the scene was exported/imported through teleblender it has no morphs no skeleton so i suppose you did the export/import through fbx or collada
i have a general idea of how this could be done but dont plan on writing the blender script to do this sorry. I didnt see existing scripts to do this
but i dont follow activities in the blender world, maybe if you search in the big blender forums for words like "morphs" and "combine" or "unify"
if you use mcjTeleblender to export the daz scene, all the materials should be in blender
The main purpose of teleblender is to transfer a frozen daz scene to blender and convert the materials into the type of materials that Blender wants ( ex: cycles materials )
in all versions of Blender, except 2.79 i think, when you exported a scene from Daz using Daz Studio's built-in exporter and imported it in Blender "manually", the materials for the Cycles renderer we basically blank ... that's why teleblender was created
with Blender 2.79 the obj importer now creates usable cycles materials, but not as good as the Teleblender ones , because teleblender transmits to blender more of the material parameters like tiling for instance