Hi All, I've been playing around with GI in poser the past few days, and I decided to compare the different ways of lighting a simple scene, and see what result I got.

Here it is :

**TOP LEFT
**1 Single spot light to the left of the camera, as you can see, almost no light in this scene at all.
Please note the Env. Sphere (see below) is turned on in this image.
RENDER TIME : ~2 Minutes

**TOP RIGHT
**1 Single Spot light but this time with GI turned on.
Please note the Env Sphere is turned off.
Almost no difference in this and the last image, you will notice the light interaction between the green ball and the larger light-blue one. also the floor and large ball are interacting.
*RENDER TIME : ~25 Minutes

MIDDLE LEFT 
1 Single Spot light and 3 Infinite lights casting no shadow at about 10% intensity
This was an attempt to create the Bottom Left image using just infinite lights. other than the reflections on the green ball, this came out OK.
Env. Sphere is turned off.
*RENDER TIME : ~3 Minutes

MIDDLE RIGHT 
1 Single Spot light and 1 Single IBL
This looks completely wrong. the ambiance created by the IBL is very unrealistic. IBL really failed here.
*RENDER TIME : ~5 Minutes

BOTTOM LEFT 
1 Single Spot light
This image uses the Environment Sphere. its a UVBall scaled to 50,000% and given a bright Aqua ambient color with an ambient setting of 0.25. Thanks to GI, this means the sphere PROJECTS light into the scene.
RENDER TIME : ~40 Minutes

The final image looks incredible. although some more tweaking is required to the GI settings and render options. GI really brings out the polygon edges on models, I did not have Smooth Polygons enabled, which would have removed the bands on the large ball. Also, the entire scene looks a little "gritty" as there are not enough GI samples for the lighting to come out smooth.

As you can see, the render times jumped a huge amount with GI, even in a scene where 90% of the photons would dissapear into the void.

The following are the material settings :

First image is the Environment Sphere Material, the second is the Material used on all objects (except Green ball which uses the Primitive Default material)
*All objects have Diffuse color changed

*GI is definately the key to getting fantastic lighting in poser. Whether its implimented or not, I can see people will start submitting some amazing images using GI in poser!

Here is the full size render of the GI + Env. Map image :

You will notice that turning GI on simulates Ambient Occlusion automatically, which makes sense when you think about what GI does.

Attached Link: Poser Based Sky Dome

But the concept of tackling this with just one light is awsome.  I did'nt think Poser had GI, where is it enabled?

How big is the lower left scene; could it be upladed to this thread, is it available anywhere?

the above scene is a simply creation of mine using primitives.

Here is a link to download the PZ3 file and the Python script used to create the final image posted in Post 2.

Uncompress the file to your POSER folder, the python script will be placed in RuntimePythonposerScripts folder along with all of posers scripts. It is called GI_HI.py

NOTE Scene Settings:
MAIN CAMERA - Used in above images
SPOTLIGHT is currently turned off, Raytrace shadows used in above images.
UVBall4 (Env. Sphere) - Currently not visible. Make visible for GI.

*Angelouscuitry

*All of the images in the compilation above are the same scene, with different lighting.

To read up on GI as it stands at the moment, head over to this Thread. Theres alot of information in there, so read slowly and take it in if your going to start playing with it. and you better be patient LOL render times can be scary

"BOTTOM LEFT
1 Single Spot light
This image uses the Environment Sphere. its a UVBall scaled to 50,000% and given a bright Aqua ambient color with an ambient setting of 0.25. Thanks to GI, this means the sphere PROJECTS light into the scene.
RENDER TIME : ~40 Minutes"

May I suggest posting your hardware specs
to give a better baseline for your render times.

cheers

When a 3D mesh becomes a rightously defended personification of your personal desires
It has become an IDOL and YOU have become its worshipper,slave and servant
-Tain-

My Computer specs are as follows :

CPU : AMD Athlon 2600+ (running at 1.7 Mhz)
MEM : DDR 400 1Gig
HDD : SATA 320G 10,000rpm
VID : Geforce 6800 Super 512mb
O/S : Windows XP Pro Sp2 blah blah

I have posted the above scene rendered at MAX quality (took 9 Hours) here.

Pretty cool ! I think you should also consider doing a standard cornell box render. That way we can compare the results with other renderers also.

See here:

Cornell Box

And this is what the reference cornell box looks like:

The GI quality of a renderer is measured by how close it renders to that pic

**templargfx,

**I think reference to the other recent GI thread is in order, here:
http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2704900
(GI discussion gets going deep in the thread)

