Quote - This sounds similar to the "burnt-in specular" problem encountered in Poser when you want the shader to do the specular, but the image already has specular highlights due to how the photograph was taken: no criticism of technique, it's just a limitation of the approach, I guess. I really think this is where non-photographic-origin skin textures are finally going to come into their own.

Yep. Photographs don't just capture diffuse information, and with traditional renderers, that was mostly a good thing. Use photographs makes texturing considerably faster.

Quote - BTW, that SSS shader node (as seen in the examples) isn't as easy to implement like it is in Poser... the node tree is quite extensive. Not for the faint-of-heart. :blink:

Yeah, most of the approaches to SSS skin I've seen since the shader came out are pretty complex and extensive. I suspect that part of this is from trying to make a relatively versatrile shader that works for many models.  You can actually get some pretty nice results just mixing the SSS node into an existing material, either substituting it for the diffuse, or mixing it at some percentage. It won't be as realistic, and will likely require some cheating or tweaking for some situations (strong backlighting, e.g.), but the results can be quite nice. If you're not looking for photorealistic, you can also avoid a lot of that complexity.

Quote - ETA: in other words, I haven't got it nailed down yet, myself. :biggrin:

I'd be impressed with anybody who had it nailed down already, given it's not even in general release yet. Hell, the people who have created the skin shaders based on the SSS node HAVE impressed me, but that doesn't mean we're done figuring out how to use this new feature. :)

Yes, particle hair is also awesome, albeit a little tricky to use, especially for long hair.

Just a few caveats I've noticed with this - 

It will apply the motions to only the first figure in the scene - a figure being anything with an armature - based on the order in the Scene List view. If you have multiple animated characters, split them into separate .duf files before exporting. Also, if you've deleted the main figure accidentally and undone it, it may not be the first thing in the scene list any more. There's no way to re-order the scene list I can find (please let me know if you know how to do it), but when you delete and undo, it always adds the undeleted object to the end of the list. 

You need to make sure your main figure is first, or you'll end up with animated hair or something.

Quote - Blender and DAZ are my tools of choice but I have always worked the other way in the past. Now I might just try it in reverse.

Yeah, I feel the same way. While DAZ Studio is a great product, it doesn't have the feature set of Blender, and I also find that it takes me longer to do most a lot of tasks, so I'm really excited about the fact that this now works.

Select the object, then look in the right pane (N key) under Display. There should be an unchecked box called "All Edges":

Turn it on, and you should see the lines again. Somewhere in the last few releases, they seem to have made the algorithm that culls edges from the display more aggressive, but we can turn that off.

Quote - Really good to see others as excited about this new renderer as I am, even though it is but at the early stages of development. The fact that OSL has been enabled for it means exciting times ahead.

Since the 2.5 rewrite, I've really, really liked Blender (I can't understand the people who are still sticking with 2.49b). Though DAZ Studio and Blender are awesome programs, I find I'm able to pose and animate much faster in Blender, and I like the additional flexibility a full-featured 3D program offers.

But, Blender really was missing a good renderer. Blender Internal was state of the art back in 2004 or so. :) And integrating with YafaRay or another third party renderer is such a hassle, and you lose out on one of Blender's main advantages - how integrated everything is. Getting render layers back into Blender's compositor, for example, is a real hassle with an external renderer.

So, yeah, I do see huge potential with Cycles. With the node-based materials and OSL support coming in the next release, amazing things are going to be possible. Even as it is now, I've gotten some pretty amazing results with it and I can't wait until I can totally forget the Internal renderer exists. :)

Let me know how the shaders work for you. They're nothing fancy, but I've been pretty happy with the results given the current limitations (no SSS, etc.).

Quote - Bad news! It looks like they can't get past the Autodesk licencing so there won't be FBX support till Autodesk change the terms of the SDK.

This is true in terms of using the official FBX SDK from Autodesk inside Blender, and that's an issue that's unlikely to ever be resolved. The licensing of Blender and the SDK are just not compatible.

But that does not mean that all hope is lost for Blender FBX importing.

