I’m talking about spontaneously disconnecting shaders.

Background info (read these):

• The issue as described in a thread on the mailing list.
• A workaround as described by eX-SI Support

The following script partly automates the solution described by eX-SI Support so if you have many libs it almost eliminates human error. It seems to have worked for us so far as a preemptive measure before scenes break or after having spent too much time fixing a scene. Import an asset, material preset or fix a broken scene, go through the hoops. This is not fun but until there is an official fix, we’re kinda stuck.

Run Application.MatLibFixStep1() which will convert material libraries to external references, prompt you to save the scene and quit Softimage.

Restart Softimage, open the scene you saved previously and run Application.MatLibFixStep2() which will reconvert the material libraries to internal storage.

Jean-Sebastien’s workaround is also worth investigating if the above doesn’t work for you (see the Softimage mailing list thread linked above).

One of the clients showed me a pretty cool use of the geometry stack in conjunction with Momentum’s DeformRigidBody operator. This operator is able to treat every polygon-island inside a polygonmesh as a separate rigid body, and, since it is connected to the geometry stack, is able to keep the shape of the rigid bodies in sync with the deformation happening below. This way you can create animated shapes, and have them influence the rigid body simulation in Bullet.

While I implemented this feature, I was not aware of all of the possible uses, of course. Since the interactive creative environment has been introduced into Softimage, the possibilities are endless, and it is very hard to imagine what users will come up with once additions to ICE are released into the community.

The client, who had to deal with a very complex effect for a commercial, used Momentum just for the rigid body simulation, while the deformation was done through ICE. What’s interesting here is that he is simulating the deformation using a turbulence method, and driving the rigid body engine with this deform.

By offering small building blocks that work well together with ICE, or even integrate into ICE as compounds, Momentum 2.0 opens a whole new world of possibilities for simulation. Goal-based simulation and user driven results are in reach. What thrills me the most though, is to see unexpected setups like this one. The community’s amount of creativity really produces so much inspiration for developers like myself.

I will continue to talk about techniques and tricks with Momentum on this blog, and try to contribute users’ experiences and solutions.

Here’s a capture of the effect:

Click here to view the embedded video.

Here’s a link to Momentum 2.0 product page:

http://www.exocortex.com/simulation/momentum

We have posted a series of other videos, including tutorials, trailers etc on vimeo, you can find them in our Momentum group:

http://vimeo.com/groups/exocortexmomentum

This is a good place to stay up to date on new releases and latest information.

Please let me know what you think, I like to be intrigued for other topics and solutions for complex effects.

Recently we had an issue where a single scene was acting wonky and for it to render we needed to coax it a bit into cooperating with a pre-render script. The production guys fixed their issue but it got me thinking and I decided it might be good to revisit Homam’s ideas but make it work with the siOnBeginSequence event… Or maybe even any event.

The idea is to have a single plugin that is extremely simple and that registers into the requested events. When the event is triggered, the plugin will inspect the scene and find any relevant annotation and execute it’s code. The plugin will find annotations who’s name matches the name of the event prefixed with run, runOnEndSceneSave for example.

The scene root is inspected for annotations as well as any other model no matter how deeply nested. Annotations’ code is executed depth first so if you had a scene who’s assets’ code needs to be run before scene code, you’re good to go. Finally, if any annotation’s execution fails, execution of all remaining annotations is halted; please debug your code.

The explorer screenshot shows an example where the scene contains code that will run when the scene is saved. The Model annotations that allows the runOnEndFileImport code to be run only once on initial model import. Let’s break that second example down a bit starting with the runOnEndFileImport code:

The flag1 parameter of the runOnEndFileImport is used to know if the code has already run once. The problem though, is that if you export the asset, it will export with the flag on and thus would not run on subsequent import. You could rely on the user to remove the flag on export but you could also implement two other event annotations: runOnBeginFileExport to unset the flag and runOnEndFileExport to switch it back on.

