James arrived early for the big PoserLand mirror ball tournament. But as soon as he took his seat he noticed something wrong. The mirror ball was not reflecting at the edges! He called over an official to complain.

"Sir, that is a regulation mirror ball." said the official. "See, the Poser manual clearly states you should connect a Reflection node to the Reflection_Color input."

"Well, it's wrong. A mirror reflects light equally, regardless of angle. This one clearly looks more like the scene has been painted on the ball and we're looking at diffuse reflection, not mirror reflection.", said James, who is famous for being a know-it-all.

"He's right", said a nearby photographer. Walking up to show them his digital camera he said "I can't even see James in this picture."

After some tinkering, the officials determined that some idiot (or malicious?) programmer had hooked up the Reflection_Color input in series with the Diffuse_Color input, which has a Diffuse node built into it.

---- Scene 2

Fortunately, they discovered that other inputs are just pass through with no internal modification of the input. So they moved the Reflection node to the Alternate_Diffuse input which, paradoxically, does NOT apply diffusion at all.

The photographer snapped another test picture. James was clearly visible now. Whew!

"Thanks, James", said the official. "I guess you DO know it all."

Have a look at the checkmarks called "Reflection Lite Mult" and "Reflection Kd Mult". They determine if the reflection input should interact with incoming light or the surface color - in your case, you'd simply want to uncheck Reflection Lite Mult. See also the Poser 6 manual page 299.

Ahhh - doh - (slinking away with shame)

Message edited on: 09/22/2005 13:17

I wonder if this knowlage can be used to make some complex reflection effects Humm may have to put on my evil scientist hat when I get home.

LOL! I was caught out by that one too, some time ago:-) But OTOH, Poser does NOT handle reflections correctly (along with most, if not all, other ray-tracing apps). It reflects colours and brightness on the surface, but does not reflect LIGHT back into the scene (and we all know mirrors reflect light, don't we?). P6 Ambient Occlusion may help with this - I've yet to try it, but I doubt it'll be work very realistically. The reason, of course, is that the time to calculate real reflected light would astronomically increase the render time. If you look in a mirror that is reflecting light onto a surface (from the right angle), you can see in the mirror not only the scene it's reflecting but also the light it's reflecting (a mirror will cast a bright area as if the mirror itself is a light). But that then affects the reflection in the mirror, which then affects the light output which affects the.... well, I guess you see where I'm going. It's almost infinitely recursive. Nature does it almost intantaneously. Computers need a little (a lot of) time to catch up:-) Cheers, Diolma

"It reflects colours and brightness on the surface, but does not reflect LIGHT back into the scene (and we all know mirrors reflect light, don't we?). P6 Ambient Occlusion may help with this" Ambient Occlusion won't help with that. It's not so much a "fault" of the raytraced reflections as it is the lights in Poser. The effect you are talking about is known in some 3D apps as "reflective caustics" (there's also refractive caustics, which is light that is bent as it passes through some refractive surfaces, like water, glass, etc.). Reflective caustics is light that is bounced back in the scene from a highly reflective surface. So, in order to have any kind of light bounce going on at all in a scene, you need lights that can emit photons, which Poser's do not. Some advanced renderers like Brazil, Vray, FinalRender, and MentalRay, can do it. You can fake it in Poser though... using clever shading or mapping techniques.

LOL, maxxxmodelz! OK, some advance renderers can do it. I've never been able to afford them, so havn't been able to try them out:-) But, actually, the principle still holds sound (if a little irrelevant for art-work). Light rays travel (by definition) at the speed of light. And they have the "Computing power" of the universe in which to do it... Ray-tracing (even if it DOES recurse, as opposed to no. of bounces) cannot ever match that.... But it'll get better..eventually. Cheers, Diolma PS. I'm a hobbyist, not a professional..

"Ray-tracing (even if it DOES recurse, as opposed to no. of bounces) cannot ever match that...." Oh, you're absolutely right, diolma! Even the most advanced, physically accurate renderers in the industry can NEVER reproduce exactly what goes on with light when it travels and interacts with surfaces in the real world. It would take a vast legion of quantum-computers to crunch those complex variables, and even then it wouldn't come close! ;-)

