View Full Version : Real GI in Maya Renderer... is it possible?
09 September 2002, 12:40 PM
A|W developed a diffraction shader for maya which uses the incandesence channel of the chosen shaders. Why can't this be done with a GI implementation? I know it isn't the same but the possibility's there right?
Another way it could be done is to approximate where the light would bounce off the geometry and position point lights with colour and dropoffs on the geometry but disconnected from the emitting geom, calculated invisibily at render time. Possible?
09 September 2002, 08:25 PM
09 September 2002, 06:17 AM
Great. Thanks for that link.
09 September 2002, 12:59 AM
realistic diffraction can not be done with any modern GI (photon mapping) renderers because these renderers only simulate the particle properties of light. if you think back to your physics class in high school, diffraction is a wave property of light, as are interferance and polarization.
09 September 2002, 01:09 AM
That gave me an idea. Would it be possible to make a pugin or mel script that does this:
:lightbulb Make a particle emitter at a selected light.
:lightbulb Emit the particles from the emitter.
:lightbulb When particles collide with a surface the surface luminance and surface colour are sampled from the collision point of the surface.
:lightbulb A light is created at the same coordinates as the particle and intensity and colour are set accordingly.
:lightbulb The created light is dissconnected from the surface
09 September 2002, 01:12 AM
bleh....too much trouble......and it might be significantly slower than a compiled binary renderer.
09 September 2002, 06:41 AM
array you party pooper.
09 September 2002, 03:38 PM
Yup it would be possible, but then, this is exactly what a photon mapper does, in effect. Doing it in MEL would be so slow you'd be dead before the render finished. Neat idea tho...
09 September 2002, 12:16 AM
But what if you only had to do it once. You set up your key lights and hit calculate then it places all the bounced lights. You just calculate once. This would be to slow for animation doing it frame by frame but it would be OK for stills yeah? I'm not talking thousands of lights, more like 128 lights, or make it adjustable - an accuracy scale.
09 September 2002, 09:31 AM
The thing to remember is it's a multi-iterative process. If you calculate light bouncing off just once, you don't take into account light that hits after the calculation! For example, take two walls facing each other, you could have a photon bouncing between them hitting all the way along before they ended up in your eye.
There's an OpenGL Cornell box radiosity demo using BSP trees I got from somewhere or other where you can see it working out the iterations in real-time, with the box getting brighter and brighter until some user-set energy cut-off is reached (i.e. when the photons are so low-energy as to have no worthwhile effect on the scene).
What I'm saying is, rather than trying to would it out automatically by tracing, it's better to do it by hand; that's what Pixar does and it works just fine for them!
take a spotlight for example with a 40 degree cone-angle. It hits a wall at an oblique angle and light rays would maybe bounce off over a 90-120 degree angle. You could simulate this with a point light here, but then where do you place other lights? They could be hitting say twenty other surfaces, before you know it you've got a problem of incredible complexity, the only way to solve it is a proper photon mapping algorithm, which trust me, you don't want to write in MEL. If you only consider the first bounce, the result will be too simplistic. If you try to go further, it'll be a complete nightmare.
Like I said tho, you come up with a nice idea, just a bit impractical.
if you want to do a radiosity-like solution, I thought this method up a while ago, while making a skydome script:
There's a plugin on highend by an A|W coder, may be in the Bonus Game pack, which implements the functionality of the Closest Point On Surface node (one fo the funkiest 'hidden' nodes in Maya) for a polygonal mesh. Probably called Closest Point On Mesh. Anyway, you give it a point in world space, for example the position of a light, and it'll give you information about a particular mesh near that point, for example it's UV co-ordinates, from the UV co-ordinates you can work out the colour of the mesh at that point (see where I'm going with this?).
So what you do is light your scene in the normal way, picking out the main light sources (say a light bulb in the middle of the room). Then pick out which are the brightest objects in the scene, e.g. the white-painted walls and a shiny red object in the middle of the room. So you make dummy objects for those that you want to cast bounce light, with many less vertices (tho of course how many is completely up to how many lights you want), and the same texture as the real object. Then you whack lights at every vertex and ramp the intensity right down. You'll also want to manually adjust the falloff and stop them casting shadows on the objects they're supposed to be simulating. Then link the light's colour up to the colour of the Closest Point On Mesh at that point in space and boom! Instant radiosity with colour bleeding.
Think that should probably work, tho doubtless you'd find trouble along the way. Also you'd need to fiddle with the lights a lot: probably want a master control null for all the attributes of all the lights in one object and stuff.
If you want to learn MEL, could be a good project to start on, hell I may even do it myself!
As with all things CG it's a fake, even your photon-mapping and Monte-Carlo is a fake (just a very very good one), but it may work well enough to fool!
09 September 2002, 01:33 PM
I was thinking like 2 or 3 particle colisions, nothing too demanding, It could get quite nice results. Well Pixar has a team of dedecated lighting directors and plenty of time to work with. Most other renderers these days come with GI even the latest Renderman.
Anyway, yours sounds like a good idea.
Make it into a nice plugin and sell it!... :rolleyes: er, hang on, that means I'll have to pay for it too. Umm on second thoughts give it away for free! :deal:
09 September 2002, 01:42 PM
tomb please check your pm
09 September 2002, 11:37 PM
It all comes down to how much work you have to do to get a nice image, and the method you described would I think not give the best "bank per buck", so to speak.
I gotta do some MEL anyway, to keep my eye in, so maybe I'll code this method I described. In effect, it's a simple extension of many other skydome scripts, except placed on objects using closest point on mesh. hmmm. Anyways, if I do write it, be sure it'll be on Highend3D, for free!
01 January 2006, 05:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.