and a notice that Poser GI is not officially supported, although yes the elements of control are 'there' if you dig.

Hopefully, GI will be fully implemented in PoserPro.

Very exciting and thanks for this work templar

whoops, i now see you DID reference that thread!

I did some GI cornell box renders in poser and carrara. it took 11 hours vs. 20 minutes, so FFRender needs some work IMVHO. other problem: GI depth in poser is fixed at 3, which reduces realism somewhat and means it can't match the above pic posted by GH.

you have to open the script and change the parameters in text editor, then save it back. Run it just before rendering; that's all you have to do, just run the gi.py and then render with FF. Turn off AO on your light(s) and in nodes

I spent a painstaking long time re-modelling (IN HIGH RES LOL) a Cornell Box and the short and tall box inside it. All my dimensions are smack on with the specifications from Cornell University of Graphics.  When I get home tonight (at work) I will import it into poser, configure the light and camera to best represent the real cornell box specifications and see what comes out!

Angelouscuitry
Did you have any luck getting the scene to render with GI? or are you still stuck?

Great, can't wait to see your results :)

One thing that was not mentioned is that gi and radiosity are not the same .. As in the cornell box you can clearly see the effect of radiosity. Somthing poser does not have.

GI is the generic term used for all lighting in a render. It refers to any technique that not only takes into account 'direct' light (from spotlights for example) but also 'indirect' light from other objects and the environment.

Global Illumination

Radiosity is one of the algorithms used to do GI, it is the oldest and least efficient one. Newer techniques use more efficient methods like photon mapping or path tracing.

Firefly uses photon mapping AFAIK.

poser7 may use path tracing, since the variables involved are giDepth, NumSamples and NumBounces (the latter was implemented incorrectly). it may be better documented in poser8. I can't find any variable that uses keyword "photon", altho MaxICSamples and NumSamples may be somewhat analogous to photon count. radiosity AFAIK is just a generic term for the tendency of indirect light to bounce off object surfaces and illuminate other surfaces, based on the spectrum of light absorbed by the first surfaces hit by direct white light. poser7 can demonstrate said effect to a limited ray depth. the variables involved in GI depth and attenuation can't be varied without recompiling P7/FFRender AFAIK.

Hmm you could be right, dunno why i assumed it was using photon maps. Now that i think about it, photon mapping creates actual file maps on disk and poser doesn't seem to create anything like this when you enable GI. Maybe one of the people 'in the know' could clear this up ?

And I think the confusion about the term 'radiosity' comes from the fact that the word is also used in optics and thermodynamics. But there really is an actual algorithm called 'radiosity' in GI theory as well. It's main limitation being that it can only do diffuse reflection, and very slowly at that. which is why it's not used much anymore. See here for a SIGGRAPH paper on it:

Radiosity

the developers aren't able to tell us much. in poser 7, all the documented GI variables come with a line similar to "use at your own risk". we'll hafta wait until public release of Poser 8 for more info.

Sorry for asking but,

Is the python itself work for both Poser 6 and 7, or just 7?

Thanks,

JB

python works in both p6/7 (windows) and p7 (mac).

well, I gave up with the cornell render last night, I will attempt again this evening.

The problemS I encountered are as follows :

Too much reflectance.
Getting the right amount of reflectance and absorbance on the surfaces in poser is close to impossible.  I am going to have to come up with some type of node-based shading system I think

Light Output.
The light used in the above scene is a 100watt globe. the wavelength information is provided by cornell university, thanks to matlab I have the exact RGB value of the light base color. unfortunately, I am unable to increase the brightness of the light within poser without it altering the RGB values of the light color. meaning if I use the base color of the light provided, the entire scene is extremely dark. I am going to have to fake the light, and make up my own settings to try and reproduce a similar lighting technique in poser. perhaps an immiting surface will help.
Also, the light in the real world is not a point light, but an area light, Poser doesnt have these, so I will probably need to rig something up for this too

Overbright Paths. 
Some of the calculated light paths seem to give the surfaces points of extreme brightness. this can be overcome with settings, but it shows an obvious flaw in the GI algorythm.

Incorrect light interaction with extremely close surfaces. 
Corners and other closely placed polygons seem to have an adverse affect on your rendered image. Instead of creating a natural AO due to minimal light bouncing right into the corner, poser actually seems to light up the corners under certain situations (it doesnt always happen) no idea how to fix this "issue"