There's a Google Summer of Code project currently in the Bratwurst branch that's leveraging assimp to create an FBX importer. Not sure when that'll hit Trunk, though. The earliest would be 2.65, but possibly not until 2.66. 

http://wiki.blender.org/index.php/User:Aramis_acg/FBX2012-AssimpIntegrationFrom the TODO list, it looks like it's getting close to done, too. You can get access to the FBX import by downloading the latest Bratwurst branch from graphicall.org. You'll need to turn it on in the User Preferences / AddOns, and it won't show up unless you hit the "Tested" support level button.

Thanks, but I know about mcJTeleBlender. What I'm looking for is a way that brings the pose over to Blender as a pose for an armature, so I can tweak and animate the pose once it's in Blender. I could always just export .OBJ if I just wanted the posed mesh.

They're posted in the main thread. There's also an updated from Millighost and there's
some overlap between them. 

You can find them both here: 
http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2834649&page=3

Quote - ah! gotcha. thanks.

"oh...thats very different... nevermind." :D

Yeah, it's gotten me more than once. Probably should've chosen a different file host, but
all the free ones offer ads, and most of the ones with ads seem to run variations on that. :(

Quote - > Quote - Unfortunately, I'm having trouble understanding the exact nature of the scaling problem you're having. When I extrude and scale on the file you uploaded, everything behaves pretty much as I expect it to. If you can provide more details about the problem you're experiencing maybe somebody can offer more insight, but some things to try:

• try "scale along normals" (alt-s) instead of scaling (s). I use "scale along normals" a LOT when modeling

That was exactly what I failed to do - only because I didn't realise one could. Thank you. I was trying to evenly extrude a plane with equal width where the extrusion was based on a normal. And failing.

Awesome! Glad I was able to help. Scale along normals is one of those hidden gems
that you're unlikely to find yourself unless somebody tells you about it or you see it
in a tutorial or something. 

Quote - I'd love to check out your scripts but there's no way I'm going to install some site's 'download' manager. That's just asking for a world of trouble.

If you're seeing the download manager, you're clicking on an ad, not on the Sendspace download link. The one you want looks like this:

Not like this:

Very cool!

I'm looking forward to looking at your code. I tried to follow your conventions and style as
much as I could. While I'm an experienced coder, I am NOT an experienced Python coder,
and often make things unpythonic (and also harder than necessary) :)

I did PM you when I started working on this, but I'll drop you another one. I'm more than
happy to pitch in on whatever you're not focusing on. I did the armature and pose stuff for
a practical reason - I needed it for a project I'm working on. I won't at all be upset if I can
throw it all out now. :)

It boggles my mind that there's still no good way to transfer poses from DAZ to Blender (if
you know of one, please share - BVH is the best I've found, but it screws up some of the
bones)

I'm especially interested in looking at your bone orientation code. I found that trying
change the bone roll caused problems with constraints and setting bone transformations
from pose data. Been trying to figure out if this is a coordinate system problem, object vs.
pose vs. world space issue or what. I ended up leaving all bones at 0° roll.

There are a couple different ways to get fine details like these. The most obvious is to add geometry and model in the details, which is what it sounds like you're trying to do.

Unfortunately, I'm having trouble understanding the exact nature of the scaling problem you're having. When I extrude and scale on the file you uploaded, everything behaves pretty much as I expect it to. If you can provide more details about the problem you're experiencing maybe somebody can offer more insight, but some things to try:

• try "scale along normals" (alt-s) instead of scaling (s). I use "scale along normals" a LOT when modeling

• try extruding in different modes (face/edge/vertex). I find that extruding in face mode is often what I need when trying to "pull out" volume from a surface detail like buttons, buckles, etc. rather than in extruding in vertex mode

• Try modeling the details as a separate object in its own object space that simply overlaps or intersects with the main object, and then join the objects later when you're happy with the position of the detail.

You can also use normal and displacement maps to add details as was mentioned. There are plenty of alpha images out there for textures like stitches, and throwing together stitching or other details in photoshop or GIMP isn't terribly hard. Once you have the details in a texture, you just map them to the displacement or normal influence (using "Normal" or "Displace" under the "Geometry" section) instead of mapping them to diffuse color. This can give the appearance you want in your final render without increasing the model's vertex count.

