Thanks. The figure is M4. The info you gave me for the eyes should give me a few things to change, but I don't know remember seeing "architectural glass" as an option in the material settings....

If that's Michael then all the materials are configured by Reality automatically.

architectural is an option all the glass material. If you click on a glass material you will find that there are four kinds of glass that can be selected. Architectural is one of them.
All the details are in the Reality User's Guide.

Cheers.

Thanks. That's Michael. Obviously the automatic config is not working so great here, for some reason.

Why are you saying thst is not working. Are the materials not set as I described?

Cornea should be set to Glass, automatically. 1_SkinFace should be set to Skin and so on. If the configuration didn't work then both materials would be set to Glossy.

Please let me know.

Thanks.

Yeah, I'm saying it's not doing that. When I do an initial export, Reality 3D is setting all the materials (i.e. everything in the scene) to glossy by default.

I've been trying this on a custom character, but Michael 4 is the base. I'll try and see what happens just with M4.

Okay, I just tried it with default M4, and a quick glance suggests that M4 seems to export okay as you describe. But when I've got complex shaders in the scene, it apparently seems to throw Reality out of whack.

You will get betters results by simply using the standard materials for your model. Given the physics-based shaders of Reality and Lux there is no need to use complex shaders in your model.

Make sure that you have a diffuse map, a bump map and, possibly, a specular map, and Reality will do the rest.

Cheers.

Thanks. It's too bad that Reality cannot reduce things to that level itself. By this stage in my Poser career, I have a lot of well-developed characters to strip. Does anyone know if there is a script that can accomplish that?

Quote - Thanks. It's too bad that Reality cannot reduce things to that level itself. By this stage in my Poser career, I have a lot of well-developed characters to strip. Does anyone know if there is a script that can accomplish that?

There will be one in the forthcoming EZMat, designed to simplify shaders to the level where they are useful to unbiased renderers. It will be specifically targetted at Reality and Octane users, and will strip out all the nodes apart from the maps referred to by Paolo which will then be reattached to the PoserSurface in the appropriate places.

Quote - .... It will be specifically targetted at Reality and Octane users...

And, I suppose, Pose2Lux users :-)

Sweet! EZMat is looking better and better! What's your timetable looking like right now? Is this going to be a commercial release? (You certainly deserve it....)

Thank you Snarlygribbly.

The fact is that Reality actually traverses all the nodes of the poser shader and converts as much as it's possible.

The issues arise only when using very complex shaders that use esotheric capabilities of Firefly. There is actually no need to strip the shaders in the vast majority of the cases. For example, the image attached, from Syyd's Oxygen, works just fine.

Cheers.

Ah, yes, that shader looks very familiar :-)
The EZSkin shader.

I'm a bit confused about the message you're trying to give here. Earlier in the thread you gave the advice:

Quote - You will get betters results by simply using the standard materials for your model. Given the physics-based shaders of Reality and Lux there is no need to use complex shaders in your model. Make sure that you have a diffuse map, a bump map and, possibly, a specular map, and Reality will do the rest.

So, a utility which ensures the shader is simply using the standard materials and has the stated maps, will give better results?

Or not? The last post suggests that there is no need to strip the shaders and that Reality will cope well with complex shaders anyway, making the earlier advice redundant.

Not trying to pick an argument, you understand - I've been following the thread and thought there was an opportunity for me to help out in a small way. Now I'm just confused :-)

Well, here's what I've learned. If you save a developed character to your Figures library, Reality will not recognize the base figure. It will call the internal name Figure 1 or whatever. I guess that is why it was not assigning the correct materials.

I understand how the statements might seem contradictory... but their are not :)

As we all know, Poser shaders can be extremely complex, to an infinite level of nesting. The only way to be able to convert any possible combination of shaders is basically to re-write Firefly, which is clarly not in the scope of something like Reality. It would also require years of man-power and bring the cost of Reality quite high.

What Reality does is to traverse the shader and collect information on the nodes. Some nodes are directly translatable, for example, the Image_Map node. Others require conversions, for example, the procedural noise ones. Other nodes make no sense at all for Reality and Lux, like the Blinn node, and they are ignored.

The issue comes from nodes like Blinn or Phong that receive input from other nodes. Since Blinn and Phong are not replicable, Reality ignores them but it continues to scan their inputs because more data could be used there. What is attached to those node could influence the final result of the Reality shader. I have added many tests to try to catch the largest array of conditions and handle them properly but there are always exceptions. 

So, for normally complicated shaders, like your EzSkin, Reality can extract the right information automatically. For others there might be things in there that throw a curve ball and confuse the final result. That's why I said that it's best to use the simple mats. If you are creating a scene from scratch, and you know that you are going to use Reality, then there is no need to use esotheric and complex Poser materials. They will not buy you anything and simply use more memory than necessary. For example, if there is an alternative between SSS mats and non-SSS mats it's best to use the non-SSS alternative. Reality already creates its own SSS materials, indipendently from what Poser specifies.