Have you noticed the Annotation object? Well, I figured that to add some context to the code in the annotation, on top of the standard Softimage objects (like Application), we could probably provide the actual annotation object that is being executed so you can then start rummaging in your scene at the appropriate location if needed.

Finally here is the Gist that implements the actual plugin that does the event registrations and annotation finding and execution. If you need this functionality on more or fewer events, just add or remove the appropriate ones in the ACTIVE_EVENTS list.

There are most certainly performance limitations to this that I haven’t investigated or measured. For instance, activating the siOnValueChange event and having tons of annotations in a large scene might not be a good idea.

Finally, if you’ve got a smarter way to find annotations under an X3DObject, please share!

So here is a quick revisit of my past post on decorators but this one is very generalized.

And some example usage…

This version of the decorator is fun (Yeah!… I said fun.) because you can change any value in Softimage temporarily, as long as the value can be changed via a Application.SetValue() call.

I think you get the Gist of it.

Phoenix Tools was a plugin company for Softimage 3D, and I was one of the founders. We did good and bad, and we eventually closed down in 2002.

Arete had an excellent reputation for their ocean and atmospheric library, called Digital Nature Tools. I think their main business was in military simulation, however they had a part in every cg-generated ocean in the movies of the 90s.

In 2001 we joined forces to port their software under XSI (I think it was 2.0). Unfortunately, after the first version came out, both companies shut down.

8 years later, I am working on a feature animation with a few shots in water, and I realized I still had on some cd the arete psunami libraries. So, I decided to give it a try. I removed the license check from the shaders and I compiled them with good old Visual Studio 6, linking against the oldest mental ray library I could find (3.3), and in the end it worked. I was kind of touched when I finally saw the displaced grid rendering in Softimage 2010.

I think I will do no harm to anybody releasing these shaders. Both companies are dead since long, and this is my little tribute to them and the talented people who worked there.

The addon is only available for win32, and no, no chances for other platforms. That Arete library is the only one I have. If you do, use it at your own risk (and fun, i would say. There are probably better ways to do oceans nowadays).

And, you know what, I don’t even know how the full package works. I don’t have anymore the documentation, nor the scripts we provided. If my old companions will find them, I will post them later.

The basic usage however is easy. You have to connect a DNT_Ocean_Sh and DNT_Time to a DNT_Ocean_Evolver. What come out is the ocean instance, that can then go into the other nodes. Also, you want to apply DNT_Air as environment to have nice reflection and the atmosphere.

time to release another plugin under the flag of Sixbirds Barcelona!

As already shown in a teaser video on vimeo.com, we worked on a plugin to use particles as pixels to unleash the power of ICE to textures.

This plugin requires Autodesk Softimage 2010 SP1, Windows 32, 64 or Linux 64 bit.

Provided in the plugin is a C++ operator, a custom ICE-Node, some compounds to drive the pixels as well as a sample project.

So what does it do? Let’s have a look:

Thanks to Steven Caron for food for thoughts, thanks to all of the beta-testers!

Once again I am proud and happy that the company I work for is enabling me to publish these tools under GPL, so source-code is included!

Please comment, let me know what you think.

Here’s the download link:

http://www.sixbirds.com/development/sixbirds_pixelparticles.2010_SP1_1.0.xsiaddon.zip

Later!

Helge @ Sixbirds Barcelona

PS: I noticed during the beta-phase of the plugin that is it fairly easy to create a basic feather system with this setup, I demonstrate this in the vimeo video also. How ironic! :)

The rendertrees have all kinds of materials, with bump, transparency and reflection in place.

The most obvious approach to solve the problem is brute force: writing a script that would traverse all the materials, and substitute each material with a constant one, using as color the diffuse color of the original material, and inheriting all the subtrees for the transparency and reflection mixing. This would have required a couple of days of scripting, and, as any brute force approach, is not really elegant.

Another idea we tried was tuning the normal. We replaced all the lights with a single directional white light, pointing downward. Then, we connected a constant vector to the bump port of each material, pointing upward (0,1,0). The light has no specular contribution and the ambience is set to black. This way, only the diffuse component of the materials is returned, and since the normal always points upward, the incidence with the light is always 1, so all the materials behave like constant.