If only eFrontier would allow us to use other Renderman implementations besides Firefly, we could do this basically inside of Poser. Of course, they'd also have to allow user-created shader nodes to be used in the material room, which would need to be turned off by default for the newbies. Air, Pixie, and the big boy of Renderman, Pixar's Photorealistic Renderman all have some form of global illumination. There are a couple of others (including the discontinued Blue Moon Rendering Tools) that support GI partially. C'mon, eF, what do you say? Can Poser 7 give us an option of where it sends the Renderman bytestream output? Firefly is nice, but for those things it can't do, it sure would be wonderful to be able to render directly from Poser to another Renderman instead of having to go with the various clunky export workflow options. Despite my bickering, I really DO enjoy using Poser a lot. The less I have to fiddle to get my figures rendered with GI, the more I'll enjoy it.

Attached Link: http://www.stewreo.de/poser/poserman.html

To paraphrase a popular commercial in the States... BRILLIANT! BRILLIANT!

Stewer: The problem is, Poser now has PERFECT Renderman export when using Firefly only, or craptastic Renderman export via file:export. I appreciate your efforts with the Python script, but as you state on the Poserman page: "No shadow maps. No Material Nodes. No environment maps. Limited bump mapping." Which is why eF needs to make the Renderman bytestream that it sends to Firfly available to the user for sending to other Renderman engines. As I've stated above, I'm trying to avoid these clunky export workflow options. Having to recreate my shadernode setups is more trouble than it's worth, since I have Cinema4D 9.5, and can recreate shader setups more easily there. Unfortunately, this is still a clunky workflow, since I lose the ability to pose. Ideal workflow (obviously, eF wants to provide this, or they wouldn't have added Firefly): Pose -> setup shaders -> render -> tweak pose/shaders -> render, etc. Once again, since Poser is ALREADY spitting out excellent RIB to Firefly, there shouldn't be a lot of work involved to get it ready to use other engines (unencrypt the shader library, setup a dialog for the user to choose which renderer to use, etc).

Are you sure that Firefly uses RIB? If I recall correctly, it is not Renderman compatible, but just a different REYS renderer.

Firefly is renderman compliant.

Writing a RenderMan interface that not only writes RIB files but also takes care of full shader translation and texture map conversion is not easy: There are too many things that each renderer does in it's very own way and that does not translate to the other. In my opinion, eF should rather spend the development time on improving FireFly itself than implementing a 3rd party renderer interface that <1% of its user base are interested in. Writing a universal interface is not easy: Each renderer I have seen so far has its own format for texture and shadow maps and has different ways of how it deals with raytracing in the RIB file. Shaders are also different, I've had a lot of .sl files that one renderer would compile and the other wouldn't. After all, the pricing of commercial RenderMan plugins suggests that it is not cheap to provide full solid support: Animal Logic's MaxMan costs USD 990,00, Maxon's RenderMan support for C4D is only available with their very costly Production bundle.

I tried the PoserMan script, 3Delight reports:
3DL ERROR: Syntax error in token declaration "transmission" "string[]".
3DL ERROR: Syntax error in token declaration "trace" "float[]".
3DL ERROR: The interface of shader "D:3Delightshaders/poserSurface.sdl" is invalid.
3DL WARNING: Shader "poserSurface" is of the wrong type, will try "defaultsurface".

It renders the scene, but with no textures. I'm using 3Delight version 4.5.0

Stewer, that's why I'd rather they simply expose what's already there, make it available to the material room, and then lock it by default for the average user. The option to unlock it and set it up for use would be available for more advanced users, who could then hand edit the necessary files to work with their renderer of choice. This would take most of the work out of their hands, freeing them to fix other things. The Air comment was meant as a "if you really want to give us a superb renderer, aim higher" type of comment. Or, if nothing else, subcontract out that aspect of things to 2 or 3 people who could devote themselves to such a thing. Volfin: you may have to recompile the shader if Stewer's version was compiled with an older version. Stewer: I'm IMing you with a few questions :)

Yes, the shader needs to be recompiled for newer versions of 3Delight. I haven't touched the exporter in a while, unfortunately.

Doh! Thanks for the tip...