micropolygon vs physically

   12098   4   4
User Avatar
Member
4 posts
Joined: June 2010
Offline
Hi everyone!
I'm a newbie houdini . I don't undertand the difference of micropolygon and physically . And when should i user micropolygon or physically .
thank everyone :roll:
User Avatar
Staff
2540 posts
Joined: July 2005
Offline
There are actually three choices:
1) MicroPolygon rendering
2) Raytrace rendering
3) Physically Based Rendering

All three render engines use different methods to calcualte the final pixel value for a shading point on a given surface.

MicroPolygon rendering uses the REYES architecture based on PIXAR's RenderMan renderer which is an open specification and is quite well entrenched in the Feature Film industry.
MicroPolygon renderers are well known for their very fast rendering of motion blur and depth of field. This is extremely critical in feature film vfx work to match live shot motion blur. As they say, no motion blur? Go home.
MicroPolygon renderers are fantastic at rendering displacements. Since the geometry is cut up (diced) in to pixel sized geoemtry bits, these bits can be pushed and pulled (while background algorithms desperately try to sew the geometry back together) to create wild displacements with motion blur and depth of field.
MicroPolygon renderers only render the geometry loaded in with the current given bucket. This means insane amounts of geometry can be rendered with MicroPolygon rendering. This takes some care when dealing with geoemtry that is dynamically loaded at render time (delay load rendering) but with care, very efficient renders can be achieved.

Raytrace rendering in Mantra is used for calculating reflections and refratctions. As soon as a plate goes in to raytrace mode, all the geometry that is a candidate for reflections (based on the reflection mask) will have to be loaded in causing memory consumed to increase.

Hybrid MicroPolygon/Raytrace mode in Mantra is quite interesting. If you choose MicroPolygon as the primary render engine, the primary samples are done with MicroPolygon rendering. If you have any shaders applied that do reflections, then the raytrace engine is envoked and the secondary and terciary rays are calculated with the memory penalty described above.

Both MicroPolygon and Raytrace engines use what is called an Illuminance Loop to calcualte the lighting for the given sample point being rendered. This gives the shader writer immense freedom to determine how the light is calculated. Over the many years many cheats and hacks have evolved to allow realistic rendering and shading of geometry in a very quick period of time. Many of Houdini's default shaders do this. It is also easy to create non-photorealistic rendered images (NPR) with these two engines and the given shader programming interface (VEX and VOPs with Houdini).

MicroPolygon and Raytrace engines take a bit of work to get realistic images although with the advent of high dynamic range image maps and somehwat efficient ambient occlusion schemes and in H10's path tracing enhancements, it is easier to achieve the goal if realistic renders. You can also simulate irradiance and global illumination but at a cost. At some point, PBR will start to overlap with MP/RT and that is where the choice has to be made when realistic images are needed/required.

PBR or Physically Based Rendering exists to render physically accurate imagery. Unlike MP and RT engines, you don't have direct access to the lights. All lights in the scene are integrated together and surfaces are then “lit” realistically. You have some back-door access to the various light scattering functions called BSDF's (Bidirectional Scattering Distribution Function http://en.wikipedia.org/wiki/Bidirectional_scattering_distribution_function) [en.wikipedia.org] but this is ceratinly not an artist friendly task. Many BSDF's are available already pre-defined for you from the Material palette in Houdini.
PBR requires all the geoemtry in the scene to be loaded at render time, same as with RT.

Becuase PBR uses a realistic light engine, the resultant imagery is quite photo-realistic with little effort at the cost of render time. You can use real area lights, geometry lights, light protals and more to light your scene in a realistic way. Area lights are actually more efficient than pont lights with PBR. This is the exact opposite in MP/RT rendering.

—-

Use MP/RT when you need fast, efficient renders for non-photoreal imagery and realistic images that take work and some understanding to set up and light using time-honored tricks and hacks to make nice imagery.

Use PBR for realistic rendered imagery with little set up at the cost of increaed render times.


Dive in and start rendering with the various engines and see for yourself.
There's at least one school like the old school!
User Avatar
Member
858 posts
Joined: Oct. 2008
Offline
jeff
This takes some care when dealing with geoemtry that is dynamically loaded at render time (delay load rendering) but with care, very efficient renders can be achieved.

Why, what happens? The geometry is then loaded all in one piece?
--
Jobless
User Avatar
Member
4 posts
Joined: June 2010
Offline
Thanks everyone .
User Avatar
Member
257 posts
Joined: Nov. 2007
Offline
Soothsayer
Why, what happens? The geometry is then loaded all in one piece?

yep. Because with raytracing mantra needs to have access to information about other objects in the scene, not just the object that is within the current renderbucket.
Delayed load micro polygon rendering on the other hand does not require geometry to be aware of other geometry in the scene.

Often if you want to give the impression of reflections with delayed loads you use environment maps in the shader. Which will not give you self-reflection, but will give you a lot of the shading you are looking for.

So raytracing defeats one of the purposes of using delayed loads -> the objects are kept in memory rather than being thrown out when no longer required by the current bucket.
Cg Supervisor | Effects Supervisor | Expert Technical Artist at Infinity Ward
https://www.linkedin.com/in/peter-claes-10a4854/ [www.linkedin.com]
  • Quick Links