Unfortunately this method has a major disadvantage: since the direction of the reflected and refracted rays leaving a (reflecting/refracting) material depends on the normal, the result is completely wrong for secondary rays, because we are moving the normal to an arbitrary (up) direction. So, using the bump port was not a solution.

However, this failure pointed us towards a better solution.

Again, we just had to fix the diffuse component. In all the material shaders (except a few exceptions like hair, which we treat separately), the way the diffuse component is computed is as follows:

1. Get the light color
2. Multiply it by the incidence
3. Multiply the result by the diffuse color

So, if you want to get back the plain diffuse color, you just have to tell the light to return 1 (white) divided by the incidence. This way, the material shader returns diffuse * incidence * (1 / incidence) == diffuse.

This the starting case (a phong sphere – top), and our first result (bottom)

And this is the rendertree for the light

Also in light shaders, the normal can be used (it’s the lit point normal). The dot product of the normal with the light direction L0 is the incidence, which we then use to divide 1, and return the result as the intensity of the light.

That was ok for a half dome, but what about the rest? A possibility is simply to double the light, specularly to the xz plane, cloning the rendertree (and L0 becoming 0,-1,0 for the other light). That would cover 99% of the cases, being any oriented surface sample being lit only by one of the two lights at most.

The “at most” is the remaining problem. If you have a cube, its vertical faces won’t be lit by any!

So, we have to expand a bit this setup. We start setting up a minimal light rig, ensuring that al least one of the lights will always hit any oriented surface. The minimum number of lights for such a rig is 4, equally distributed in space.

So, we take a tetrahedron of radius 1, centered at the origin, and cluster constrain a directional white light to each vertex, all pointing toward the origin.

Each light has the following rendertree (with a small change for each of them)

This is the tree for light L0: the left side vectors are the four lights positions, set by expression. Since The tetrahedron has radius one, they also represent the direction toward each lights. All their incidence with the normal is computed and sent to a positivity check, and this check drives a switcher between zero and one. So, the sum of these 4 switchers is the number of lights (1 to 3) visible from the rendered point.
This number is multiplied by the light incidence and the result divides 1, as in the single light case.

Why do we need the number of visible light? Since we have 4 lights, the total amount of light that gets received by the point is
L = L0*I0 + L1*I1 + L2*I2 + L3*I3, for each positive Iight. In fact, the material shaders won’t even query a light if its incidence is negative.
So, as before, we still return 1 divided by the light incidence, but also divided by the number of visible lights, so that the overall sum of the visible lights is always 1.

The other 3 lights have the same rendertree, except the dividing incidence comes from I1, I2, I3 respectively. For instance, this is the tree for light L1.

And finally, we have our constant result. You can download the rig here.

Edit: I upgraded the addon to version 1.3, see the 13th solver for new description of the Nulls 2 Nurbssurface. Additionally I fixed two bugs and removed some nasty logmessages from the Null 2 Curve solver. Some solvers are NOT compatible with the version 1.3, so I will keep the link to the previous versions around.

So finally after a good first round here at Sixbirds in Spain we decided to release some of the tools we are using for production to the community. At this point we are sharing our rigging solvers, a collection of custom operators for “solving” certain equations, like IK, Bezier projection, curve lookup etc. The collection includes 12 different solvers. Please have a look at this video, which gives you a quick runover of the technology…

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

Requirements: Softimage 2010 SP1, Windows 32, 64 or Linux 64 with installed Python 2.52 or higher. For installing python see
http://softimage.wiki.softimage.com/index.php/Python#Installation

The addon also includes a very handy custom command, called “sixbirds_rigging_inspect_op”, which allows you to look at the settings of the solvers without having to dig for them in the explorer. I usually map this command to F4, since I don’t use the F4 UI Slider feature all that much. Furthermore the addon provides a simple toolbar to apply all of these solvers, and adds a new simple “bone” primitive to the Get->Primitive menu, which is handy when creating custom IK chains. Also the addon will come with a sample project, one scene for each solver demonstrating the features.
The addon is provided under the GPL license, without warranty, and, as we like to say in R&D: As is. Please don’t ask for fixes or further features at this point, we don’t have the resources.