Camera Settings. 
The camera type and size are specified by Cornell, but translating those to poser failed miserably.  I did create my own camera with the same perspective, size and position as the photo, having my cornell box match ALMOST exactly to the original cornell image. but due to the real photo having lens distortion that is then fixed in post processing, some of edges on the box itself dont quite line up. the small and tall box inside line up perfectly though.

Hopefully I can figure out how to get around these things. I think I might have to move away from the cornell scale, and really boost the scale up by around the 1000 mark.

As it stands, GI in poser is not very friendly, I can see that entire scenes will need to be specially configured for GI, a simply light set change is not going to be enough, at the moment at least.

maybe the entire Poser Universe will be scaled up for the next release.

Kudos for the persistence and research. E-F should give you a call.

::::: Opera :::::

LOL. wouldnt that be a strange phone call :P

I hope they do up the global scale in poser, its microscopic at the moment, in Poser 5 it actually caused renders to not render properly at there default scale. In Poser 5 I used to up everything to 500%.

The additions in Poser 7 seem to have removed the problems with rendering, but the scale is still tiny.

After modelling the Cornell Box in Milkshape 3D, then using Polytrans to convert the size to real world values, I imported it into poser. the cornell box (which measures 9 inches a side) was so large that the entire model couldnt be seen in the preview window, it was too large, and the camera cutoff was stopping the object from rendering. after scaling down, it seems that Poser's natural scale it 6.385%

LOL. wouldnt that be a strange phone call :P

I hope they do up the global scale in poser, its microscopic at the moment, in Poser 5 it actually caused renders to not render properly at there default scale. In Poser 5 I used to up everything to 500%.

The additions in Poser 7 seem to have removed the problems with rendering, but the scale is still tiny.

After modelling the Cornell Box in Milkshape 3D, then using Polytrans to convert the size to real world values, I imported it into poser. the cornell box (which measures 9 inches a side) was so large that the entire model couldnt be seen in the preview window, it was too large, and the camera cutoff was stopping the object from rendering. after scaling down, it seems that Poser's natural scale of 100% is 6.385% in the real world!

think about that, 1 meter in Poser is actually only 6.3 centremeters!

reconsider it, templar. one may not need to be so precise with one's first attempt. it's possible a first-order approximation will be enuff for now. for example, I believe poser7 GI can cause the green and red to be picked up by the two interior boxes, but poser7 GI depth is insufficient for said colours to be bounced off the boxes and onto the floor.

Thank you for taking the time to do these experiments.  The GI render looks so much better than any of the other examples, it's almost like comparing a picture to a painting.  Hard to explain, but it makes the image look warmer and more alive or something.  The IBL didn't show any detail at all on the smaller globes.  So interesting.

Justpatrick:
You are very right, and I too was suprised to see how badly IBL handled this scene. The actual reason for such a bad render is that IBL works on the principle that no light from any differing directions will be the same. With GI, you can render a scene with the same color coming from all directions, but as that light actually physically interacts with the scene before lighting it. the end result is realistic. IBL however simply lights the object with color X from direction Y without the light interacting with the scene beforehand, hence the washedout ambient look of the image.

I could have got a better IBL render using a different IBL image, but then I would not be recreating the same scene as the GI one.

Miss Nancy:
Actually you are wrong, with my renders I did last night, the light was coming off the small box and lighting the ground green (but behind the box when veiwing from the correct camera angle)

from my experiments, ginumbounces controls the number of times a single light calculation will bounce off surfaces before destroying itself on the next surface. this means, at the default 3, a single light calculation will interact with, at most 4 surfaces.

In the cornell scene, most of the light seems to bounce twice before losing any visible effect on the scene, however some light does use up all 4 bounces.

Also of note, 100% reflective surfaces dont seem to "use" on of the bounces when contacted. handy

The reflectance of the surfaces (using a basic diffuse only setup in the material room, with a diffuse of 0.68) actually reflects too much light for such a large scene (this is where the scale comes into consideration) despite the fact the box is 9 inches a side, poser makes it TINY so the distance the light travels before losing its energy is incorrect. this is (AFAIK) the main reason my test renders came out so, well, wrong.

That being said, the renders I did do looked awesome, just not correct LOL

Once I've finished playing with the Cornell box, I am going to try playing with V4 in GI, as my previous little plays showed some extreme results of the "Incorrect light interaction with extremely close surfaces. " problem I mentioned above. especially in the arm pits and eyesockets.

But thats getting ahead of myself.

try setting irriadiance caching to 1 and then use my GI_HI.py script at the top, be prepared for some funky looking patterns. dont know why this happens, but it looks cool. completely useless though.....

