I'm running DX on W2K with X-Win32. As soon as I start DX and execute a network, the CPU usage for dxexec.exe goes to 100% and stays at that level until I quit DX. I'm not sure if this is related to the very long delays (> 20 sec) I sometimes see between the mouse button click and something happening. Does everyone see this behaviour on NT (W9x doesn't show process activity levels). Is there a way to fix this, e.g. by setting process priority levels?
Gib > -----Original Message----- > From: Gib Bogle [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 12, 2001 10:23 AM > To: '[email protected]' > Subject: RE: [opendx-users] Clipping > > > Chris, > > > -----Original Message----- > > From: Chris Pelkie [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 12, 2001 12:38 AM > > To: [email protected] > > Subject: RE: [opendx-users] Clipping > > > > > > >Thanks for the advice on using Slab. That gets me a couple > > of steps closer > > >to my goal. I have now run into another difficulty. I want > > to Construct a > > >field corresponding to the TIFF image, but with actual (x,y) > > positions, then > > >attach the image colors to this field. My reason for doing > > this is so that > > >I then hope to use Map to map these colors onto the > > rubbersheeted image of > > >the field with the elevation data. To use Map I believe I > > need the two > > >fields to be in the same coordinate system. > > > > > > They must overlap at least by some amount or you get a field of > > invalid positions from Map, so yes, the coordinates must be > similar. > > You are going to have a great deal of trouble mapping a 2D surface > > onto a 2.5D rubbersheet though so don't even try. (2.5D means a 2D > > surface projected into 3-space, i.e., the positions are 3D but the > > topology is 2D). Map will refuse to do it, period, but even if it > > didn't refuse, the only places where the two fields touched > would be > > where the 2D plane intersected the 2.5D object, so you'd get spotty > > coverage. > > My explanation of what I plan to do was imprecise. My > intention is to use > the same method used in the Colorado River example (in the > distribution) to > paint a TIFF onto the field containing elevation data, which > is subsequently > rubbersheeted. > > > > > > > > >I have been doing some testing with Construct and Map to see > > how to map > > >colors, without much success. > > > > > > Um, that's why the gods invented Colormap. (:-) > > Yes, you can do the same with Map but it's more trouble than it's > > worth usually. > > I will explore this, but it would be a very good idea for me to fully > understand Map anyway. > > > >My simple test has two Constructed fields > > >which are identically created. > > > > > > Good so far > > > > >I pass each through Autocolor (here I vary > > >the parameters) > > > > > > why? just map the data from one to the other then Colormap... but > > keep reading... > > I Autocolored just to get some colors for testing. > > > > then use Map with Positions and Colors, i.e. I try to map > > >the colors of one field onto the other. > > > > > > Colors are RGB 3-vectors (usually, esp. if you used AutoColor and > > didn't set the "delayed" flag). Map ALWAYS interpolates (even if it > > doesn't have to). Interpolated RGB 3-vectors are usually not very > > good looking, since RGB is a very non-linear space (after > > transformation back to the visual representation we know and love). > > In other words, you can't move from point A to point B in RGB space > > in a straight line and expect the colors along the line to be > > "smooth" visually. So abandon this approach. > > In this test case no interpolation would occur (since the > positions are > identical), but in the real case of course I was expecting to employ > interpolation, and as you point out I hadn't thought through the > implications. > > How about going the other way? I can use the resolution of > the TIFF (since > the colors are fixed to this grid) and map my elevation data > onto a field > with the TIFF grid and colors. > > > > This gives an error message about > > >unsupported color format. If I send the output of each > > Autocolor module to > > >Image it displays OK. Am I trying to do something with Map > > that it was not > > >designed to do? > > > > > > > > > Almost certainly, you created scalar data back in Construct > so you'd > > have something to Autocolor. > > > > Now you've asked Map to do the following: > > For each position in the input field, look up in the map field's > > positions to find a match. Interpolate the map field positions as > > necessary to get an exact match. Interpolate the map data > > corresponding to the map positions that were used, to get an > > interpolated data value that corresponds to the interpolated map > > position. Carry that value back to input and stuff it into the > > designated component, indexed to the original position we were > > working on. > > > > OK, you said: "look up by positions, retrieve data (which > is scalar), > > stuff into colors of input, then render." > > Renderer says: "barf! colors cannot be scalar integers (or whatever > > you tried to feed me)." > > (ok, it said "unsupported color format" but I like my error message > > better; it has more snap.) > > What I had failed to grasp here is that it is the map data > that is being > stuffed into the input color component. I had thought the > map color was > being used, which as you point out above wouldn't work if > interpolation was > required. > > > So let's roll way back up to where you said you had two identical > > fields. Why not just Replace the colors from the source field onto > > the destination field? They have the same exact positions > and number > > of colors and everything lines up beautifully and Replace does NO > > interpolation, so you don't even get weird round-off errors > or wacky > > RGB values, and it happens instantaneously since it's just > a pointer > > copy operation under the covers. Map involves some > heavy-duty number > > crunching. Big nasty Maps can take considerable time to chew on the > > problem. Map is NOT smart enough to recognize that the > positions are > > perfectly aligned. It will still do all the math. And due > to possible > > round-off error, it may not even come up with the same answer. > > My simple test was using identical fields, but I started out > with something > closer to my real problem, in which the elevations are in a > field with a > grid that is completely different from the TIFF grid - > different numbers of > positions, and real coordinates rather than 0...Nx, 0...Ny. > > > Same for your TIFF: construct a "blank field" with the right number > > of positions and connections (delta 1 in both dimensions, > since it's > > a pixel map), then in one instantaneous sleight of hand, lift the > > colors of the TIFF and drop onto this field. > > > > NOW rubbersheet (after Marking the elevation data), or just > directly > > Compute new positions based on X, Y, elevation, and any scaling > > factors you want to apply to X,Y, Z. You map a 2D surface to a 2D > > surface, THEN you make it 2.5D. Much simpler. > > > Or, go all the way back to what Greg said. An image in DX is just a > > 2D field of positions and connections (quads) with colors > (no data). > > You should be able to Replace the elevation data (from wherever it > > comes), or calculate it in some interesting way (for > example, Convert > > colors to HSV, then elevate the "saturation") onto the > "image" field > > then rubbersheet or Compute positions. The original colors stay > > firmly attached to the transformed positions so you don't > need to do > > any mapping or colormapping or interpolation of colors. > > If I understand correctly, I need to keep the grid of the > TIFF (in the sense > of preserving Nx and Ny). I just need to create a field in > which the TIFF > positions are transformed into the same coordinate system as > the elevation > data, then Map the elevations to this field. I think I was > trying to do it > back to front. I'll give this a try. > > I am aware that my progress with OpenDX is painfully slow > (I'm not sure why, > but maybe age is a factor), and I am very grateful to you and > Greg for your > patience. > > regards > Gib > > > > NOTICE - This e-mail is only intended to be read by the named > recipient. It > may contain information which is confidential, proprietary or > the subject of > legal privilege. If you are not the intended recipient please > notify the > sender immediately and delete this e-mail. You may not use > any information > contained in it. Legal privilege is not waived because you > have read this > e-mail. > > For further information on the Beca Group of Companies, visit > our web page > http://www.beca.co.nz > NOTICE - This e-mail is only intended to be read by the named recipient. It may contain information which is confidential, proprietary or the subject of legal privilege. If you are not the intended recipient please notify the sender immediately and delete this e-mail. You may not use any information contained in it. Legal privilege is not waived because you have read this e-mail. For further information on the Beca Group of Companies, visit our web page http://www.beca.co.nz