On the other hand, if there are no alternatives, then using complex shaders can be done with ease, because Reality has been designed to handle them as accurately as it can be. There might be cases when some shaders don't get converted at their best. In that case the best thing is to let me know. In that way I can obtain the product, check how it translates in Reality and possibly modify the program to handle that case better. I routinely expand the capabilities of Reality to handle more and more combinations. 

Like in many fields of art we must be midful of what we do and how we do it. 

I hope this clarifies the situation.

Cheers.

Quote - Well, here's what I've learned. If you save a developed character to your Figures library, Reality will not recognize the base figure. It will call the internal name Figure 1 or whatever.

That is not correct. The name is given by Poser, Reality does not name the objects in the scene.

Quote - > Quote - Thanks. It's too bad that Reality cannot reduce things to that level itself. By this stage in my Poser career, I have a lot of well-developed characters to strip. Does anyone know if there is a script that can accomplish that?

There will be one in the forthcoming EZMat, designed to simplify shaders to the level where they are useful to unbiased renderers. It will be specifically targetted at Reality and Octane users, and will strip out all the nodes apart from the maps referred to by Paolo which will then be reattached to the PoserSurface in the appropriate places.

@.@ ooooOOO now your just teasing! EZmat just keeps sounding better and better. Then again that glass shader with it alone would make it well worth it. Much less everything else with it!

Quote - That is not correct. The name is given by Poser, Reality does not name the objects in the scene.

Whatever the case, the point is that Reality will not recognize M4 if he is called from the Figures library. That's a significant datum to be aware of.

My current render tells me what Reality > Lux can & will do, although it's even more clear than even with high quality Poser renders that textures with any specular and shadows in the image map will look like a disaster (which is as it should be) when rendered properly in Lux. So this particular render will not look good, as the vendor used photograph-based colour maps. But at least now I know where I'm at and should be able to get good results once I sort carefully through my texture sets.

One question in this light, however. Will turning down Diffuse_Value in Poser weaken the effect when ported over to Reality?

Quote - Whatever the case, the point is that Reality will not recognize M4 if he is called from the Figures library. That's a significant datum to be aware of.

Nope, I have several figures in the Library and they are recognized correctly. There is something else going on.

Quote - My current render tells me what Reality > Lux can & will do, although it's even more clear than even with high quality Poser renders that textures with any specular and shadows in the image map will look like a disaster (which is as it should be) when rendered properly in Lux.

Are you referring to eyes with the reflections baked in? Those should be avoided in Poser as well, as the lighting will rarely match them. I know that a lot of images maps are made in that way, and that's unfortunate. The hardest problem is with backed-in highlights for hair textures. Those are absolutely the pits.

Quote - One question in this light, however. Will turning down Diffuse_Value in Poser weaken the effect when ported over to Reality?

That will lower the gain for the texture, basically making it dimmer. I would not suggest to use it. It's supported but only for some exceptional cases.

Hope this helps.

Quote - > Quote - Whatever the case, the point is that Reality will not recognize M4 if he is called from the Figures library. That's a significant datum to be aware of.

Nope, I have several figures in the Library and they are recognized correctly. There is something else going on.

Explain me this, then. I stripped my character down to the bare maps, and it still came up in Reality with Glossy on everything. (And yes, not only did I rescan; I created an entire new scene file.) Then I saved out the Materials and morphs and loaded them onto a freshly loaded M4 and tried again. Exported just as Reality is supposed to do.

Quote - Are you referring to eyes with the reflections baked in?

No, I had already worked over the eyes of this set. I'm talking about skin. Because the texture was made from photos, it already has highlights and shadows in it. If I'm going to use Lux, I'm going to have to do a careful sort through my texture sets. I like a lot of detail in my sets, but obviously not detail that includes highlights and shadows.

To clarify again, I'm talking about a custom M4-based character that the user saves to the Figures library. Obviously Reality recognizes Michael 4 loaded from the DAZ Figures folder.

Quote - Whatever the case, the point is that Reality will not recognize M4 if he is called from the Figures library. That's a significant datum to be aware of.

Quote - Nope, I have several figures in the Library and they are recognized correctly. There is something else going on.

I just tried loading different figures from the figure library with both M4 and V4, they are identified properly by Reality as "Michael 4" or Victoria4. I'm not even close to a Poser guru, but it looks like there may be a problem with how your M4(s?) is being saved, or maybe a problem with the cr2?

