Matt wrote: > there is an import via socket module available in the VPE; have > you had any experience with this?
I have not used it. > As Mike mentioned, I observed in the call_module DX samples where it > appears the VPE data flow graphs are essentially coded into C: a > program-schematic of the data flow, analogous to the VPE > implementation. For the data receiver / viewer, I may take this > approach because of it's obvious speed increase. This doesn't preclude > me from using the DX image viewer, correct? The following is based on what we currently do, which grew out of our initial use of this approach in 1997. Things may well have changed since then, but I think the basics will be the same. You can use Display, but Image was (is?) not available. This is not the limitation that it might initially sound like, since default rotate/pan/zoom interactors are provided. But I believe they may only be available in software rendering mode, since we end up using our own and I think that was the reason. I just took them directly from the code in Image(). Then, the Supervise* modules provide all that you need for window and event handling, with events tied to whatever functionality you want. So, for example, to interact with one object in a Display of many objects, you can catch a button down event, call Pick to find the object, replace the object with a simpler geometry version (for interaction speed), and then apply a transform to it based on the cursor motion, and then rerender via Display. And then repeat as long as the button is down. Then on button up you can put the original object back in and Display. This all happens in a tight event loop down inside Display/Supervise* so it's very fast. > I agree that it seems much easier to use the DX viewer natively rather > than creating a middle-man that has to constantly request and receive > updates from DX. It seems to me I could still write my custom GUI in Qt > (later on), and simply instruct DX what to display / do via C-calls (via > the callm lib). This way, I'd still utilize the original DX image / > visualization window (for zoom, rotation, etc.), but allow my front-end > GUI to manipulate it in terms of which data is displayed, and how, etc. That should work. We generally try to keep the GUI separate from the rest of the code with a functional interface; with the GUI either telling the rest of the code what to do, or displaying results from it. > If there's any errors in my plans or assumptions, please let me know. > > Thanks again, > > Matt > -- > > Michael Zelenik wrote: > > >Drew correctly points out the difficulty of using the VPE and > >data flow environment for robust or commercial products. > > > >However, all of the DX functionality IS available through the > >library routines, either directly in an explicit routine, or > >through the valuable DXCallModule() function, which allows you > >to run any module just as in the VPE. This also includes > >Image and Display modules, with event handling. > > > >Using this approach, we have created robust commercial products > >entirely in C. without the dxexec or the VPE. These products make > >extensive use of the DX functionality and data model inside, and > >the Display module outside. They also provide excellent user > >interactivity with complex 3D displays (much better than one can > >get in the data flow environment). In general, we prototype in > >the VPE, and then write the C version after we see where things > >going, often as an iterative process. It has worked very well. > > > >In my opinion, this is the ONLY way to write anything that is of > >large size or complexity, and certainly anything that needs good > >error handling. But, like everything else with DX, there is a > >learning curve, but once over that, it becomes very nice to work > >with (except for memory handling sometimes). > > > >If you search back through the archives for my name in the > >From or Body fields, you can see some discussion about this back > >in 2000 or so. > > > >Mike > > > > Andrew J. Dolgert wrote: > > >Hi Matt, > > > >You can set variables in a running copy of DX using DXLink, but you are > >correct that you send them as text. There are helper routines in one of > >the libraries that let you write a loadable module and external program > >which talk with each other over sockets. These routines are commented > >out in the Windows build, by the way, with a big #ifndef WIN32. You > >would want to combine the two in order to have full control over DX. > >Send data on the socket; change parameters through the script. > > > >If you want to use shared memory, you have to write it yourself as a > >loadable module in DX. On Windows, you have to roll your own anyway. > >Writing a module isn't so bad, though. MPI is also available, as I > >think about it, and implementations of MPI sometimes use shared memory > >on local machines. I haven't looked into using MPI with DX and suspect > >it is implemented mostly for parallel execution of modules, not for > >receiving data from remote processes. > > > >If you don't have a running copy of DX, then you can still use library > >methods to decode arrays and such, but you can't load a DX net. Without > >a DX net, what good is doing visualization in DX? I think this technique > >is best for translators to/from DX. For instance, if your program wanted > >to create a DX Object and then send it to DX, it could use the library > >to make the relevant Arrays and Objects, then use _dxfExportBin_buffer > >to turn this object into a byte stream, send the byte stream to DX, and > >then have a DX module decode it with _dxfImportBin_buffer. More likely, > >you'll write a DX module that receives data in your preferred format and > >then creates the Object on the fly. > > > >When you control DX from an external program, the simplest way is to > >allow DX to show its own Image window. If you want the display in your > >own program, then see the Tk example in the distribution. Every time you > >try to rotate the image, you have to request that DX rotate the image > >and return the result. If you want to test whether this will work well > >enough for you, you could expand the Tk example to allow rotations. You > >may want to do this to prove to yourself that DX can fulfill your > >technical requirements. > > > >I probably have some of this wrong b/c I know better the things I did > >than everything doable in DX. People have wrenched this program into > >all sorts of amazing capabilities over the years. While the data model > >of DX is great and it is a very expressive visual language, it is not > >good at being embedded in other programs because it runs as a separate > >process, doesn't have structured error modes to the controlling process, > >and the executive sometimes dies. All this is probably okay for an > >academic tool, but, again, it depends on your requirements. > > > >Drew Dolgert > >Cornell Theory Center > > > > >
