PDA

View Full Version : Texture maps and flickering??



kenmac
12-12-2003, 11:36 AM
I just finished a large architectural animation and for some reason
on this job more than any job in the past I had a nightmare time with
flickering textures.

I am well aware of the fix I have posted at the bottom of this page.

My question is………..

Is there a minimum size texture that is best to use?
Out of all the file formats example .tga or .jpg etc…..is there one
that is better than the other to use?


Almost every 3D Artist will have come across the dreaded texture
flickering noise that occurs in animation, specially when using high
frequency fractals or image maps, specially bumps. The issue occurs
because sometimes the detail on the texture is so small (smaller than
a pixel) that the renderer has very different values to take from the
texture in order to draw a single pixel... or something like that

Why not just decrease the bump value or make it less noisy?
Well... consider the following situation...You have a camera moving
from high up to close-up on a road, you want to see the asphalt
detail when you're close-up, but the further away you are from it the
more obvious the flickering appears since the detail becomes much
smaller than a pixel... so you're left with a catch 22 situation...
reduce the bump and the flickering goes away when you are high up but
it doesn't look realistic when close to the camera.

Well the solution is quite simple really, so simple I banged my head
on the wall when It occured to me... considering the amount of hassle
this caused me in the past it's not that drastic a reaction

All you have to do is use an Alpha gradient with it's input parameter
set to "Distance to Camera" .... 2 minutes in Viper and you should be
able to tweak the gradient to make the bump fade out in the distance
and still retain detail when close-up. With flickering color
maps/fractals you may want to set the gradient color to a blend of
all the colors in your maps and set it to normal blending mode rather
than alpha.

fartofart
12-12-2003, 01:00 PM
hi
1st well the gradient fade fix you are mentioned works good in most cases...
Hotcolors:
but keep in minde tv use a smaller range of colors so to avoide flickering use less saturated colors (wich often looks also more realisticaly)
so not pick 255 from the color range pick 245 as max insted

2nd
you use jpgs as textures as far i know they use same size in ram as tga so use tga hd space is cheap:) or did we need pre blured pics?
use indexed color maps (256 colors-hotcolors) textures in moste case.

3rd there cant be a fix size for texture res ..it depen on TV lines
a pixel has to be bigger than one line other wise it flicker
one field see the pixel line other not(fieldrendering!)
all depend on zoom and cam angel so make lines bigger or blur them

4th
medium AA fix alot flickering compared to low

there is no rule ofer the thumb to fix it ..only when you have a fixed cam :)

this is what i know .. i was an architecture dude in a 3d company ..
we had the same problems there
c.d.

kenmac
12-12-2003, 03:27 PM
I wish so badly that someone would do an in depth tutorial of this....


Almost every 3D Artist will have come across the dreaded texture
flickering noise that occurs in animation, specially when using high
frequency fractals or image maps, specially bumps. The issue occurs
because sometimes the detail on the texture is so small (smaller than
a pixel) that the renderer has very different values to take from the
texture in order to draw a single pixel... or something like that

Why not just decrease the bump value or make it less noisy?
Well... consider the following situation...You have a camera moving
from high up to close-up on a road, you want to see the asphalt
detail when you're close-up, but the further away you are from it the
more obvious the flickering appears since the detail becomes much
smaller than a pixel... so you're left with a catch 22 situation...
reduce the bump and the flickering goes away when you are high up but
it doesn't look realistic when close to the camera.

Well the solution is quite simple really, so simple I banged my head
on the wall when It occured to me... considering the amount of hassle
this caused me in the past it's not that drastic a reaction

All you have to do is use an Alpha gradient with it's input parameter
set to "Distance to Camera" .... 2 minutes in Viper and you should be
able to tweak the gradient to make the bump fade out in the distance
and still retain detail when close-up. With flickering color
maps/fractals you may want to set the gradient color to a blend of
all the colors in your maps and set it to normal blending mode rather
than alpha.

Hervé
12-13-2003, 03:23 AM
I've finished an archi stuff myself, and flickering was a hell , so I baked all textures and voilà, no flickering what so ever....

other than this , the only solution I know is the one you mentionned... this is a known problem of LW renderer....

Please open the doors to VRay.....

