Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
raouldukey@my-deja.com (raouldukey@my-deja.com) writes: > I thought it would be easy to modify the Show3.pro > routine to place the image plot on the back wall > of the cube instead of the floor. However, after > struggling with it for a long time, I find that > I am totally confused by the multiple coordinate > transformations made. Has anyone got > some tips on how to do this? > > What I would like > is to create the cube with the shaded surface > command, work out the coordinates of the back > wall, and use polywarp to work out where to > project the image. Then, afterwards replace > the shaded surface on the floor of the cube. > > I know....I know.....I need to learn object > graphics. Any tips would be appreciated! Well, after telling someone the other day, "Oh, it would be simple with object graphics.", I decided to see how simple it would be. Yikes! There are just one or two gotchas here that make life a wee bit difficult at times, starting with the fact that the documentation is wrong--again. However, this is the same wrongness I uncovered in another long, frustrating day not too long ago, so I think I can now safely offer this rule of thumb: if the documentation says you can do something in object graphics with a 2D image, the documentation is almost certainly wrong. In any case, before you spend three hours making life miserable for the poor dog, try it with a 24-bit image. Life will be easier that way. OK, so we think we can approach this by rotating the object image (24-bit, please), but it ain't so. Images don't rotate in object graphics. (The documentation does point this out, somewhere.) So, no problemo. We're gonna make a polygon object and add the image to it with the Texture_Map keyword. I've used this for surfaces and it works like a champ. Very easy. Except...How come my image is black? :-( Ah, I need a 24-bit image. Did I mention this? Ok, 24-bit image, texture map, rockin' and rollin' now. Except...oough. Still black. Well, not *midnight* black, but black enough. Let's see. What about if I put the image here, instead of where I really want it. Humm. Not so black. What about there? Only black on one side, but not too bad on the other. Only problem now is that it's across the street from where I want it. :-( OK, must be a light problem. Add a light to the image. (Why didn't I think of this? Every picture in an art gallery has a light above the image to illuminate it. Stupid.) Whoops! Wrong kind of light. Add *ambient* light there, Jose. All right! The image is looking gooood. Try to put a shaded surface in front of it. Uh, oh. That surface was also looking good before I added that damn light to see the image. Now it looks like I've got the stadium lights shining on the surface. Sure enough. If you want a shaded surface, better turn the image lights off... And so it goes. I'm looking for my slide rule right now so I can calculate the optimum distance and viewing angles for the lights in the scene. While I futz around with it, you might want to look at a simple example of what I came up with. You can find it here: ftp://ftp.dfanning.com/pub/dfanning/outgoing/misc/example_su rface.pro In the end, I pretty much decided this is not going to be what you had in mind. But that's how it goes some times. Another day, another ... well, dollar's not right. Another story, I guess. Better than nothing, and a whole lot more entertaining for the paying customers. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
Richard G. French (rfrench@wellesley.edu) writes: >> IT WORKS! > > Ok, I'm not going to let you guys off that easily! I've got to see an > example of this so I can learn how to use the Z buffer, too! Can you > put together a simple example of this new image plot on the back wall? > Then the mere mortals among us can try to figure out the coordinate > transformations and maybe help you avoid having to fiddle it by hand. > I must say that David's (and Martin's) sample code for object graphics > has got me quaking in my boots. I'm relieved to know that there is a way > to do this using direct graphics! Sorry. raouldukey@my-deja.com has the code. I've got my tennis racquet and I'm just heading out the door. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
raouldukey@my-deja.com wrote: > > IT WORKS! > Ok, I'm not going to let you guys off that easily! I've got to see an example of this so I can learn how to use the Z buffer, too! Can you put together a simple example of this new image plot on the back wall? Then the mere mortals among us can try to figure out the coordinate transformations and maybe help you avoid having to fiddle it by hand. I must say that David's (and Martin's) sample code for object graphics has got me quaking in my boots. I'm relieved to know that there is a way to do this using direct graphics! Dick French
raouldukey@my-deja.com (raouldukey@my-deja.com) writes: > IT WORKS! Hooray! I'm taking the rest of the day off then, while I'm on a roll. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
IT WORKS! Thanks for the Z buffer tip. I had never used that before, but now I see all sorts of applications. Thanks again! > > The problem here isn't that Shade_Surf is erasing the > display, the problem is that it is NOT erasing the > display. Now are you confused? :-) > > The output of Shade_Surf is actually an image. I think > you could get this program to work if you puts the bits > and bobs together in the Z graphics buffer. Then things > that were suppose to be behind other things would actually > show up there. > > Think of the Z-graphics buffer as Object_Graphics Lite > and you will have no difficulties. :-) > > Cheers, > > David > > -- > David Fanning, Ph.D. > Fanning Software Consulting > Phone: 970-221-0438 E-Mail: davidf@dfanning.com > Coyote's Guide to IDL Programming: http://www.dfanning.com/ > Toll-Free IDL Book Orders: 1-888-461-0155 > Sent via Deja.com http://www.deja.com/ Before you buy.
raouldukey@my-deja.com (raouldukey@my-deja.com) writes: > Ok...so you would think my life is now perfect and that I would > be satisfied? Not So! It turns out that this method works fine > if I use the surface procedure to redraw the surface in front > of the image using the /noerase keyword. However, the shade_surf > procedure doesn't seem to accept the /noerase keyword (well...it > accepts it, but just chooses to ignore it ;) ) so it erases > the screen and redraws the surface. Therefore it erases the > image I worked so hard to place correctly! *sigh* Of course, > the shade_surf doesn't seem to be a normal procedure that I > can attempt to modify so that it behaves more like its brother > surface. > > At this point, I am again stumped. I know that the output > would look excellent if I could just get it to work. Unless > there is a way to get shade_surf to recognize /noerase, I > think I have no choice but to switch to object graphics via > your example. Thanks for the help, and for giving me a place > to whine about my IDL difficulties! The problem here isn't that Shade_Surf is erasing the display, the problem is that it is NOT erasing the display. Now are you confused? :-) The output of Shade_Surf is actually an image. I think you could get this program to work if you puts the bits and bobs together in the Z graphics buffer. Then things that were suppose to be behind other things would actually show up there. Think of the Z-graphics buffer as Object_Graphics Lite and you will have no difficulties. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
Martin Schultz (m218003@modell3.dkrz.de) shows that the Germans do too have a sense of humor when he writes: > OK. I guess, I see clearer now: it's not objects that I don't like, but > the applications that are built on objects! ... Nowadays it seems we have to *talk* > to these machines and *ask* them to *please* try to accomplish at least > a tiny fraction of what we had in mind. Even though your program didn't actually produce anything on the display (typical for object graphics programs, by the way) when I tried to run on my machine, it did manage to capture some of the flavor of object graphics programs. :-) But RSI never claimed this stuff wasn't low level. They just haven't come up with much in the way of higher level tools. And I'm not sure we want them to anyway. Heck, you will find *much* better IDL programs than RSI puts out just by looking around the web. How come Liam Gumley has to write a TV command that actually works on the machines we run IDL on!? And images are IDL's thing, for goodness sake. But to give RSI some credit, they do have new things in each new release that make object graphics easier to use. In IDL 5.3, I think (I couldn't get my old beta fired up for some reason, so I couldn't try this), they now have these handle-like things you can put around your lights. Sort of like the lights we use in the theater. That way you can *see* the lights in your scene and physically move them around and position them. That will make things a LOT easier to work with. The thing that absolutely makes object graphics so impossible on occasions is that you get absolutely no feedback on what has gone wrong. Since *everything* is possible, object graphics doesn't care if you rotate the surface under the rug where it can't be seen. Maybe that is where you intended to put it. Meanwhile you sit and stare at an empty screen for hours, whispering every incantation you know, hoping upon hope that *something* might show up to give you your bearings. I'm telling you, I only have so much patience for staring at a black rectangle on the display that is suppose to be an image. I finally, yesterday, had to ask RSI for an example that worked. At first they pointed me to their Show3_Object example in the example/objects directory, which I had already examined, since that is exactly what I was trying to do. But that example worked as well as mine did: a black rectangle instead of the image. Don't these people look at the output of these programs before they pass them off as examples of how to write programs!? But eventually I did get a working example. That is the only way I would have discovered, I think, that a 24-bit image was required. I tend, like many people, to be *way* to naive when it comes to believing what I read. So, OK, it was a frustrating day. But I learned a couple of new things, and knowledge that comes too easy isn't fully appreciated. What I know will help me sell books. What I can't figure out is why RSI believes that their customers, who have no such financial incentive to spend hours learning this on their own, will be willing (or able) to give up direct graphics for this. Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
Wow! Thanks for taking the time to help. I looked at your "simple" program, and it was impressive. I will try to work through it and try to learn something about object graphics, because at this point, they are simply magic to me. > > ftp://ftp.dfanning.com/pub/dfanning/outgoing/misc/example_su rface.pro > As for my efforts here, I continued to work with trying to modify the show3.pro routine, because the output is exactly what I am looking for, if I can only get control of it. The coordinate transformations don't seem to be well-documented, and the IDL manuals aren't that helpful (IMHO). I was finally able to work out how to project the image to the front face of the cube. I wasn't able to automatically work out the coordinates of the back face, so I had to manually tweak it into position. This isn't too bad, because the coordinates will always be the same for a given x and z axis rotation. Ok...so you would think my life is now perfect and that I would be satisfied? Not So! It turns out that this method works fine if I use the surface procedure to redraw the surface in front of the image using the /noerase keyword. However, the shade_surf procedure doesn't seem to accept the /noerase keyword (well...it accepts it, but just chooses to ignore it ;) ) so it erases the screen and redraws the surface. Therefore it erases the image I worked so hard to place correctly! *sigh* Of course, the shade_surf doesn't seem to be a normal procedure that I can attempt to modify so that it behaves more like its brother surface. At this point, I am again stumped. I know that the output would look excellent if I could just get it to work. Unless there is a way to get shade_surf to recognize /noerase, I think I have no choice but to switch to object graphics via your example. Thanks for the help, and for giving me a place to whine about my IDL difficulties! Raoul PS To all - Sorry about the double post yesterday.... strange mixup! Sent via Deja.com http://www.deja.com/ Before you buy.
In article <MPG.129e62a85186952598997c@news.frii.com>, davidf@dfanning.com (David Fanning) writes: > Well, after telling someone the other day, > "Oh, it would be simple with object graphics.", > I decided to see how simple it would be. > > Yikes! > > OK, must be a light problem. Add a light to the image. > (Why didn't I think of this? Every picture in an > art gallery has a light above the image to illuminate > it. Stupid.) Whoops! Wrong kind of light. Add > *ambient* light there, Jose. > > And so it goes. I'm looking for my slide rule right > now so I can calculate the optimum distance and viewing > angles for the lights in the scene. [...][/color] OK. I guess, I see clearer now: it's not objects that I don't like, but the applications that are built on objects! Just had a look at AVS the other day: Maybe I'm already too old for this, but I just can't make ends of something where you have to mouse and drag yourself along, select rectangles with a 3D-look and inconclusive labels, paste them onto a worksheet, connect them with wires, and hope that this will work. Similarily: IDGgr... is far too much "real life oriented" for my sense. Why should I have to call an electrician (or - worse - a professional light engineer) just to put some scene on my screen. I always thought, the virtue of a computer is that you can use it as a tool, and that it will do *exactly* what you ask it to do. Nowadays it seems we have to *talk* to these machines and *ask* them to *please* try to accomplish at least a tiny fraction of what we had in mind. Even though it might in the end produce a result which falls short of one produced with IDLgr..., I much prefer to write surface,data instead of virtual_world = obj_new("IDLgr...",/Grass_On_The_Bottom, $ /Mountains_On_The_Right,/Rivers_Below) virtual_world -> SetProperty,River="blue and reflecting", $ Mountains="not too steep" light = obj_new("IDLgr...",Time_Of_Year="January 1, 1999 AD", $ Sky="Some scattered Cumulus Clouds") light -> SetProperty,MoonPhase="Full" potential_surface_plot = obj_new("IDLgr...",world=virtual_world, $ light=light) potential_surface_plot -> AddData, data ; In version 5.2.1, rivers don't look nice, so turn them off potential_surface_plot -> SetProperty,/DoNotShowRiver ; The following feature is undocumented but prevents a crash ; for winter scenes potential_surface_plot -> SetProperty,/DoNotCareAboutSnowCover potential_surface_plot -> Please_Show_And_Pray_That_User_Doesnt_Change_Aspect Ooops! Forgot to specify the density of air .... and my clouds don't have 24 bit ... But object graphics programs may win a Noble Price for literature one of these days ;-) Cheers, Martin -- [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[ [[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[ [[ Bundesstr. 55, 20146 Hamburg [[ [[ phone: +49 40 41173-308 [[ [[ fax: +49 40 41173-298 [[ [[ martin.schultz@dkrz.de [[ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[