As somebody else in the thread mentioned, you can't use normal maps in Cycles, but you can bake the results of a normal map into a displacement map and use that instead. There are differences in displacement and normal maps, but the majority of the times, the results are similar enough that you can make it work.

There's another way to use normal maps with Cycles: a displace modifier using "Normal" for the Direction, combined with either a subsurf or multiresolution modifier. 

A third option for these details is to use Sculpt mode with a multiresolution modifier. You can sculpt in the details either freehand, or using any of the various alpha brushes available around the web. You can sculpt them in at whatever resolution you need for your final rendered image (though, honestly, when I need to go really high resolution, I move to ZBrush). You can then either bake these sculpted details into a normal map, or simply render right from the high-res sculpted model (generally speaking, your render times will be longer if you do that, though).

meipe:

Sorry about that, I'm not sure what happened with that code. It looked correct when I typed it in using the

 tag.

I've done a fair bit of development on the dsf scripts. I'm gonna hope that Millighost is okay with this, but I'm posting my versions of his dsf tools. I've made a bunch of changes. I didn't really keep track of what I did, but offhand, I can think of the following:

• Added support for either older text-based .dsf files or the newer GZipped versions
• Added ability to load armature from .dsf file, with bone attachments and constraints. I didn't make this part of the dsf-geom script, but instead added a new dsf-armature import that will read the armature out of a dsf file. This does not link the mesh with the armature, however - that has to be done manually.
• I've updated the dsf-geom script to import the correct bone weights from the dsf file. The one in this thread gives every vertex a weight of 1.0 in every group its part of.
• I've started on a pose importer for scene (.duf) files. This is very much a work in progress, but if you select an armature that was created using the new dsf-armature import script, and then select import duf pose and select a DAZ Studio 4.5 scene or pose file, the script will attempt to apply the pose to the armature. This works for simple poses, but does not work correctly with more advanced poses, so you may not want to use this yet. I've got a couple of ideas about what's wrong and hope to have this fixed in a day or two, but if anyone spots what I'm doing wrong on the pose import, I'd love to hear what I'm doing. 
• Morph and UVSet import both allow you to select more than one file and will correctly import multiples
• Bug fixes (e.g. UVSet import now works with Blender 2.64)

You can find the scripts here:

http://www.sendspace.com/file/nq1eiaMillghost - if this is not okay with you, say the word, and I'll yank the files down. 

I'll gladly take suggestions and bug reports as long as Millighost is okay with it.

FS

Quote - Seems like the new format changes etc pretty much screwed the importer over, am I right? At least when I try to import the genesis.dsf from Studio 4.5 it gives tons of errors.

The problem you're experiencing (I think) is that 4.5 supports two different .dsf versions, one that's the old fashioned JSON text file, and a new compressed file format. Fortunately, the new format is actually nothing more than a file in the old format that's been gzipped. That's easy enough to account for in the scripts. In the four dsf_xxx_load.py files, you can add an import at the top:

import gzip

 and then in the load_file method, change the code to un-gzip the data before parsing if the parse operation gives an error, like so:

<span style="font-family:'courier new', courier;"> @classmethod def load_file (self, filename, opts = None): try: jdata = json.load (open (filename, 'r')) except ValueError: f = gzip.open(filename, 'rb') file_content = f.read() decoder = json.JSONDecoder() jdata = decoder.decode(file_content.decode("utf-8")) si_arm = self.get_armature_from_jdata (jdata) return si_arm </span>



You'll have to make the change in four different files (dsf_arm_load, dsf_geom_load, dsf_morph_load, dsf_uvset_load). I've fixed a few other issues with 2.64 and/or DS 4.5, so if Millighost gives the okay, I'll share my revised scripts.

Another change I've made that some people might be interested in is supporting the import of multiple morph targets or uvsets at once. I'm also about 90% done an addition that imports the armature and pose data out of a .duf file (might also work with .dsf - haven't checked). Again, if Millighost gives teh okay, I'll share the revised scripts.