All of the solvers are applied by selecting objects in a particular order and creating the solver. I want to quickly summarize these selection orders so you can properly use the addon.

One note: All solvers use X as their main axis. This decision was made since the Softimage Bone primitive uses X as the axis along the bone. So all other solvers use this axis as well. This means, for example, that you will have to rotate controllers or the spline solvers or the squash and stretch for example, if you want the spline to point along Y.

1. SRT Spring
This is a solver which is able to simulate a simple transform based spring. You can select the channels you want to use for simulation (scaling, rotation and/or translation). To apply this solver just select any 3d object and it will create a null as a child of this object with the solver applied.

2. Direction Spring
The direction spring solver simulates a spring which is driven by a global direction, not an orientation. Just select any 3d object and it will create a bone as a child, with the solver applied. To see the difference between the SRT Spring and the Direction Spring just play with it or have a look at the sample scenes.

3. IK 2 Bone
This solver can calculate one of the different outputs of a typical IK chain, but also provides soft stretching and some more features like inverting the solve etc. To use this solver, please select a) the root, b) the effector, c) the upvector and d) the output object. This solver does not create 3d object by itself, so if you want to apply to a bone you will have to create a single bone first (Get->Primitive->Bone). The solver also creates a property on the root object to drive all output objects (if you create more than one) in a central place.

4. IK FK 2 Bone
This solver has the most complicated selection order of all solvers provided in the addon. To apply it you nee to select a) The root, b) the IK effector, c) the IK upvector, d) the FK first bone, e) the FK second bone, f) the FK effector (wrist for ex) and g) the output object. This solver, like the IK 2 Bone, does not create output objects itself. This solver also creates a centralized property on the root object.

5. Simple Spline
This solver calculates a transform on a piece-wise-bezier defined by as many 3d objects as you want. The tangent of the bezier are the local X axis of the 3d objects driving the solver. To apply it simply select at least 2 objects (or more) an apply the solver. This solver creates a null as a child object of the first controller. The Simple Spline also creates a property on the first controller, to drive all created output objects in a central place.

6. Rolling Spline
This solver calculates the same bezier transform, but requires a secondary layer of controls to allow for continuous rolling along the spline. For using this solver you need to have a two level hierarchy (like parent_ctrl -> child_ctrl) or at least two controllers. Please select the child controllers ( at least 2 ) and apply the solver. It will create a null as a child of the first selected controller. Please have a look at the sample scene to get a better idea. The rolling spline, as the simple spline, creates a centralized property on the first controller.

7. 4 Point Surface
This solver computes a transform on a iso surface build by 2D bezier curves. These curves are defined by 4 controllers (the corners of the iso surface). To use this solver select 4 objects, it will create a null object as a child of the first corner object.

8. Interpolated Pose
The interpolated pose solver calculates a pose in between two other poses. To use it simply select two 3d objects and apply the solver, it will create a null as a child of the first selected object.

9. Squash and Stretch
This solver can calculate a scaled output transform based on the distance of two objects. The scaling for this effect is done along Y and Z. To apply the solver, select the first object of the distance calculation (hip, for example), the second one (chest) and the parent object for the new null. This can be for example a vertebra on the spine.

10. Null 2 Curve
This solver projects  an object onto a curve. This is useful for facial rigging and for anything that has to travel on a path, while being driver by a visual controller. To use this solver select a) the driver ctrl, b) the upvector ctrl, c) the input curve) and (optionally) d) the output curve. The solver will create a null as a child of the output curve (or the input curve if you just had one curve selected).

11. Curve Sliding
This solver reprojects a curve along itself while maintaining the length. This is useful for keeping the length on a curve, even it is deformed. To use this solver, just select one curve and apply it. If you want to use the sliding on top of enveloping, for example, ensure you have the animation construction mode selected before applying it.

