Hi, ... > Instead, I would start by caching a pair of Lists, one for positions, one > for data, input through 2 DXLSetValue inputs, using 2 GetGlobal-SetGlobal > pairs, then appending your new info as short lists to the existing cached > lists. The "List" object is essentially like a simple array, without the > overhead of interconnected components that one sees in a Field. You can > make a new list by feeding existing lists or single items or a combination > into the List module, so in your case, you retrieve the cached List from > GetGlobal, then append your new input list to make a new (longer) list, > then send that back to SetGlobal for the next iteration. Also, of course, > feed the output of List downstream for visualizing, as follows. You will > need to generate a Field to visualize, so you feed the positions list into > a Construct(origin) and the data list (which of course must correspond in > length, and have a one-to-one order correspondence with the position list) > into the same Construct(data). Construct makes the Field, then you can > visualize it. Since the data is vector, use AutoGlyph and get vectors for > free. Oh, Construct will add 1D line connections which you don't want, so > use Remove(connections) right after Construct. ...
Thank you for your detailed advice. I have made a few experiments with this setup, an it works "basically". I did not use live data, but started with a small program reading positions from a file and feeding these via DXLSetValue to dx. On the dx side, I used DXLInput, List with a GetGlobal/ SetGlobal pair, Construct, ShowPositions and Image. However, this is quite slow: it executes at a rate of about 2-3 "frames" per second (on Sparc Ultra-10 with Creator-2D and hardware rendering). I think I will have to add some accumulating mechanism on the simulation side, so that larger chunks of positions/data are fed to dx, and switching to single position updates only when this kind of close examination is occasionally necessary. A real problem which I could not solve is that the image module resets itself on every iteration of the net. This not only results in annoying flashing of the image, but also makes it impossible to manipulate the displayed image interactively (i.e. rotating, zooming etc.). Is it possible to circumvent this (i.e. can image retain viewpoint, scaling properties etc. across execution iterations)? ... > And, think about doing this in script mode: I have a sinking feeling that ... Invoking dx with -script from DXLStartDX does not work, this apparently bypasses the DXLink facilities. I tried -execonly, but this leaves me with a image window without any interaction mechanism (no rotation, no zoom etc.). Thank you again for your help. D.Ruppert RTS GmbH Schwieberdingen/Germany [EMAIL PROTECTED]
