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
There really needs to be a "standardized" way to transport textures (procedural and bitmap) between various 3d applications. A couple companies have attempted this (probably more that I am not aware of)
http://www.darksim.com/html/dt25_description.html
http://www.allegorithmic.com
It would be great if the 3d modeling and rendering software developers would support this too.
I know OBJ and 3DS as well as others support texturing, but the complexities of shader trees or shader stacks in current applications means that exporting textures to those formats often lose a lot, and texture baking in many cases is not suitable.
Would be nice, but don't hold your breath.
And that lack of standardization is just one more reason why many professionals, who work in team environments using multiple CG apps, avoid procedurals like the plague. So much easier to just use an image you can control and swap between many CG apps, as well as into and out of Photoshop and AE and whatever in-house software they use. That's the real standardization....
Yeah, thats why I put "standardized" in quotes.
Well there is a fundamental problem with this. Procedurals are like many things that are in flux level of development. The way different packages implement them are both fundamentally different and constantly being tweaked. The first issue means that things don't translate directly, just like in languages. The second issue means that even if one does try to create a translation program they are shooting at a moving target. That's not to say it can't be done, just that it's not simple. This feature is exactly one of the main features Paolo provides with Reality for Lux (translating 3Dlight shaders, lights and cameras to LUX,) and he does a good job from what I understand. But it takes a bit of work and some things just don't translate. But... yes, that is ofc the holy grail many of us wish for ;)
Eventually they will get shaders (and lighting as these are wed at the hip to some extent) to translate much better but then the focus of incompatibilities will simply shift to rigging, physics, etc...
The best chance though of tackling these issues would be to have some central program that became standard for routing different things through, that allowed various companies (or interested individuals/parties) to write their own translation layer.. a 'print manager' for 3d objects of sorts... DAZ Studio in an optimistic perspective could become that app theoretically if the company positioned itself well, but then it would be a gamble to some extent that they could pull it off.
Baked textures/ambient occlusion etc.. is common in games but for other production environments procedurals are actually used a lot. Just when they incorporate them into the pipeline is done on a company by company, case by case basis. The other thing missing here is that often procedurals are actually used to create the texture that is then baked. Conversely, procedurals are added at the last stage at times when they won't have to go through issues with other apps, or when they do route objects through other apps, they aren't worried about the textures translating because it's understood that the final textures will be applied at the end in whatever combination of methods are used.
Both points are valid. I am a firm believer in using real photos to generate textures whenever possible. But as mentioned, photos are biased by the lighting conditions in which they were captured. Specular reflections are a good example of artifacts which are difficult or impossible to remove in photoshop. But what if you dont have access to attractive naked people, or a good camera? Isnt there another way to derive skin textures?
Procedurals in theory, dont ever need to repeat. Procedurals should produce random patterns based on rules, never repeating. The problem comes in as aforementioned, with not having a large enough sample to get the job done. Only when samples are too small is tiling and repetition a problem. Procedurals are also resolution independent and arent affected by scaling.
Human skin is a good example of the benefits and drawbacks of each method.
Human skin based on real human samples has certain obvious benefits, as the old saying goes "aint nothin' like the real thing."
1. Realistic Color variation
2. Realistic bump and displacement
3. A million other subtle details difficult to fake
But there can be problems including the following:
1. Pixel resolution inconsistencies causing blurring where it shouldn't be.
2. Specular highlights and shadows are captured which add bias the resulting skin
3. Textures might be too unique, too specific, and therefore not useful for many generic projects. All humans have unique skin, and if the sample you use is too specific all your resulting characters will look to same. Not good.
An ideal skin is both specific, but still general enough to be useful for many characters.
I am using Carrara 3d Paint to create characters. I apply color as one layer, leatherette as another, pores as another, as well as two noise filters for variation. One noise is chromatic and blurred to create color tonal blotchiness. Another noise layer is monochrome also blurred to create value blotchiness. It is the lack of blotchiness that gives away many man made skins. But realistic leather is also a necessity for believable skin.
The leather and bump textures were derived in Genetica and saved out as .bmp. I then use them as sources for painting in Carrara. I then can compile the final textures in PSP. The good thing about using procedurals this way is:
1. I have complete control. Since color and leather and pores are all seperate layers I can manipulate each to the degree I want. I control the amount of leather grain in the final result. If I was using a real photo I would not be able to manipulate the individual aspects in this way. I can alter color without affecting bump for example.
The result is all that matters. I have seen many skins based on real photos that look terrible, overly contrasty, overly shaded, overly processed in general, but others that are amazing like the Elite textures. On the same token I seen some incredible fakes built up from procedurals that look better than photo based skin. So long as the procedural creator or painter knows how to create the myriad different types of skin covering a body then it is possible to pull it off.
At the risk of wrinkling this discussion further; has anyone here used Shader Map (http://shadermap.com/home) to work with texture / bump / normal maps?
I haven't tried it myself but hope to get to demo-ing it this week to see if it meets my needs.
Rashad, since you mentioned procedural shaders for skin, here's a link that may be relevant (contains nudity):
http://www.shonner.com/drafts/procedural_skin_texture.htm
Thank you Rashad, I think that is a good depiction of how and why procedural shaders can be used effectively :)
Wow, Rashad, I applaud you for tackling human skin. That's one of those reasons why I occasionally prefer premade content to doing stuff myself. I tend to mix and match various skin textures, bump maps, etc., from various packages depending upon which is best. No way I'd have the skill or patience to do it myself.
And honestly I never would have considered using procedurals for skin, but you probably have a really nice idea there. Not sure how you handle the area-specific wrinkling and color variations and body hair and such using procedurals, and then get it all blended together, but no matter how you do it (procedurals or photos) it seems like a lot of work.
Come to think of it, how DO you handle the area-specific variations, like the wrinkling at the joints and body hair and color variations ?
Some shaders allow multiple maps on a single channel (diffuse, bump etc,) but I apologize, I should have let Rashad answer before jumping in.
My point was that procedurals imply a continuing pattern over an area. Maybe it's not repeating, or duplicated, but it's continuing over the area.
However, human skin has vastly different areas, with vastly different characteristics. Fingernails, the wrinkles on your knuckles, the hair on your chest, the mostly smooth skin on the bottoms of your feet, etc. It's very difficult to selectively apply a procedural by area like that. Somehow you have to selectively apply varying textures to different areas, and then blend them all together convincingly. And if you look closely at your skin, you realize that there is a huge variation in color, texture, bump, etc.
While taking a photo has some drawbacks, it seems to me that somehow generating and blending procedurals by area is far more work. For example, how do you generate fingernails and nipples and elbow wrinkles procedurally, and then blend it in with the rest of the map.
I guess I've never seen a really well done procedurally generated skin texture (at least that I'm aware of), so I'm not yet convinced it's an effective option.
Joe,
It is a lot of work, and to be fair I have been at this for several years off and on certain that one day I'd figure this out. I am getting quite close to a natural looking result, but I cannot post anything just yet as I am still tweaking my process.
I have purchased several leather merchant resource packages which have the "elephant skin" type of wrinkles needed for knees, and elbows and finger bends. Once I am happy with the basic skin I will then apply these leather as multiply filters to carve out the heavy wrinkles.
Hopefully by the end of today I should have something compelling to upload. Fun Fun.
Several years?? Wow...
So I guess if you had one of those 3D scanners where you can take hi-res photos of a human body under controlled lighting conditions, and do it all in a matter of minutes, you'd jump at the chance? :)
Honestly, in terms of quality and efficiency, I think that for skin textures (and for most other textures), taking photos is the way to go.
But like I say, I applaud you for putting in the effort. I'd be the kind of person who would hire a model, put him/her in a studio under controlled lighting conditions, get out my camera, and take a bunch of hi-res photos, stitch them together, and bam, you're done.
Just wanted to provide an update. I'm still working on some things but I hope that very soon I will have some fake but realistic looking skin to show. I have been making good strides so far this week so I am very hopeful. See ya all soon!
We did end up purchasing Filter Forge. The price was too good. My wife wanted to do some things with it, so we ended up buying it for her computer. LOL So I will have to get up early when I need to make something with it myself ;)
Thanks everyone for their input and its been a interesting discussion with some twists and turns.
mentioned in the News Headlines on the Blender website a couple days ago:
http://code.google.com/p/openshadinglanguage/wiki/OSL_Introduction
http://code.google.com/p/openshadinglanguage/
http://www.openshading.com/
Open Shading Language (OSL) is a small but rich language for programmable shading in advanced renderers and other applications, ideal for describing materials, lights, displacement, and pattern generation.
OSL was developed by Sony Pictures Imageworks for use in its in-house renderer used for feature film animation and visual effects. The language specification was developed with input by other visual effects and animation studios who also wish to use it.
OSL is distributed under the "New BSD" license (see the "LICENSE" file that comes with the distribution). In short, you are free to use it in your own applications, whether they are free or commercial, open or proprietary, as well as to modify the OSL code as you desire, provided that you retain the original copyright notices as described in the license.
It will be interesting to see what rendering engines end up supporting this, and how well.