CompuServe Thread

#Renderer & transparency

8 messages in this thread
#2763From: Hanspeter LudwigJan 2, 1995 8:42 AM
Hi Steve, Happy new year, I just wanted to let you know, that with Version 2.07 most of our problems are gone. The following in not ment to hurt anybodys feelings it is rather a wishlist and from what I've read and heard about version 3 some of the things will probably be included into the new version. The main thing is the renderer. I'm not at all complaining about the speed (well, it *could* be faster but there is *no* program around that is fast enough). The problem is transparency. – Whew, Andrea just handed me the paper with her notices, I hope I can translate that into english, so that it makes sense to you: The basic problem seems to be that transparency factors are *added*, where they should probably be *averaged out*. Here is an example: a white, 80 % transparent segment is placed partially in front of a black background and partially in front of an opaque white object, which appeares dark grey, due to its shadows. The intersections of the two segments should now look grey also, even thou a little lighter. Fact is the intersection looks almost plain white. A probably better example: a dark red (140/0/0) segment that is 70 % transparent is placed in front of another dark red seg. (same color). This second seg now is opaque. The color of the intersection should also now be dark red, but it is bright red. The two reds seem to be added rather then averaged out: 140 red + 140 red = 280 red. This is turned to the closest number possible to display I presume: 255 (bright red). Instead the color-calculation should probably be something like this: 30 % of 140 (the transparent seg) + 70 % of 140 (the opaque seg) = 100% of 140 red. I am not sure about that thought Well I know that these examples are rather theoretical. The basic problem to me seems the color-theory here. You seemed to have used the additive color-mixing theory instead of the substractive-mixing. A good example for the unusabillity of additve color mixing might be my most gross red 70's ashtray. If I for instance put that monstruos deep red glass ashtray onto a green underground the green does not turn lighter in brightness – as in addtive color-mixing – it turns darker, turns more dirty, towards olive – just as in substractive color mixing. This is easily illustrated by black & white photography. Lets say you want to shoot a picture of a red brick-house that is partualy covered by ivy. If you use a red filter the bricks become very bright, they will apeare allmost white on the b/w print, wheras the ivy will turn allmost black. If you use a green gel on the lens, the ivy now will be allmost white and the brick-wall will appeare a lot darker then it actually is. In conclusion I think the only problem is the wrong colormode. Additive color-mixing does not work, because there is hardly a case where this is used in real life (hey, of course, on monitors). Most of the times you see substractive color-mixing. I can imagin that this problem sounds a lot more trivial then it is to program. But I still wanted to bring it to your attention just because we had some problems with a production recently. Another thing was the reflection on transparent segments. If you have a transparent white seg in front of a black background there is no reflection rendered, even if it is cranked all the way up. Wishes: Would it be possible to predefine motion paths in Sculpture, so that they could be used as such in direction? That would be a big help if you have characters move along mountains or so. What do you think, is there a possibility to include motion paths in Action too? On many occasions that would help to make the movements more understandable, especially if you have different figures interact. Would it be possible to have measurements all through the modules? For instance that would be great if you build a movement of a person walking in action. If you then import that movement into direction you have to somehow coordinate to relative and the absolute motion so the figure does not look as if it is sliding over the floor. If you would have measurements or a grid in Action that uses the same units it would be a lot easier to get the figure moving according to the underground in Direction. Also numeric entering of values would be great. I know that this is possible even now, but unless you enter the value in the channels the values are never exact (I did a movement (version 2.07) once where I used "new transition" to start another movement with the same frame and values. Unfortunately I errouniously changed the values on some segs (frame 1) after that. I tried to just compare the values in the display and entered the values according the the original ones. After I rendered both motions there was still a big gab between the to movements. Comparing the values in the channels showed the problem. The values were not identical. ass soon as I changed the values to the exact ones everything was fine.) Do you think an EPS import filter would be possible to include into Sculpture? EPSes are bezier-splines as you know. Sculpture is a based on splines too. Wouldn't it be possible to build an import filter for EPSF? I agree that dxf files are cumbersome and in most cases it makes no sense using them in A:M. If I need to do a logoanimation I usually have to build the whole logo in Sculpture which is time consuming compared to just entering the text via keyboard. I know that A:M is not meant to be a Tool for Logoanimation but the control you have over the animation makes you want to use A:M for that kind of stuff too. (I personally do not like flying logos a whole lot, but sometimes you just have to do them to get a job) Dxf import does not allways work too good (depending on what program you use to generate the dxf file) and besides, you have to carry unnessesary masses of data all the way though the animation. EPSes would probably be a more intelligent and elegant way to import logos etc.. Of course this probably sound more trivial then it is too. I wish you a happy 95 and again, the above is not meant to hurt your feelings, it is supposed to help. Peter
#2764From: Pawel BodytkoJan 2, 1995 10:04 AM
>>>>a dark red (140/0/0) segment that is 70 % transparent is placed in front of another dark red seg. (same color). This second seg now is opaque. The color of the intersection should also now be dark red, but it is bright red. The two reds seem to be added rather then averaged out: 140 red + 140 red = 280 red. Peter, I have had a lot of similar problems with the renderer, some of them I was able to go around… My experience is that when you have a transparent object you have to pay *A LOT* of attention to AMBIANCE values of your transparent object… Value "0" is your best shot… If you want the objects behind a little brighter try "1" or "2"… Anything higher will give you the results you describe… I get excellent transparency from A:M… with the right settings of Mirror, Specularity and Regraction it can beat any renderer on the market… Good luck! Pawel
#3238From: Hanspeter LudwigJan 16, 1995 1:44 PM
Hi Pawel, (I've been reading your and Jim Jonah's messages to other users for some time now and boy,I wish I'd new A:M as good as you guys do) well, you are right about the render quality. You *can* get highly realistic textures if you need them – if you have the time to spend. We *did* experiment with ambiance a lot, still it didn't work correct. Our particular problem here was that we needed a stylized look for the animation of a syringe but at the same time it had to look *right*, not realistic but right. On the places where more than one layer of tranparent material laps over other pieces the effect appeared. B.T.W. the ambiance on all the models was set to zero. I mean, I love A:M and I love working with it, but some things just drive me nutso. (Just yesterday I accidentially erased a model only because Character on the Mac can save Figures with .seg endings. I hit the save shortcut after I imported the segment into Character, forgetting that this would erase all the segment-data) Another thing. Maybe you have an Idea. I am looking for a good "fog" material, theoretically it is possible to do that, but do to the problem described earlier all results look strange and not at all naturalistic. Any idea? I can send you the data of a fog material we have allready build. It looks beautyfull until you place an object behind it. talk to you, Peter
#3243From: Jim JonahJan 16, 1995 10:09 PM
Hanspeter, PMFJI, I missed the beginning of this thread, but from your last message it sounds like you had problems with overlapping transparent objects. Have you tried using the cookie cutter and the transparency maps to eliminate unwanted parts of the transparent object? On the fog issue, again have you tried using transparency maps and ambience maps? Try using the same map in both places with the amount set to 100%. By adjusting the gray values in the map, you can get some pretty cool effects. I picked this tip up from TAnimate over an AOL, and have been experimenting with "visible" lights. So far, the results have been very good! I hope this helps, Jim Jonah
#3254From: Hanspeter LudwigJan 17, 1995 3:30 PM
Hi Jim, Here is our basic problem again: "The basic problem seems to be that transparency factors are *added*, where they should probably be *averaged out*. Here is an example: a white, 80 % transparent segment is placed partially in front of a black background and partially in front of an opaque white object, which appeares dark grey, due to its shadows. The intersections of the two segments should now look grey also, even thou a little lighter. Fact is the intersection looks almost plain white. A probably better example: a dark red (140/0/0) segment that is 70 % transparent is placed in front of another dark red seg. (same color). This second seg now is opaque. The color of the intersection should also now be dark red, but it is bright red. The two reds seem to be added rather then averaged out: 140 red + 140 red = 280 red. This is turned to the closest number possible to display I presume: 255 (bright red). Instead the color-calculation should probably be something like this: 30 % of 140 (the transparent seg) + 70 % of 140 (the opaque seg) = 100% of 140 red. I am not sure about that thought Well I know that these examples are rather theoretical. The basic problem to me seems the color-theory here. You seemed to have used the additive color-mixing theory instead of the substractive-mixing. A good example for the unusabillity of additve color mixing might be my most gross red 70's ashtray. If I for instance put that monstruos deep red glass ashtray onto a green underground the green does not turn lighter in brightness – as in addtive color-mixing – it turns darker, turns more dirty, towards olive – just as in substractive color mixing. This is easily illustrated by black & white photography. Lets say you want to shoot a picture of a red brick-house that is partualy covered by ivy. If you use a red filter the bricks become very bright, they will apeare allmost white on the b/w print, wheras the ivy will turn allmost black. If you use a green gel on the lens, the ivy now will be allmost white and the brick-wall will appeare a lot darker then it actually is. In conclusion I think the only problem is the wrong colormode. Additive color-mixing does not work, because there is hardly a case where this is used in real life (hey, of course, on monitors). Most of the times you see substractive color-mixing. I can imagin that this problem sounds a lot more trivial then it is to program. But I still wanted to bring it to your attention just because we had some problems with a production recently. Another thing was the reflection on transparent segments. If you have a transparent white seg in front of a black background there is no reflection rendered, even if it is cranked all the way up." That was the first message. As you see, it is *not* a problem of removing parts of verlaping segs, its merely a problem of showing them but not in solid white. The actual problem occured on a scientiffic animation we did on eye-surgery (I know, some jobs you have to do). First a special type of syringe. That things had two tubes. Each of the tubes contains one component of a special fibrine glue. The animation had to look real, but schematic at the same time. Too much realism would have given it a too scary look. The way we have it now is far too schematic though, it doesn't look right. The clear cornea was an even bigger problem, since there was supposed to be an incision shown. That meant a *lot* of muscle motion and overlapping transparent pieces all over the place. We ended up doing most of the stuff in post. Thanks on the hint for the fog I'll give it a try, especially a rotoscoped black and white QT-Movie would probably work great for that. Any experience with that? Read ya, Peter.
#3268From: Pawel BodytkoJan 17, 1995 10:08 PM
>>>I mean, I love A:M and I love working with it, but some things just drive me nutso. Peter, this seems to be the standard relationship with A:M ;=) The transparency troubles you describe are just part of those "quirks" everybody sooner or later runs into… The reason I jumped into the tread was because I have been there (overlapping bright areas) before and with careful adjustments I got rid of them… I use A:M mostly for a high resolution product still shots, including many transparent cosmetic containers with color gels, foil stamps printing and other tricky objects, including whole bitmap background scenes shown through infracted transparent shapes. (I am a commercial artist, with about 80% of my business in packaging design). Because of this kind of work I have spent huge amounts of time playing with the transparency issues… I hear what you are saying about the additive and subtractive color model, and can't really judge if this is the cause of our trouble or not. My experience has been to pay extremely close attention to ambiance when dealing with the transparency… (my guess is that the bug, if there is such is in this area rather than the color model) If your transparent object has the Ambiance value 0, it is possible that the object behind is "too ambient", or "not ambient enough" and in order to compensate the scene has light sources that are too many or too strong … As for the "fog" material, the only thing I've played with was an attempt to create a "glow" around certain object by placing a simple 4 point patch with transparency mapping (specularity was 0, to avoid highlight) — I almost got it working except for the edge that has rendered as totally opaque — it goes back to this dreadful "background color" that shows up when you need it the least… Since the "glow" area is supposed to disappear into the scene, the grayscale bitmap used for mapping starts black out of the frame and gradually gets lighter… Well, the black becomes the "background color" (so handy in cookie mapping!) and instead of being 100% transparent, becomes 100% "nonexistent" so the segment can fully show itself <BG> If for some reason you do not have this problem in the Mac (it certainly is a bug — just appeared to me that it might even be file format specific, let say TGA or PCX — I will have to test it), you might want to try the transparency mapping to create fogs, clouds, glows and so on… Since transparency mapping is not the same as transparency in A:M (it is described as simple color averaging) it shouldn't give you any trouble with the ambiance… — Hey, why don't you try to wrap a tiny (10×10 pixels) gray bitmap on your syringe as transparency mapping and try to render it that way… It looks like crazy idea but it might work. (Unless the "background color creaps in <g>).
#3287From: Jim JonahJan 18, 1995 11:28 PM
Pawel, I just tried a trick I learned over on AOL using the same map for transparency and ambiance to create a visible light source. The map was a gradation from a light gray to black, saved as a Pict file, and everything worked perfectly for me. Your "black/background" color problem may well have been a file format problem. When I used the same file saved as a Targa, there was a strange white ring that showed up about 1/2" past the edge of the gradation. That disappear when I resaved the file as a Pict format. Hope this helps, Jim Jonah
#2768From: Steve/HASH, Inc.Jan 2, 1995 1:36 PM
Thanks for your input Peter! We always appreciate hearing from our users as this is where we get the info we need to improve our product…. hopefully we will be able to make some of your wishes come true with version 3! Steve, Hash Inc.