12. Curve Collision
This solver does a simple collision with soft distance of a curve to a nurbs surface. This is useful for having curve being pushed by a teeth proxy in a facial rig, for example. You can use this solver in conjunction with the curve sliding solver. To use it, select a) a curve and b) a nurbs surface. Ensure that the surface is closed, please test with a nurbs sphere first. The collision object is supposed to be really, really simply to give you good feedback.

13. Null 2 Surface
This solver projects  an object onto a nurbssurface. This is useful for facial rigging and for anything that has to travel on a surface, while being driver by a visual controller. To use this solver select a) the driver ctrl, b) the upvector ctrl, c) the input surface) and (optionally) d) the output surface. The solver will create a null as a child of the output surface (or the input surface if you just had one curve selected). The solver uses a relative mapping, similar to a pen table (tablet space to screen space). Feel free to post questions if you need additional assistance.

Ok, after all of this information let’s have a look at a second video, in which I will go over each solver, reapplying it and test-driving it.

I hope you all enjoy the videos and find something useful in them. We are trying to design more tools in a way that they are easy to share, and we at Sixbirds want to follow that move of being able to publish more production tools.

Please let us know what you think at

development (at) sixbirds.com

Or feel free to post comments here at XSI-BLOG.

Last but not least: Thanks to all of the other providers of free software / plugins and the helpful Softimage Community!

There you go!

http://www.sixbirds.com/development/sixbirds_rigging_solvers.2010.SP1_1.3.xsiaddon.zip

(older versions:)

http://www.sixbirds.com/development/sixbirds_rigging_solvers.2010.SP1_1.1.xsiaddon.zip

Best!

Miquel & Helge @ Sixbirds

Everyone complained (including me) that the old particle system was too weak, too limited…. But it was fast to get some things done. To randomize a value, for example, you simply had to open a property page and set a variance parameter. Partly because ICE is so open, to vary a parameter, you have to search for the desired compound or node modifier, drag & drop, connect ports and then set values in the new compounds. Read me right, ICE is very powerful but if you have to modify dozens of parameters hundreds of times in one typical work day, this work flow becomes redundant an inefficient. There must be a way to be quicker.

Softimage proposed a work flow that can be described as follows: a technical director connects basic nodes, designs compounds and exposes ports. An artist, who is not necessary knowledgeable of ICE, then sets the different values of the exposed parameters. Some problems may arise with this approach. How can a TD predict every alteration needed by the artist? In the context of a particle simulation of falling rain, for example, a TD may have to design his compounds to support, for a simple shot, wind and gravity. Then, another shot may require water splashes from the droplet hitting the ground. Another still, requires the same rain but with the added effect of coagulating droplets on a smooth surface. And so on. You can easily imagine multiple variations of the same effect. So how are TDs supposed to tailor their compounds to fit all of the artists needs? One obvious solution is to build a system of compounds rather than a top level one. Yet the artists would need to be taught and learn how this system works and therefore, learn how to use ICE. Yes, maybe… but unlikely. I know many technical XSI users that were clueless on how create a simple simulation; artists, even less probable. How can technical directors empower artists without limiting them with a simple set of parameters? There should be a window to deliver the power of ICE to artists without being too painful. Artists should be able to easily create simple particle animation. You do not need to be a mechanic to drive a car.

With these observations in mind came the search for a way to simplify the ICE work flow which any Softimage user would understand and produce simulations in no time. The intent is not to replace the current work flow but to complement it and accelerate the multiple iterations needed in order to design particle simulations. Subsequent refinements, complex connections or relationships can and should be achieved the traditional way by connecting nodes and compounds in the ICE tree. But once a new solution is found, it should be easy to re-integrate it in a simpler work flow system. It should also be seen as an added value to cut the time to help generate about 75% of particle animation scenarios.

You do not need to look very far to find solutions. By simply looking at the different ways shaders can be modified, it is easy to wonder why ICE property pages were not designed the same way. Isn’t it faster in many situations to create connections by using the plug icon in a shader’s property page rather than opening it in the render tree, dragging and dropping a node, then making the connection? It should be the same in ICE property pages. No?