kenmac
12-13-2003, 08:51 AM
Hervé,
Do you know if other 3d apps have this problem?
Personally, I can't believe this problem even exists.
The method above works great for low polygon work.
It takes for ever when you are rendering of a 300 unit building.
Maybe I should try baking everything now.

Axis3d
12-13-2003, 11:21 AM
One thing I use alot is the Alpha channel gradient with the Input parameter set to Incidence angles. I find that the bump mapping which is at the glancing angles to the camera are the ones that cause the flickering. I have done a lot of tests and have found that Incidence angle works better, this way, you are not fading out all of your bumps.

Mainly, the contrast in your scene is what will cause thin, tiny details to buzz. If you can control your contrast, you can cut down on a lot of problems.

Another trick I have used is to render at 640 x 480, then, in After FX, import the footage into a 640x480 composition. Then, when you render, change the render output module to stretch to 720x486 D1. The slight softening makes very thin lines much less annoying on playback. Try an experiment on a frame.

Hey, Ken
I think I worked on a job (indirectly) with you recently. It was the Millionaire machine. If I'm not mistaken, you designed the model that was built as a miniature for the job? I did the compositing and effects work on that commercial.

kenmac
12-13-2003, 12:50 PM
Originally posted by Axis3d
Hey, Ken
I think I worked on a job (indirectly) with you recently. It was the Millionaire machine. If I'm not mistaken, you designed the model that was built as a miniature for the job? I did the compositing and effects work on that commercial.

Hey Axis3d,
Yup that was me....Spot turned out great. Nice Job on the composite. Do you live in the Philly area?

Ok, back to flickering....I even get flicker on objects that don't even have bumps. All the polys are good. I just don't get it.
I will try Incidence angles. Maybe I can post the scene on the web and you can download it and tell me what you think.
I am currently trying the baking method like Herve said but the dam program keeps crashing....Yikes!!!!

kenmac
12-13-2003, 12:55 PM
Originally posted by Hervé
I've finished an archi stuff myself, and flickering was a hell , so I baked all textures and voilà, no flickering what so ever....

other than this , the only solution I know is the one you mentionned... this is a known problem of LW renderer....

Please open the doors to VRay.....

Herve,
Which type of baking did you do? Image or to Object?

JDaniel
12-13-2003, 01:11 PM
I think it's time for a sub-pixel renderer. :D

Axis3d
12-13-2003, 07:20 PM
Hey, Ken

Thanks for the compliment about the commercial. I work in Philly at a place called Shooters Post & Transfer, but live in NJ. I am the animator/ VFX guy there. I told the producer of the millionaire job that I would have rather taken the 3d model that you built in Lightwave (which looked very nice and detailed) and animated that instead of cleaning up all the shots of the model that they filmed. We could have done some more dramatic stuff with it. She said the director is more 'old school' and likes to film something in front of the camera. Although I agree with that (I film as much practical stuff as I can), everyone who sees the spot thinks I did that in 3d anyway! Go figure!

I recently had to dump some architectural animation to tape that a firm in town made and it had horrible aliasing problems. All those thin, horizontal lines buzzing. Part of the problem was in the textures. If texture antialiasing was turned on, that would have helped. They could not render with a higher level of anti-aliasing so we ended up giving the whole animation a 1 pixel blur in the Flame before outputting. That actually helped about 95 percent of the flickering.

Hervé
12-14-2003, 01:43 AM
hello ken, yes LW is the only render I suppose to have that problem, and apparetly it will satay like this until we have a sub-pixel renderer... so not tomorrow.... I baked to image using the method described on NT's site called Baking illumination.... but after you have to use HDRshop (no other way).... so I do hope you're on PC...

BTW, just baking illumination is nice coz you dont have to render gigantic maps... although I strongly advice an app like NeatImage to clean the noise (you really dont want noise on the illumination map), dont use LW's noise reduction, really bad, and if it's forgetting dots, you're cooked...

Anyway the real long part is to make the very special UV's that Baker requires.... listen to this carrefully....