and its my pleasure :D

do not set IC at 100% - it may require infinite render time. either set it at 99%, or set maxError at 0.01 (equivalent). "SetGIIntensity" has no effect on the scene. "SetGINumBounces" varies GI Intensity, but GI Depth (bounces) is fixed by FFRender and can only be varied by recompiling FFRender. Increase "SetGINumSamples" to 64 for increased accuracy (less noise).

well, at least the set number is enough for a cornell render. I wish there was a decent description of how these settings interact with each other and firefly.

poser actually wont allow you to set it to 100, although if you do set it to 100, save the preset (it will say its at 99%) loading the preset will give you 100%, but it renders no different to 99% LOL

The Cornell render was still going when I left for work this morning.

I managed to fix a few problems I was having, mainly with the light source.

The light is now outputting the correct color, to fix the intensity problem, I took a completely different approach to my first attempt, instead of modifying the light, I surrounded the light (above the hole in the roof) with a hemisphere, this hemisphere emmits a medium level pure white light which backs-up the point light (it also makes it work more like an area light, which is extremely handy!)

The render, about 70% complete was looking very good, I had a relatively low GI settings, so the end image will be grainy, but I just can't bring myself to increase the render time anymore for what is essentially mucking around.

I will post the result when I get home (providing its FINISHED LOL)

hey send the pz3 to me and I'll crank it up to the sky and send it on a 24 or 36 hour render. I am crazy that way.

::::: Opera :::::

lol

here you go :

Cornell.zip

Inside the ZIP file are 3 files :

Cornellbox.pz3   - Poser 7 scene file
Cornellbox - front missing.obj       - Wavefront OBJ model of cornell box
Cornellbox - front missing..mtl      - Material file for OBJ model

Please note, the OBJ version is not completely accurate as far as the boxes inside are concerned. I replaced the boxes with poser primitive boxes. loading the poser scene will give you an accurate model.  Also, the MAIN camera is setup to mimic the Cornell shots.

Everything should be setup and ready to go. the point light should have the right color, and the dome should be emmiting light. you may want to up the ambient value to around 5 to make it brighter.

Have fun LOL

thx fr the file, temp. on opening Cornellbox.pz3, it sez: "please locate Cornellboxmt5.jpg".

oh, thats the image posted on page 1 of the cornell box from cornell university, just save the image.  it is used as the background only, and I used it to get the perspective/camera etc correct, its also handy for comparing render outputs.

it is not needed though

Attached Link: http://www.graphics.cornell.edu/online/box/data.html

Ok, I am up and going. I started up a test render, just to be sure all was in place, at low settings. I turned that off after three buckets and have now cranked up the settings. You can see the quite agressive render settings in the image above. The gi settings are:

scene = poser.Scene()
if (scene != None):
 settings = scene.CurrentFireFlyOptions()
 if (settings != None):
  settings.SetGIIntensity(1)
  settings.SetMaxSampleSize(20)
  settings.SetGINumBounces(3)
  settings.SetGINumSamples(64)

My system is:
AMD 3500+
4GIG RAM
twin Raptor drives in RAID-0
Windows XPPro 

This computer has five fans. I call it "Sikorski"

This will be a long render. Please anyone who thinks I have been settings post here so I can turn it off in the next few hours and reset. It is 8:47 PM here in Los Angles; I am enjoying the Angels DESTROYING the Yankees and will be up for a few hours. It's only the end of the third inning and the game has been on for an hour and forty-five minutes.

TemplarGFX, thanks for doing all the hard work, and for being generous to put it into the community. I am sure your Poser Cornell pz3 will be handy for all of us when GI is turned on for real later this year (we hope.)

::::: Opera :::::

oh, the cornell box is sized appropriate to the figure scaler in poser. Its not its correct real-world size (the OBJ file is, although NOT if you load it into poser!)

Your settings look quite good. I have similar settings running on my render at home, although lowered the number of samples to 32 and no pixel samples.

your computer kicks the crap out of mine!

Miss Nancy :

The cornell box I created was created from the data on that page (it was .... interesting...) the only different I made was to straighten the red wall, I did this because at its original angle, it did not line up AT all in poser with the cornell image. oh well maybe I did something wrong on that wall :S

are you getting any artifacts? What is your irradiance cache slider set to?

I use 10 for quick renders, and 45 for high quality.

reason for these number? NONE lol