Also, all parameters affecting the simulation should reside in the same property page. With a typical ICE tree containing easily 20 compounds or more, finding a parameter often requires a search through many compounds. Too many doubles clicks are required to access the compounds’ parameters; why not put them in one location. When a scalar is randomized for example, the parameters associated with randomization should replace the original scalar in the top property page. You say: isn’t the top compound intended for that? Yes, but it doesn’t expose ports automatically. Remember, the goal here is to create particle simulations in a production environment; not to design ICE trees in a R&D context.

In the following video, I demonstrate a working prototype. It shows the above ideas in action with the exception of having iterations made through parameter contextual menus instead of the plug connection icon menu. The Softimage development kit does not give access to this type of UI widgets for ICE compounds property pages. Also, for clarity’s sake, it would have been beneficial to have used tabs in the property page to seperate emission, particle type, forces, triggers and events. This was not implemented. This prototype was written about a year and a half ago with a beta version of XSI 7.0 and unfortunately has not been updated to work with the current version of Softimage but would be relatively simple to rewrite. I must also credit my colleagues at the time, Jeff Wilson, who helped with the original concept and Javier von der Pahlen who co-wrote the prototype. It is important also to say that I was an employee of Softimage at the time when that prototype was written. As a long time user of Softimage’s products, I was trying to push solutions that made the work of technical directors easier. Unfortunately, this concept was not accepted. But it remains a great concept on how technical directors can go beyond compounds and integrate ICE in production pipelines more efficiently. It clearly illustrate the ability to build a simple particle animation rapidly without having to access the ICE tree. All iterations are made through the property page.

I simply wanted to share these ideas with the Softimage community and start a discussion. As, hopefully, more and more people will be using ICE, I’m sure that work flows will evolve to more efficient ways to manage ICE trees. Maybe it’ll lead to similar solutions, whether it comes from Autodesk or the community. I think it’s really cool concept and it would save many users time and headaches. What do you think? Is this type work flow worth exploring?

PPG Based Particle Animation Work Flow With ICE from Hans Payer on Vimeo.

HDRShop
HDRShop plugin Diffuse_SH.

I used to work for a 2 years at Framestore-CFC in London. That mean I use Maya and PRMan as my main application. During this year I learn a lot of thing but also hear a lot of false assumtion about rendering in general. Typically the common comment was that PRman was more suitable to render complex character and that MR was very slow for this kind of job. In fact people arguing about this doesn’t not really know what are the status of modern rendering such as MR, V-ray or any others assuming everything was frozen since 5 years or just repeating what the veteran keep repeating.

But I am not engaging a new flame wars between renderer. Actually I don’t care which is the better today in 2008 you can produce beautiful picture with any renderer available in the market ( and yes that include maya’s software render well known to be a piece of crap ;) ) The most important is the guys behind the scene. But I need to put everything in their respective context to elaborate and may be justify what and why I will describe later.

Actually mental ray is very fast, if you do things correctly. If you don’t do things correctly ( such as massive spatial and/or temporal oversampling ) it as well as any other renderer will be very slow. But I always get this "PRMan displaces faster" stuff. Of course it does…. until you actually trace a ray.
You have to know that PRMan lives in a mindset where raytracing is so slow that you avoid it at all cost. The thing is that in PRMan, if you try to shoot a ray, it too has to do all those things that a raytracer do by nature. So the minute you actually shoot a single ray, PRMan has to do what mental ray always does…. and the comparasion suddenly isn’t so much in favour of PRMan any more.

So people using PRman developed a completely different approach to same problem : Lighting and Rendering a scene while trying to avoid at all cost raytracing. That what is interesting. What will happen if I use these approach with Mentalray within XSI ? Maybe I can have a hybrid solution keep the best of the two world to render my character(s) ?

Diffuse Convolution on Environment map

What’s that ? To keep it simple you can assume that a diffuse convolved map is envmap where you apply a smart blur that will give you the result of sampling this envmap with an infinite number of rays with the Final Gathering on a perfect lambertian surface. For more information you can refer to Debevec’s research ( the father of HDR images ).