- all the polys attached together (aka sharing the same points will result in a smoothing texture from Surface Baker, even if smoothing option is ON or OFF in texture panel, and this is a ultra-tedious-nightmare... on a 1,8 Mil Polys model (entire House + Garden with all plants + inside all rooms)

Someone suggests I give a try to MicroWave (pro-baking and much more ) from 3D evasion... and if NT does not open to Vray or Brazil or similar, I'll get that plugin...

Cheers

kenmac
12-14-2003, 09:46 AM
Originally posted by Hervé
hello ken, yes LW is the only render I suppose to have that problem, and apparetly it will satay like this until we have a sub-pixel renderer... so not tomorrow.... I baked to image using the method described on NT's site called Baking illumination.... but after you have to use HDRshop (no other way).... so I do hope you're on PC...

BTW, just baking illumination is nice coz you dont have to render gigantic maps... although I strongly advice an app like NeatImage to clean the noise (you really dont want noise on the illumination map), dont use LW's noise reduction, really bad, and if it's forgetting dots, you're cooked...

Anyway the real long part is to make the very special UV's that Baker requires.... listen to this carrefully....

- all the polys attached together (aka sharing the same points will result in a smoothing texture from Surface Baker, even if smoothing option is ON or OFF in texture panel, and this is a ultra-tedious-nightmare... on a 1,8 Mil Polys model (entire House + Garden with all plants + inside all rooms)

Someone suggests I give a try to MicroWave (pro-baking and much more ) from 3D evasion... and if NT does not open to Vray or Brazil or similar, I'll get that plugin...

Cheers


Herve,

With the above method I gather this means you have to render with radiosity on? If so, this is a complete drag due to the increase in render time.

Also, if I may get this straight. Maya and Max don't have this flickering problem?

KenMac

Hervé
12-14-2003, 11:49 AM
Well not exactly, you can bake normal lights, areas ,spots, whatever... Illumination in this case does not mean Global Illumination, it means Luminaire... he he...

Well other renders have what they call scanline rendering...

I cannot recall exactly where, but there is a sitethat explains a bit....

Take for example some ultrathin diagonal lines, well in this case LW s....k a bit.....

I know for sure mental ray does not have this problem, this is why the only chance for us LW'ers is to have a open dooe to other rendering apps., but apparently NT refuses to do so.... why... who knows...?

Cheers KenMac

Axis3d
12-14-2003, 12:46 PM
Ken

You could bake using Overcaster instead of Lightwave's radiosity. That'll save a ton of time.

Hervé
12-14-2003, 11:24 PM
We are just sooooooooooo tired of those stupid "workaround".... in other words I am tired and have lost lot of energy working like that.... and baking is not a magic solution either.... and even though overcaster "was/is" good (again just a workaround), this is today's not the solution, really not, when you have competitors running Brazil, VRay, mentalray and the likes....

..... and judging here....

" SplutterFish Announces Immediate Availability of the Brazil Rendering System for Discreet's 3ds max 6 Professional 3D Animation Software"

NT, your renderer was a marvelous stuff when it came out, but now it looks really outdated.... + so many developers have problems with what they call the SDK, always blaming NT (who else), saying we want to fix bugs, we would develop more our plugins... etc...

an example.... well HyperSmooth and LW clip maps.... very bad... that is one but I recall sooo many times "me calling the dev of th plugin, and the guy saying, sorry, NT's fault....

So now I have to ask officially to NT....:

NT, since you have no plans for the renderer of LW, and even if you have plans, ,I doubt we'll see them in v8, so what does that mean.... another year like that.... Please open LW to other render apps... I am sure you'll fell better after....

What are you scared of, people stolling parts of codes or what...? I just dont get it, please explain a bit why...?


So Axis, very nice , we are very nice advisors, sadly our advices are .... well.... you get the point....
(in case, ..... baking just illumunation is in principle short (coz you bake small maps), but making a large model ready for this operation is the tedious part, and when I say tedious, trust me on that....!!)

Merry Xmas NT
Hervé

trick
12-15-2003, 01:47 AM
To make one thing clear:

Architectural animations (put to Tape for showing on TV-sets) with a lot of thin lines are NOT flickdring because of bad anti-aliasing. You can even render with extreme enhanced AA: the flickering will stay. MAX may not show this because it's default renderer is a lot fuzier then LW's. Try one of the sharper algorhythms and you'll see the same flickering. The main reason you see this flickering esp.with LW is because it's AA gives the most crisp images (one of the reasons I started using LW in the first place). This can be good for detail in stills but bad for animations with a lot of detail. I'll bet that C4D has very little problems with flickering just because it's renderer (and the lighting) gives a much softer look. Therefore I would suggest to make an alternative AA-routine, but certainly not drop (just speed up) the current one. Because of the crispness a thin line can show up in an even field, and disappear in an odd field. As mentioned above you can either use a 0.6-1.2 pixel vertical directional blur in POST or use the soften filter next to at least medium enh.AA.

Hervé
12-15-2003, 03:11 AM
so let's make that AA routine please NT....

kenmac
12-15-2003, 06:52 AM
Herve,
I can not agreee with you more.
Personally, I am frustrated with this program.
Since I have started using this program I have noticed that everything is a "work around". I can't tell you how much it upsets me to hear other 3d apps don't have this problem flicker problem.

NT reminds me very much of Apple Computer. Always playing catch up, doing everything not to be main stream...Then one day you wake up and find yourself only having 2.5% market share.

I spent hours on this last product re-rendering looking for flicker.
Once I get one object to stop flickering another one acts up.
I am exhausted...Remind you....These are always those thin architectural details that you just have to have in a scene.

I do want to say thank you to everyone who has made suggestions. I have noted this thread and will use it as reference.
I would also like to thank Larry Shultz for also helping out.
Maybe other 3d apps might not have flicker but I'd be surprised if they had this great of a community.

Keep the suggestion rolling in...

kenmac
12-15-2003, 11:56 AM
Hey good news...I just spoke to Donny at NT tech support and told him about the flicker problem. I suggested that NT post some tutorials or tricks on how to fix this. He said sure, no problem and that they would....Way to go...I am sure there are many of us who could use this information.

Hervé
12-15-2003, 11:15 PM
Oky Doky, well again those are all going to be workarounds, but at least they'll try something...

If it was not so complex (it looks soooo complex), I'd move to XSI, it's not amoney question for me.... but I gave up moving to another app.... I dont want to relearn what took me so long on LW....

Cheers KenMac
Let's hope for the best.....

Hervé
12-16-2003, 12:40 AM
Hey I post that here (nothing harmful Proton...) this is a MentalRay render.... scanline, very sharp, full bouncing a dn bells and whistles..... hummm 8 minutes.... !!!
My baked scene in LW takes 4 minutes to render... sniff sniff....

What aws the reason again for not opening to other renders...? sorry.... what do you say...? what ...? No?!!, Dont tell me, No ?!! Cant believe it....

Cheers

Halsu
12-17-2003, 05:42 AM
Just a quick note that LW already IS a subpixel renderer. That's called anti-aliasing.

At low AA, there's 5 samples / pixel
At medium AA, there's 9 samples / pixel
At high AA, there's 18 samples / pixel
At extreme AA, there's 33 samples / pixel

If you REALLY need more samples, render at bigger resolution, and scale down in post.

To further show that LW's antialiasing is NOT doing too shabby a work, try rendering an image at 4X resolution, then scaling it down in photoshop with cubic interpolation. The result is very similar, also in small details, as LW's own antialiasing is.

As far as the image based texturing is concerned, there's pixel blending and texture antialising for reducing small detail flickering.

For procedurals (and minute geometry), a similar filter would be a cool addition, but doesn't yet exist. One possibility could be using i.e. Digital Confusion to blur the scene ever so slightly based on distance.

This combined with rendering at higher than normal resolution can fix some problems - albeit with a render time hit.

Small detail fickering in TV monitor is not at all LightWave specific problem.

It's normal, part of limitations the current television standards have, and it's something anyone working with video should know about, and know how to fix.

It happens even with television cameras. Thin lines flicker, period.

Solution is to avoid or at least blur thin horizontal lines.

Lightwolf
12-17-2003, 06:15 AM
Let me add my two cents here:
We are talking about two entirely different things here, texture and object antialiasing.

Object antialiasing is the option you set in the camera panel (and yes, it helps textures too), texture antialiasing is what you do in the texture window (the filter checkbox).
Both are quite week in LW, however, while you can fight bad antialiasing on an object level by bumping up the amount of samples, this is quite hard to do with texture, especially at flat angles.
What LW really needs is a decent texture filter that accounts for anisotropic angles, currently is uses point sampling in combination with mipmaps, whic his quite fast but, well, it looks it as well. EWA (elliptical weighed average) should be the way to go, and is long overdue imho.

Cheers,
Mike - scnr :p

ColinSmith
12-17-2003, 07:59 AM
I had the flicking problem on some handrails, and yeah, ended up with the 1 pixel vertical blur in post.

But the interesting thing was when the aerial footage shot on Beta SP came in - exact same type of flicker on real life shots ;-)
More of a interlaced footage problem in general than just LW.

Generally now I`d go with the methods already discussed above, and render without interlacing.

kenmac
12-17-2003, 09:57 AM
ColinSmith,
It is funny, I never use interlacing. What I find most frustrating more than textures flickering is things such as window mullions or the wire that would hang from a ceiling to a light.
It is almost as if the light is bouncing off these objects.
Believe me, I have tried it all. Yes, I use blur..etc...

I have these fantasies of being able to put a camera anywhere, hitting F10 and not having any problems. The architectural stuff really is a pain in the &%$#* to animate.

Let's see if NT really is going to post some suggestions or come up with a more up to date render engine.
How long do you think it would take to learn Max or Maya?

Halsu
12-17-2003, 10:15 AM
Originally posted by Lightwolf
Let me add my two cents here:
We are talking about two entirely different things here, texture and object antialiasing.

....

What LW really needs is a decent texture filter that accounts for anisotropic angles,


Well, more than two things - Video intelace flickering is totally different issue from the two mentioned above. As an additional info, it's not really related to rendering to frames/fields, but rather to the one-pixel size details in the final image.

....

I wonder how hard would it be to write a pixel filter that would take incidence angle, distance to camera and zoom into account, and blur the image based on these parameters - just enough to prevent crawling... I guess this should happen between each render pass, so that the result would be averaged...

kenmac
12-17-2003, 01:57 PM
Originally posted by Halsu
Well, more than two things - Video intelace flickering is totally different issue from the two mentioned above. As an additional info, it's not really related to rendering to frames/fields, but rather to the one-pixel size details in the final image.

....

I wonder how hard would it be to write a pixel filter that would take incidence angle, distance to camera and zoom into account, and blur the image based on these parameters - just enough to prevent crawling... I guess this should happen between each render pass, so that the result would be averaged...


EKI...Write it....

Lightwolf
12-18-2003, 02:25 AM
Originally posted by Halsu
I wonder how hard would it be to write a pixel filter that would take incidence angle, distance to camera and zoom into account, and blur the image based on these parameters - just enough to prevent crawling... I guess this should happen between each render pass, so that the result would be averaged...
Well, it would be easier to re-write the texturing engine using the procedural class... but, these don't get all the information about the underlying geometry needed for decent filtering (I've done a bit of research on that matter, a shader has all the information, but wouldn't be as useful).
A Pixel filter would be nice, but since it only works on one pixel at a time, it can't (...easily...) blur with adjacent pixels. Mucho trickery is needed for that (-> digital confusion, xdof being examples). I guess using a slight DOF with one of these tools would lead to a similar result...
Cheers,
Mike

fartofart
12-19-2003, 11:02 AM
hey,
well i think why should other applications not have the problem

as i said it is a filedrendering and line resolution thingy.

well i only have one quik idea for a fix form the application side
but it will need alot calculation.

LW you compare the fields
if field one has a big contrast to field 2 at horizontal position (50-110 for example) it could blur it.shoudl mean field one with white becomes gray or 75 % of the color of field 2 (black).

so they will have not a white and a black line it ..they would get a gray line.. itz kind of blurring

So the contrast can increas field by field over 2 lines which would fix the flickering


###

sup-pixel rendering
well lw is not a subpixelrenderengine
aa is not subpixel rendering!

why? well, a pixel is a split into RGB
subpixel rednering borrow from adjacent whole pixels.
Our eyes cooperate by seeing only black and white, since the 'borrowed' sub-pixels are always adjacent to their complementary color pixels, which our eyes mix to form white!

Out of sheer desperation, a technique known as 'anti-aliasing' was developed. It attempts to employ shades of gray where font designers would like to show only 'part' of a pixel. The hope is that our eyes will tend to average two adjacent gray pixels to see one in the middle.

subpixel rednering used by the the new clear typ font from windows to render fonts . it only works well on LCD!

"While the application of Sub-Pixel Graphic Rendering will absolutely benefit virtually all users of LCD displays, it's important to understand that this technique is not applicable to high-resolution Cathode Ray Tube (CRT) displays. Yes, I know, the sample above looked really great on your CRT, but that's mostly because any mature sub-pixel rendering technology also incorporates aspects of anti-aliasing (as we'll see on the next page of this little web zone.) And it's well known that anti-aliasing helps tremendously with the display of text. So even though sub-pixel rendering is better than nothing on CRT's, its "colorized" aspects only really work on LCD displays."

##BUT NOW THE BIGGEST ISSUE!!! WHY SUBPIXEL RENDERING is not the clue!

As we've seen, sub-pixel rendering only enhances the horizontal resolution of LCD panels and abit CRT. However, this means that existing color LCD panel technology can not be used with sub-pixel rendering when the panel is used in a vertical, or portrait, orientation.



yeah we need a pixelfilter !

Hervé
12-20-2003, 02:17 AM
Here you can read this... hopefully it will make everybody on the same wave....

"Scanline vs. Ray Tracing, by Piero Foscari ([email protected]), Paul Kahler ([email protected]), and Matt Pharr ([email protected])
Piero Foscari writes, on the Real-Time Raytracing email list http://www.onelist.com/community/realtime_raytracing:

But one side question... why do people keep including scanline rendering in commercial packages when even with actual medium sized scenes and unoptimized engines raytracing is faster?

Paul Kahler responds:

Because change takes time. First you have to convince people, THEN they can change the software :-) Generally you must SHOW people in order to convince them, which often involves showing them with their own system. That means one of their own developers has to become convinced (on their own of course) and have time to do a prototype to show management. There is also the "if it ain't broke, don't fix it" problem.

Matt Pharr replies:

Frankly, I don't think that's it at all. Rather, the simple reason that commercial packages still include scanline support is that ray-tracing the eye rays isn't in fact faster than a good scanline algorithm. Obviously this depends on how good the ray-tracer is versus how good the scanline algorithm is, but I think that the gap is pretty significant, if you're comparing with a scanline algorithm that does good occlusion culling, etc.

Particularly when you need to sample a pixel area very well, e.g. in order to get smooth motion blur or good anti-aliasing of fine geometry (think hair), ray-tracing just doesn't make sense, efficiency-wise--tracing hundreds of rays per pixel just takes too much time. "


If you need more accurate infos... go there ;

http://www.acm.org/tog/resources/RTNews/html/rtnv15n1.html

Scanline with good occlusion... this is the way to go... he he

Digest....... gest !

Hervé
12-20-2003, 02:22 AM
Now on the other hand.... he he

"Scanline vs. Ray Tracing, by Loren Carpenter ([email protected]) and Sam Richards ([email protected])
Loren Carpenter ([email protected]) wrote:
>That said, look around you. Pick some direction and point your imaginary
>camera over there. Now, how many pixels in that frame NEED a raytracer.
>Who cares if the doorknob reflects your face? Is it part of the story? Or,
>does the door just need a knob so it will look like a door? Why raytrace
>99% of an image that doesn't need it?

Sam Richards ([email protected]) replies:

I would just like to stick up my hand in favor of the poor old Ray Tracer. At Blue Sky we have a pretty good ray tracer. When I first got to Blue Sky I was dubious as to how much I actually would need it. I have been pleasantly surprised how much we use it. It is partly to do with the fact that we went through a phase of doing shaver commercials (which require diffuse reflections as well as normal reflections). But where it is really useful is having the ability of saying "what would this scene look like if it were in the real world" (We can do radiosity, too!).

Sometimes having gotten a single frame that looks very real we then figure out how to cheat it using similar techniques to what a renderman user might do. Often the render times are low enough that we don't need to do that and simply render it as final. While I agree that for a large part of the environment you don't need a ray tracer there are quite a lot of object types that do have diffuse reflections.

I followed your advice and picked some direction in the room I am sitting at. In practically every direction I looked at I could see nice soft shadows. The problem with shadow maps is that you have to define the radius of the shadow, however in the room I am in I can see the shadows getting blurier according to the distance all over the room. The overhead light has a diffuse reflection in the glossy ceiling. Diffuse reflections are everywhere (the floor, and numerous metal surfaces around the room). And that's not even talking about the ambient light in the room.

All the things I saw in my room can be achieved, with varying degrees of success with renderman and probably many other commercial and public domain scan line renderers. However it does require operator intervention. The nice thing about ray-tracers is that you don't have to think about it! You just give the lights a radius and the shadows that they cast are soft and correct. We definitely pay a rendering cost for this. But as machines get quicker, the more the computer should do automatically.

However, currently there is a downside, which is that it is definitely slow, there have been some jobs that I would dearly loved to have RenderMan, however there are other jobs where if all I had was renderman I would have had many nightmares over trying to figure out how to render the scene.

In my ideal world, I would have both a scan-line and ray-tracing renderman, so that I at least could switch on the ray-tracing when I really needed it for particular objects. This would at least give me the speed of the scan-line renderers and the power of the ray-tracers when I need it. "


we need both.... ha ha ha ha ha (joker's style)

Hervé
12-20-2003, 02:26 AM
AND to be really complete on the subject :

Kicking Some Tires

We've mentioned that for the most part all rendering engines perform the same basic set of tasks. They all go through the same pipeline and they all generate a finished scene. But what sets one rendering engine apart from another? We talked to a number of companies to try and find out what they do that no one else does. Most companies are a little reluctant to divulge their secrets, but we did discover a few interesting tidbits.

While all of the companies insist that their rendering engine is unique, they will also admit (with a little prodding) that any differences in image quality are usually the result of users not bothering to change the default settings.

As Brad Peebler from NewTek says, "People think that different rendering packages have a signature look–Alias and LightWave more of a clay look and MAX has more of a plastic look. This is due to the engine's default settings. As developers of software we have to set up some default settings, and if you don't change them, the results can look similar." So if you like the clay or plastic signature look of a particular package don't change anything. However, if you want your results to look unique, then you should spend some time adjusting things. The unspoken corollary here is that by adjusting the defaults you should be able to get just about any result you want from just about any package. That is, you can get Alias or LightWave to look plastic or MAX to look clay-like.

Another thing seems to be common among all rendering engines, according to the companies that sell them–they are all apparently the fastest. While the claims are a little curious, they are also very difficult to prove or disprove. We should be able to generalize and say that scanline renderers such as Pixar RenderMan (www.pixar.com) and Electric Image Camera are probably faster than their raytracing cousins.

Among the raytracers there are only a few ways to really speed things up. The primary technique (that is becoming common to most packages) is to add multithreading, multiprocessor, or distributed rendering support. Softimage, LightWave, Alias|Wavefront Maya (www.aliaswavefront.com), RenderMan, and MAX all have multithreading and multiprocessor support built in. Most of them also support distributed rendering. The only difference is how much you pay. LightWave's distributed rendering support is free. The others require separate licenses for each additional machine.

Another way to speed up raytracers is to use selective raytracing–specifying which objects will be raytraced and which ones will be scanline shaded. Only MAX and LightWave offer selective raytracing today but expect this feature to appear in more and more packages as time goes on.

If you are really hard-core about rendering, then just about all of these products have some sort of API or SDK that you can license. However, you should be prepared for some mighty serious coding.

Back To Top

Alias|Wavefront Maya

Maya is considered by many professionals to have the best soft-body animation tool around. This allows Maya to generate very realistic looking cloth and water effects. Maya also has a unique feature its developers call IPR (Interactive Photorealistic Render) that they say allows for near instantaneous editing of lighting, textures, shaders, lens, and glow effects.

Another trick Maya uses is tiling the scene into smaller and smaller blocks before rendering. If the computing cost to render a block falls within user-defined limits, it gets passed to the final render stage. If, on the other hand, a block is still too complex, it gets further subdivided. Maya also uses a technique called lazy tessellation. By that they mean that objects are first checked for visibility and depth before tessellation is done. This allows the engine to skip over objects that won't have to be rendered.

NewTek LightWave

LightWave is considered to have one of the best all-around rendering engines and modeling packages in the business. NewTek representatives claim (like just about everyone else) that its engine is the fastest and most accurate. For example, LightWave's engine uses 96-bit internal color depth through the entire pipeline. This reduces color banding and the need to antialias scenes so much.

The next release of LightWave will also be the first to feature a radiosity renderer that can be set up in such a way that scenes can be animated (a first). LightWave also supports distributed rendering and selective raytracing.

Back To Top

Pixar RenderMan

RenderMan is the rendering engine choice of the film and video industry. Its main claim to fame is speed and the ability to render very, very complex scenes (read thousands and thousands of polys). Its developers are also particularly proud of its antialiasing and motion blur. Since RenderMan was built specifically for the film industry, they also tout the accuracy of its camera settings.

RenderMan is a scanline renderer, so it requires the creation of specific shaders to generate specific lighting effects. Since its developers have built an entire shading language, it's not surprising that they are considered the kings of shaders. On the down side, programming those shaders can be tricky; many companies hire programmers to create special shaders. Moreover, Pixar also has a library of prebuilt shaders you can use. Third-party shaders are available as well.

RenderMan is a rendering engine only–no modeling package is included. This means you build and animate your scenes in another package and import and render them in RenderMan. This requires some foreknowledge of how RenderMan uses shaders. Integrating different packages isn't always seamless.

Back To Top

Electric Image Camera

The developers of Electric Image, also geared toward the film industry, are proud of its compositing features. As with RenderMan, they are proud of the speed of the renderer and its antialiasing and motion blur.

Also, as with RenderMan, Camera requires that shaders be programmed to get certain effects, but its shader language isn't quite as sophisticated, requiring knowledge of C or C++.

Back To Top

Discreet 3D Studio MAX

MAX is the all-around workhorse in the rendering, modeling, and animation world. MAX is probably the most flexible rendering package because of its plug-in nature. According to Phil Miller, product manager for MAX, key stages of the pipeline have been turned into plug-in classes providing third-party developers a way to customize MAX far beyond other products. And, if you don't like the rendering engine that comes with MAX, it also supports more than a dozen others.

Back To Top

Softimage Mental Ray

Softimage uses a combination of scanline and raytracing. You can also program your own shaders (if you know C or C++). If the idea of programming your own shaders in C gives you shudders, prebuilt and third-party shaders are available for purchase.

Back To Top

Engines of the Future

So where are rendering engines headed in the future? According to Phil Miller, product manager for MAX, "Speed isn't necessarily the next step. We've known how to do a lot of things for a while now. It was just that they took so much computing effort balanced against the results. We can do 95 percent of the effects, such as reflections, pretty easily but each higher level of realism takes twice the computing power and only gets you one or two percent closer to reality. The closer to the real world you want to get the more calculations you need to perform. Now that the capabilities of the CPUs have improved we can do these things."

Brad Peebler at NewTek agrees. "Rendering is headed in two directions. First, toward real-time rendering but with more physically based effects–caustics and radiosity. Those will start coming in real soon. As processor speeds increase we no longer have to simulate how light works–we can calculate it. Eventually we'll be able to do away with things such as Phong or Gouraud shading altogether."

Peebler adds, "The second direction is away from photorealism. We're looking at rendering scenes that look better than reality. They'll be hyper-real or stylized. More and more custom shaders and rendering engines are providing cartooning and cell shading."

Back To Top

The Checkered Flag

So we've gotten through an entire article about rendering engines without a single equation or even mention of Fast Fourier Transforms. Obviously, we've skipped over tons of details and hard-core math. The bottom line is that you don't have to brush up on your calculus in order to get more from your rendering engine. However, you should set aside some time, every once in a while, to go back and reread your manuals and experiment with various settings. If you're working with real-time engines, you'll have to learn a lot more about the specific features and functions of the engine. If you're heading toward film or video, then you need to understand focal lengths, motion blur, and probably shaders. If you're building models, objects, or scenes that you want to look unique, then you'll have to do more than stick with the defaults. If you're just making pretty pictures for yourself, then you probably don't need to know anything about the rendering engine under the hood–but it couldn't hurt.

from here : http://www.3dgate.com/techniques/000424/0424rendering2.html#kicktires

"could you notice they still think Brad is NT'CEO.... he he