100 (or 99 in actuality) seems to make very little difference in the end result compared to say, 50.  I found anything above the 40-50 mark makes very little difference to the image, but ALOT of difference to render time.

I actually use the IC slider as my "GI Render Speed" slider.

Interesting thread....

1. Someone mentioned the bounce depth being hardcoded to 3.  I don't believe that this is true.  I could modify this figure in python.  AFAIK, whatever you save it to will not save to the pz3 file.  Either 2 or 3 give reasonable results.  4 is just too bright.

2. The GI in Poser is like a "gather node on everything", so operates a little differently to other GI's.  So don't expect it to give the same results.  It will highly illuminate surfaces that touch.

3. I found, based on a limited number of test renders, that there seemed no difference between the quality fo the render between 1 and 98 on the Irrandiance Cache slider (although render speed was impacted significantly as the slider went further to the right).  But full Irradiance Caching (set to 99)  gave a way better rendered result (but took many hours to render).

::::: Opera :::::

o.k., lookin' good, o.g. set maxsamplesize to 2 or 4 to eliminate more artifacts. (will increase render time by 5 to 10 times as long as render at maxsamplesize 20). this variable is similar to "accuracy" in gi renderers using photon maps. IC at 90% (maxerror 0.1) also helps. IC at 99% may not be much of an improvement over IC at 90 and shade rate 0.2, but it may take 2 to 5 times as long to render. shade rate 0.5 will include those black- line artifacts. just to repeat yet another time what stefan (one of the developers) said, they coded giNumbounces incorrectly, and it changes giIntensity (brightness) by mistake. there is no way to vary bounces (gi Depth) without recompiling FFRrender. ray depth has no effect on gi depth. in looking at carrara GI renders, I get the feeling that gi depth=3 is an adequate setting for a cornell box designed for the given reflectance values. assuming the absorbance of these surfaces is such that the indirect light attenuates by 20% - 95% per bounce (depending on wavelength), then there's still some light left after 3 bounces, but it still might work o.k. for those with computers fast enuff to do the calculations.

*just to repeat yet another time what stefan (one of the developers) said,
they coded giNumbounces incorrectly, and it changes giIntensity
(brightness) by mistake.

Ah.  I was thinking that the more times a ray bounces, the brighter the effect, so I mistook that for meaning it was bouncing more.  My mistake.

Well, I did a little animation last night, on a quick render to see how GI is effected by certain changes.

In this scene, the following things change as it progresses

Green ball goes from:
Colour : Green
Diffuse Value : 1
Ambient Value : 0 

TO

Colour : Green (same)
Diffuse Value : 0
Ambient Value : 1

Big blue-white ball goe from :

Standard diffuse shader (Lambert)

TO

Clay Node Shader (Oren-Nayer)

Red Ball changes shape (and thats it)

as you will notice, the green ball begins to emmit more and more light, and ambient goes up. but you will also notice that the object actually becomes blury. this is not caused by anything but GI, as rendering without GI gives a crisp clean sphere. VERY interesting.

Also note the big ball doesnt seem to change AT ALL. oh well LOL

at about frame 19 there is a HUGE overbright point on the ball. GI glitch? yep

the quality settings used here really show badly in the animation, the shading is very erratic.

still, it looks cool :D

progress report on my ridiculous render.

With latest settings, things are running very slowly, barely 10% or the render in about 7 hours. However....what I can see of the top rows looks really good....perfect gradation, very subtle and true, sharp corners, etc.

I'll report back sometime tomorrow.

::::: Opera :::::

yeah, that is slow IMVHO. I estimated it would take approx. 56 hrs. on my machine, and poser ain't never run more than 36 hrs in one sitting. keep us informed, o.g. p.s. temp - that animation is not bad. with the sketch-like changes, reminds me of plympton's animations.

Thursday morning, 8:00 AM Pacific

Well...................................................
You can see what I woke up to this morning.
Turned it off.

Speaking strictly for myself, enough already of toying with a stub of a promising but undeveloped feature. 

I am off for a weeks vacation and before that i am resuming my MakeHuman and 3DSMax exploration.

I really hope GI is beautifully implemented in PoserPro.

::::: Opera :::::

o.k., bon voyage. try to avoid the caribbean or cabo at this time of year.

Denver, family reunion

this is great to know.  i've always wondered how firefly actually stacked up to other renderers time wise, and now i'll have a yardstick.  right now i'm just beginning to research blender (most recent version has sss) and some 3rd party renderers (yafray, kerkythea, and the highly impressive indigo).   so now i'll have something to compare against when i finally get to testing.