Does your cr2 reference an alternate geometry file (.obj)  other than "blMilMan_m4b.obj"? If so, that may be what is causing Reality to miss-identify it as "figure 1"

Thank you DustRider.

Just to shed some light, Reality does not look at the internal name, "Figure 1" or such; it looks at the geometry name, because that is unique among all instances of M4, in this case, and uniquely identifies the base model. So, you were right about pointing to the geometry file but it's not the internal name that is used for the material conversion.

Hope this helps.

BTW, all these items can be clearly seen if we click on the figure name in Reality, instead of clicking on one of its materials. The geometry file name is clearly labelled.

In the case of M4 it has to be blMilMan_m4b.

The geometry is unchanged.

I dunno. I guess it could possibly an extremely over-the-top caching issue, although still doesn't explain why it all exported as glossy in the first place. The fact that it exports fine when I do a fresh load of M4 and then load the morphs and textures from there would seem to point in the direction of Reality struggling to see that the CR2 is based on Michael 4. So maybe that's not the case, but I haven't seen a reasonable alternative explanation.

Believable3D, let's postpone this discussion after the 3.1 update comes out. There might be issues in some of the materials that you have in the stored presets that cause the internal conversion to stop. I have found a couple of those issues and solved them in 3.1. I'm testing the final parts of it and I expect to release it in a few days. 

At this point it's better to see if the issue persists after the update instead of trying to fix something that is already fixed.

Thank you for your patience.

Thanks, Paolo, sounds good.

Anyways I would have thought vector maps or normal maps would be wanted ?

ah ,no ,I don't know much about any Poser render engine.

Normal maps are defintely helpful and supported by Reality.

Cheers.

In Reallity I set the Cornea to arch glass, the diffuse and specular color to 255 255 255 and make sure the thin film thickness and the thin film IOR are at 0. with no bump map. The iris and pupil set the specular to 20 20 20 20 with glossiness to 9200 up to 9600.

Above is what the result, and I can adjust the size and position of the hightlight by adjusting the meshlight.

Quote - I dunno. I guess it could possibly an extremely over-the-top caching issue, although still doesn't explain why it all exported as glossy in the first place. The fact that it exports fine when I do a fresh load of M4 and then load the morphs and textures from there would seem to point in the direction of Reality struggling to see that the CR2 is based on Michael 4. So maybe that's not the case, but I haven't seen a reasonable alternative explanation.

I just tried with  my "prefered state" V4 that loads when poser opens. She has never had a texture on her, has no maps on her(when I loaded her originally from the library I used the MAT setting that is blank) I opened reality and it was Skin, glossy(eyebrows, lips) skin skin..etc till eyes then glossy, glass, glossy....BUT if I clicked a SSS texture set on her then opened reality...she did what Reality3d is saying. When I took her then into reality she went GLOSSY. all settings to glossy.

(to be fair I havent installed the last update for reality I got notified of)

But (at least on my end) you have to literally have NO maps on V4(so perhaps M4 as well) for it to work correctly. Just color the figure(beigh for skin, pinkish for lips, bluish for eyes etc) for it to work.

Quote - Here is an example by an expert user:

The left image needs a point light with the distance reduced to accurately compete with the right hand image.   The image on the left does not have the same material setup as the right hand side when it comes to specular.

The guy who is promoting reality is obviously biased and one sided. It's possible to make the left image look like the right in poser pro 2012. Just my 2 cents.

He said above he was posting for the sake of the Reality image, not for the DAZ render on the left.

I don't think you'll get exactly the same results in Poser, but certainly a lot better than the one above, as a look at numerous galleries, including my own, will attest.

There is another point to the "before and after" image that I posted, and that is the amount of effort necessary to get good results. Reality is about getting the highest level of realism with little effort. As lights behave like real lights, the lighting of a scene is much simpler and predictable

Materials have types so they are easier to setup and customize. So, it's a matter of efficiency. Sure you can get decently realistic results with 3Delight and Firefly but they require much more work and an intimate knowledge of the idiosyncharsies of the renderer. 

I wrote Reality because I was disattisfied with the unrealistic way 3D renderers use light, nowhere near real light, and materials. There are things that no biased renderer can actually simulate. For example, LuxRender calculates the amount of absorption of the light traversing a volume, based on the thickness of the volume. The light coming out of a piece of glass, for example, is weaker and tinted based on the color of the glass and its thickness. That brings a subtlety that is not available with biased renderers like Firefly, no matter how we work on it

Lastly, let's look at the work of Eli, aka ArtXtreme. If you look at his gallery you will see several pieces that are quite impressive. He is quite the skilled artist. He can definitely spend  hours and hour tweaking the Studio shaders to get some decent results. The point is: why? Why do we have to micromanage a biased renderer when we can get bettter results with the simple application of the appropriate material?

Cheers.