Having your envmap pre-blurred is a great advantage because you don’t need to sample it several times to get the correct illumination. Only one sample suffice to get the illumination on your surface. Actually you must cast only one ray. Otherwise you will average twice the map and the illumination will not be correct any more.

The ray direction that you will cast must also be in the same direction as your surface normal. The Xsi’s Ambient Occlusion setup correctly will do perfectly the job. You need one sample , the spread will be very small to not deviate from the normal ( 0.01 ) and the mode should be set to environement sampling. Obviously you can code a shader that do the correct environement lookup. I am using the XSI’s AO shader because it’s available out of the box.

Render Balls simple test.

Env sampling brute vs FG vs Diffuse Conv

The way I set up the scene is very simple. I tried to get the contribution of the envmap once convolved and only this. So there is no illumination model just different approach.
The HDR used for this test the one called beach.hdr that you can find at debevec’s website. The map that you download is an angular map so you have to convert it to spherical coordinate system. The easiest way is to HDRshop and convert to angular map to longitute/latitude map. Once the map ready, I put it in my scene as an environement map.
The first sphere is the result of an AO shader set to environement sampling mode with a spread of 0.8. I had to crank up the sampling to 1024 to get a smooth solution. AO env sampling is brute force approach. There is no importance sampling so that mean you have cast a lot of ray to get a smooth result specially with high dynamic range image. And obviously that be very slow. It’s the slowest render.
With the second sphere I used to FG to sample env. Same settings as before except that I use a shader that return irradiance and activate FG. FG is a lot faster that the previous method because it doesn’t sample every point with 1024 rays. Instead FG will sample a certain amount of point and interpolate the result between the point calculated. But for this comparaison I pushed the number of rays to 4096 to make sure I got enough accuracy to have fair comparaison with the quality of the next approach. Even by pushing the number of rays to 4096, it was still faster to render with FG.

With last sphere I made a diffuse convolution in HDRshop ( using the SH_diffuse plug in because it ‘s a lot faster than HDRshop’s function), applied the resulting image as an environement map and use the XSI’s AO shader with the sampling set to 1 and the spread to 0.01.
The render time is ultra fast and match FG solution. It ‘s actually realtime because the convolution has been already calculated once in HDRshop.

Render Balls too simple let’s try with something that got balls.

We got a exact match with the FG for a fraction of time. We can conclude that the diffuse convolution is good enough to simulate FG. But in our test we were using simple sphere. This an ideal case but we needed to check first if the lookup was correct before to move on something more serious.

I like buddha. I like him because it’s a one million polygon model that can be compared to any displaced model push out from Zbrush or Mudbox.
I have simply applied what I did with the spheres.
The first render is with an diffuse convolved envmap. It took approximately 50 sec to render with a large part of preprocessing the scene. If I had a realtime shader could get the same result ( minus anti aliasing ) in realtime. Obviously there is no occlusion calculated but that due to fact I asked only an environment lookup around the normal of the surface.
The second image is what you get if you were using FG and third one is a difference done in shake
to highlights the difference between the two renders.



As you can see only the occlusion and the FG colored bounce are missing. If you apply a simple occlusion on the top you will endup with an image that is fairly close to the FG solution but with only a fraction of the time involved by the process.

OK but in production is it worth to use it ?

Well I will say yes and no. It depand the number of shot you have to do and the time you got to complete them. This technique involve a bit of setup at the shading level while the using FG is straight foward. So if you are working on movie that need a 2K ( or more ) render then yes. Memory foot print is very low and it’s damn fast to render it specially with very heavy object like displaced object or Hair object..
At the moment you need to set this at the shader for every object. Ideally the best will be to set this as a global ambience. Unfortunately you can’t plug anything in the global ambience parameter. So the best if to use a light that cast only ambient light. And for that you need to code it so ask your favourites shader writer to do it.

Publications :

An Efficient Representation for Irradiance Environment Maps